2087 replies to this topic

[toxie]

What are the advantages to having stereo3d as a shader? Performance? Just curious as I love blowing peoples minds when looking at my cab with 3d turned on with shutter glasses.

 

 

the next version will have a port of both the old FXAA and stereo3D software code to run via pixel shaders.

(not perfect yet, but i'll provide more fixes and opts over time)

and now one can use it with very very little performance drop. 

 

EDIT: i can recommend trying JPs latest AFM recreation in stereo3D, as this is my own personal reference table now, it just looks sooooo awesome.

Edited by toxie, 17 February 2014 - 01:13 AM.

[StevOz]

The EM reels in Image Reel mode on my tables don't work, at first I thought this maybe because they were overlaid on a light and overlapped, though after separting one for testing this was not the case, they simply didn't render?

 

Also graphic decals don't render over lights, even when I set them to a higher surface?

 

In the picture you can see I moved one of the reels and the Neptune graphic decal to illustrate this, the reel should show a zero, also the light blue coloured lights in the lanes should display a graphic rollover switch decal.

 

Edited by StevOz, 17 February 2014 - 04:38 AM.

[mukuste]

@ StevOz:

 

The reels seem to have had the same issues as the SS spider wheel, it's fixed now.

 

Decals have a known issue with their draw order, sorry that I forgot to mention that. Will look into it. Thanks for the table since few tables actually use decals.

 

The draw order dialog doesn't do anything in this version.

[StevOz]

@ StevOz:

 

The reels seem to have had the same issues as the SS spider wheel, it's fixed now.

 

Decals have a known issue with their draw order, sorry that I forgot to mention that. Will look into it. Thanks for the table since few tables actually use decals.

 

The draw order dialog doesn't do anything in this version.

 

If you are to use this table for testing you will need to deselect  the tick for side visible on the 3 pop bumpers as I had them set to black ( transparent ) for earlier VP versions, this table was originally built in VP7 and I later converted it for VP9.

Edited by StevOz, 17 February 2014 - 07:49 AM.

[unclewilly]

Just a question geared toward vp10.
Will using meshes for objects like gates and spinners be possible in dx9

Just curious.

Thanks for all your work

[mukuste]

Yes.

[toxie]

.. ..but we have to figure out a fast solution for primitive collision first, the existing one can become fairly slow (preprocessing and during gameplay)

[mukuste]

A first step will be to use meshes only for rendering while keeping the default physics.

 

I think the main problem with speed in the current code is that each polygon is inserted individually into the collision octree. If some bounding box or other cheap pruning technique is first applied to group polygons together, I'm sure we can speed that up a lot. The other issue is that, as far as I remember, only static primitives can be collided with currently. But I'm optimistic that we can solve these problems.

[unclewilly]

That's awesome. One thing that looks really bad in vp are the gates and spinners. They are so flat. I guess the hard part will be 2 way gates like on temps as we now use a spinner hack for those.

[toxie]

btw: @mukuste: could you please merge the patch i posted via PM at some point? cause i already have other stuff piling up on my machine..

[fuzzel]

A first step will be to use meshes only for rendering while keeping the default physics.
 
I think the main problem with speed in the current code is that each polygon is inserted individually into the collision octree. If some bounding box or other cheap pruning technique is first applied to group polygons together, I'm sure we can speed that up a lot. The other issue is that, as far as I remember, only static primitives can be collided with currently. But I'm optimistic that we can solve these problems.

not quite right...dynamic primitives can be collidable too, but the collision system isn't designed for dynamic elements besides the ball. So a moving or rotating dynamic primitive with collision won't works as expected. The reason for this is that the face normals are precalculated at startup and you have to move them too for the collision system to work.

[mukuste]

 

A first step will be to use meshes only for rendering while keeping the default physics.
 
I think the main problem with speed in the current code is that each polygon is inserted individually into the collision octree. If some bounding box or other cheap pruning technique is first applied to group polygons together, I'm sure we can speed that up a lot. The other issue is that, as far as I remember, only static primitives can be collided with currently. But I'm optimistic that we can solve these problems.

not quite right...dynamic primitives can be collidable too, but the collision system isn't designed for dynamic elements besides the ball. So a moving or rotating dynamic primitive with collision won't works as expected. The reason for this is that the face normals are precalculated at startup and you have to move them too for the collision system to work.

 

 

Well that's what I said right It's possible but doesn't work yet.

 

@toxie: yeah I'll try but it'll be better if you get it set up yourself, if I always have to merge them myself it creates a lot of extra work for both of us.

Edited by mukuste, 17 February 2014 - 07:27 PM.

[vampirolatino2]

mukuste, thanks a lot for your time and effort to this comunity

[BananaBoat]

Amazing, im sure the community is greatful for yours (and those involved) efforts.

This potentially opens up a miriad of benefits, from cheaper PC specs to run the emulator or higher res renders given the improved framerates.

Personally i cant wait to see this happen - so the obvious question, in your opinion, how far away is this project from being available as a steady release? (no pressure, just curious)

[mukuste]

Image decals now render properly on top of lights, on the playfield at least.

 

As for the release: I think it shouldn't take too much. The plan is to release 9.2.1 first, though, which should happen basically any moment. After that, we switch main development to the DX9 branch, do some cleanup and try to get some more compatibility fixes in, and that should be it. I think all the major work on the VP9-DX9 version is done. A couple of weeks at most, I would guess.

[StevOz]

Yeah well it's nought to concern yourselves about the decals over lights on the backdrop, that is an easy fix for an author update and really I'm most likely the only one that did that shit.

[BananaBoat]

Amazing, so it seems this will be a reality for my near complete cabinet. AWESOME, thanks very much.

[fuzzel]

We are about to release the 9.2.1 in the next few days. This will be the last DX7 version

[zany]

Damn i LOVE this project! 
Mukuste, Toxie, Fuzzel....you are the F*KING BEST!!!

[unclewilly]

Great news.
Should be an awesome year for vp.

Thanks to all the developers