3889 replies to this topic

[fuzzel]

rev2069 is up:

 

- fix export obj for single primitives. was a leftover from testing in rev2066

- fix rubber mesh export orientation. now the rubber is exported the same way as it's rendered.
- flag table as changed when alpha mask is changed in image manager
- fix kicker cup orientation again. In rev2066 the kicker cup mesh was rotated by 180 degrees even if the orientation angle was 0.
 

[toxie]

You and Fuzzel have made SO MANY great updates to the code and I know you are focusing on squashing bugs and sorting out the psychics. Is your plan still to enhance the engine's Anti Aliasing  after the final release of VP 10.0 or is something you will tackle  before the initial release?

 

No, unfortunately not. The rendering core will still be separated into static and animated objects, which is the main cause for the 'standard' anti-aliasing methods to not work (nasty technical details).

But this is still much faster than drawing everything from scratch each frame.

 

So maybe with the next release?

[ninuzzu]

I tested rev2069 and the export is ok now.

Collision seems to be working now, I played several games with multiball and everything seems fine.

I have a couple of questions

 

1) Why I have this?

 

That's the same model, the left one is exported with the whole table, the right one is a single mesh export. No materials there, neither lights, but they look quite different.

 

2) It seems that the lightning environment changes from desktop view to cabinet view.

 

If you look at these 2 screenshots, you will notice that the right (wire) ramp shines in desktop view (more or less that's the effect I want), but in cabinet view the shininess is lost; in the meantime the left ramp shines (under the airplane) while in desktop is ok.

 

3) Playfield reflection and/or shadows (like we see in FP) : is this possible?

 

Thanks again for all the work you are doing, you guys rock!

[toxie]

2) yes, this is a known bug.. the environment doesn't rotate with the table (yet)..

3) not for VP10.0 timeframe, but maybe later-on..

[KieferSkunk]

I tested rev2069 and the export is ok now.

Collision seems to be working now, I played several games with multiball and everything seems fine.

I have a couple of questions

 

1) Why I have this?

 

That's the same model, the left one is exported with the whole table, the right one is a single mesh export. No materials there, neither lights, but they look quite different.

 

2) It seems that the lightning environment changes from desktop view to cabinet view.

 

If you look at these 2 screenshots, you will notice that the right (wire) ramp shines in desktop view (more or less that's the effect I want), but in cabinet view the shininess is lost; in the meantime the left ramp shines (under the airplane) while in desktop is ok.

 

 

It looks to me like both ramps are having the same problem - in your full-screen table, the left ramp looks just as flat to me as the right one.  It's more difficult to tell in the desktop version if the left ramp is shiny like the right one, but there's a hint of it there.

 

Given that the ramps are completely flat grey in the full-screen version, I'm guessing that either the material has changed somehow (I don't know what the process is for converting a desktop table to a full-screen one, but if the ramp got labeled as a plastic rather than metallic material, that could change the rendering), or the viewing angle is causing the reflections to just not line up.  The camera is oriented straight down in full-screen, whereas it's viewing from the front at an angle in desktop mode, and that will change the angles at which the material reflections are calculated.  It's possible that you just got unlucky with the angle in FS.  (The VP devs can answer this much better than I can.)

[ClarkKent]

I talked to knorr again and I also think that a separate option for the speed of the rotation of the flippers would be a good thing. I also think the flippers are moving too slow compared to a real pin. At the moment the speed seems to be linked to the power - so the only way to make them rotate faster is to increase power. But I think this is not good. What do the developers think about this?

Here the message from the table testing thread again:
The only thing that still doesnt work correct (in my opinion) is the speed of the rotation of the flippers. On a real pin, i´m a really good drop/live catcher, i can almost catch every ball. But on the vpin its... a bit different - the timing is not the same and this kills a lot of fun for me. (it has nothing to do with the tv/pc latency). And the only way to increase to speed of the flipper is to increase the power. But this does effect the ball again...

[jdark]

 I also think the flippers are moving too slow compared to a real pin.

 

thats interesting. friend of mine is playing only real tables and at frist time he tried my cabinet he reported immediately that the flippers are feeling much slower, laggy. 

 

of course my system is pimped to have low latency - tv, 1000hz usb driver on arduino leanardo as key controller.

[BigBoss]

Since we are starting tables anew for vp10, is there any reason to keep cabinet tables rotated? Why not just do a portrait 1080x1920 table with zero rotation. This eliminates the issue of rotating the environment with the table. It eliminates the hassles of dealing with rotated desktops etc. Unless I'm wrong, the only reason to do cabinet tables at 270 rotation is "because that's what we've always done" which is really a horrible reason to do anything.

[hmueck]

What stops us from doing this? Doesnt vp10 support 1080x1920?

[toxie]

 

 I also think the flippers are moving too slow compared to a real pin.

 

thats interesting. friend of mine is playing only real tables and at frist time he tried my cabinet he reported immediately that the flippers are feeling much slower, laggy. 

 

of course my system is pimped to have low latency - tv, 1000hz usb driver on arduino leanardo as key controller.

 

 

What about changing the ramp up (making it lower) in the flipper setting? doesn't that help?

[ClarkKent]

I think this influences accelleration and not general speed.

[toxie]

But that means that they will move faster to their end position, isn't it? 

 

Have you guys tried that option actually?

[mpad]

What stops us from doing this? Doesnt vp10 support 1080x1920?

My sore neck would really like an answer to this.
I really don't know what can be done with rotation nowadays and what not.

[freneticamnesic]

 

What stops us from doing this? Doesnt vp10 support 1080x1920?

My sore neck would really like an answer to this.
I really don't know what can be done with rotation nowadays and what not.

 

 

Lol... I've installed irotate on the cab and just use a hotkey to switch direction so I can work on it without feeling like I got in a bad car accident

[Talantyyr]

lol thanks fren, that would have saved me a lot of neck / back pain, rotating myself around the cab, hahaha

 

Have to install that now! 

[mpad]

But can VP work in portrait now, the gui I mean, or is landscape still a must?

[hmueck]

The gui? Why should The gui care? The important thing is the video preferences and if they Support 1080x1920.

[mpad]

I never understood it anyway why I have to launch a program in landscape which switches then to portrait for rendering and back to landscape again. Weird.

[toxie]

because we never implemented it like that.  :/

too many features and bugs and requests and only limited time.

[Talantyyr]

I also think it's more important to fix bugs and implement cool new features like materials or new kickers then to change the perspective that require adjusting the desktop rotation and anything thats already working... (which wouldn't work in fp so i wouldn't use it anyway)