2087 replies to this topic

[BananaBoat]

Oh good point, I might revert to the official and test again. Stay tuned

Sent from my HTC_PN071 using Tapatalk


Update, yes definitely related to the unofficial version. I might need to raise it with them.

Sent from my HTC_PN071 using Tapatalk

[mukuste]

Good to know, thanks for testing.

[BananaBoat]

Good result. Thanks for listening and looking into!

Sent from my HTC_PN071 using Tapatalk

[IPJball]

 

Hey again,

Hope this works. Here's what Funhouse vp9 JPSalas fs, and Funhouse vp9 night mod fs looks like still,

with the latest dx9 vp9 test. It shows the graphical glitches up over the white light in the upper left corner.

Again, hope this works, first time I uploaded pictures here. Hopefully these Funhouses can be fixed!

Thanks!

[IPJball]

By the way, again, this is on a Surface Pro 2.

Thanks!

[mukuste]

Thanks for the screenshots, I can reproduce that. Will have to find out what's going on, it looks like Z fighting in the first one at least.

[IPJball]

Thank you very much Mukuste! The only other things wrong with those Funhouses

is on the night mod, Rudy's totally frozen, and on the regular JPSalas version Rudy's face goes

from dark to light when he opens his eyes and closes them. Other than that the Funhouses don't

really have any other problems.

Thank you again!

[fuzzel]

When you right click on an object, the right context menu will commands available but also show you all the objects under the pointer, and you can select an individual item from the list.  However, it appears Decal objects are not displayed in the list.   Fuzzel or Toxie is this a VP bug?

The objects listed in the context menu depend on the object name. Decals don't have a name that's the reason. I'll check that...

ok rev928 has a workaround for that issue. If you right click on an object decals will be shown in the context menu as "Decal". It's not the best solution and can be confusing if you have overlaping decals but better than nothing

Edited by fuzzel, 26 February 2014 - 11:40 AM.

[mukuste]

Great! Definitely much better than nothing, I guess in most cases there won't be many overlapping decals.

[arngrim]

Ok. It might be a leak in that unofficial VPM version you're using then.

if we talk about my vpm build, i highly doubt it since i just added more roms, and that's all

Edited by arngrim, 26 February 2014 - 01:37 PM.

[arngrim]

can we confirm that with the official release, or the latest rev from sourceforge that the problem is not there?

[jimmyfingers]

I was initially opposed to new settings just to work around glitches with the new renderer since initially this whole current version was just intended as a stopgap between VP9 and a new VP10. Now however it seems that compatibility is already pretty good, and I put so much work into it that it would be kind of a shame not to go the extra mile and give table authors a way to make their tables perfect for this version, even if it's only a single version of VP. Who knows how long it takes until VP10 materializes...

Very glad to see this and thanks for your determination in a fully compatible VP9_DX9 build.  I agree that it will be an unknown but likely somewhat lengthy time until a VP10 version and we are indeed so close to a good looking and performing VP9 on DX9 that it would indeed be a shame not to get it that extra mile especially where some things may still not be resolvable by the author / table update alone in it's current state. The benefits that the DX9 builds are showing for incredible smoothness, which I feel is assisting in the realism, and for whatever reason physics appearing to be better / more varied points of contact (flippers at least) would be something that I think all would benefit from vs. having to use soley the last DX7 version of VP (92X) to be able to play the current collection of tables without graphic issues. 

 

As far as new bugs though, I have discovered something in the latest build that does not occur in any other previous version and relates to objects being obscured that are close to the PF level (.2-1.5 or so).  It affects at least ramps and wall objects and would have a bearing on several elements / techniques and will likely be detectable on numerous tables in one of a few ways (whether people are not actually noticing / reporting it or not).  Anything that uses PF GI or light images at playfield level (not surfaced on anything / no surface defined) and some other near playfield objects will likely be covered up and not rendered as previously, such as roll-over graphics that use ramps with lights / walls on top for hiding / showing.  Tables with PF GI light objects surfaced on nothing  (i.e. at playfield level / 0) are now obscuring items that are around 1.2-1.4 or lower (it depends where on the table and the table view it seems).  These objects do not have to be alpha ramps nor primitives so the latest primitive sorting / alpha ramp reversion aspect alone should not be the underlying issues.  This is being reproduced with just basic "solid" ramps and walls both with no textures assigned (same with the light objects).  So the more difficult alpha / primtive sorting should not even be at work here and hopefully that means this can be a more independent fix than those ordering issues. 

 

Here is a screen shot showing three green ramp objects from left to right at .2 (top / bottom), .6, and 1.2 respectively.  There's a wall in the centre with .8 height and a light that has no surface / is at playfield level.  The exact same group of objects were copied to two other locations further up on the table to indicate the positional variance.

 

Here's what it looks like in VP9_DX9_text6:

 Capture of Near Playfield Objects in VP9_DX9_Test6.PNG   466.1KB   16 downloads

 

Here's what it looks like in any previous version of VP9_DX9:

 Capture of Near Playfield Objects in any other DX9 Test Version Previous to Test6.PNG   267.96KB   17 downloads

 

Here's what it looks like in VP9_Rev923:

 Capture of Near Playfield Objects in VP9_Rev923.PNG   262.42KB   17 downloads

 

As a quick side note, the text boxes would be good to also get back into functioning with VP9_DX9 builds as they are very useful for debug purposes when building / updating a table.

 

This obscuring issue is affecting all tables with PF GI lighting and any objects that are less than about 1.2-1.4 in height.  A main group of tables for this occurring is where the insert / table lamps (lights) are propped up on small walls (.2) or using a technique I use for some of mine, where they're all surfaced on one big "solid" ramp for a quicker way vs. editing / creating a wall for each light (my technique uses a light only blueprint export than a low opacity mask made in PS and used as the texture for the solid ramp).  This ramp platform for lights is so that the GI does not overwrite the lamp images (no pure black mask in the PF images themself needed at all) and I used it in a couple tables, however, the wall technique is also used by other authors and is in the Airborne table and Comet by UW for examples.  My Centaur WIP and the current version of Bram Stoker's Dracula (GI8) have the ramp as a light platform technique.  In Centaur it's less obvious as the lights will only flicker because the over-writing PF GI image has the light inserts still in it / not blacked out but they are in an off type graphic state (if I highlighted them say as purple it would be very obvious to see it obscuring the table lights when PF GI events / changes are occurring).  For the BSD GI8 table, the PF GI images were first attempted using pure black inserts but that was yielding some rough edges on the inserts in transition so instead I upgraded to the ramps technique but because the original 8 PF GI images still have the black inserts that table is a very good one to observe the issue with and can be seen to occur with this test6 and not with anything previous.  In the BSD GI8 case while testing the current issue I had to raise the "Light base" ramp / platform up to 1.4 or higher before they will start to show correctly but this is no good as many other aspects are affected and other objects would then all need to be raised plus, at 1.4 the lights are raised too much above the table and distort the graphics to a noticeable level that was not previously present (the .2-.3 values are used because they effectively do not graphically appear any different but do the job of raising the desired object above the one it's needed to be displayed above).  

 

Here is a link to that table:

http://www.vpforums....s&showfile=6222

 

It's very easy to reproduce and running in the latest DX9 version shows the PF GI black portions above the lights even though the lights are positioned / raised above the PF GI images - all other versions do not.  Changing the PF image transparency texture to pure black is not a fix as it will look "better" but the old rough edges will return and it is not fixing the real problem where the platform the lights sit on is not properly being recognized as higher than the PF (0) level.

 

I can create a highlighted example with the Centaur WIP if you need (Mukuste) but I take it that the above screen shots and test tables should suffice.  In Centaur already the obscured roll-over issue is present and easier to detect than the inserts being "over-written", however, that too is occurring it's just more like they're blinking because the PF GI image has the inserts drawn (just not lit).

 

I'm also attaching the test table from which I made the above screen shots as this is the quickest and simplest way to see the issue. 

Attached Files

•  Test table for lights obstructing lower items.vpt   140KB   1 downloads

Edited by jimmyfingers, 26 February 2014 - 03:26 PM.

[mukuste]

This issue is almost certainly related to the depth bias value applied to the lights. The basic problem is that you cannot render a flat light on the table at exactly z=0 -- it will get hidden by the already existing table surface at that height. So you have to push it up a bit. This is not done geometrically, but simply by adding a depth bias for the purposes of the Z-buffer check. I initially had very small values for this depth bias, but it caused problems on many tables where then lights which were supposed to be visible vanished due to a too small depth bias. So I had to gradually increase this value to fix issues on several tables. (As another reference, the invisible decals on Barracora were essentially the same problem.)

 

The strange thing is that the depth bias I currently use is still much smaller than the values you cite (.8-1.4). It seems that the resolution of the depth buffer is becoming a problem here. I currently use a 16 bit depth buffer, which seems like it would be plenty for the relatively shallow scenes that VP has to render. So either there is a bug in the near/far Z plane computation, or I really have to increase Z buffer depth to 32 bit and hope that that helps. I hope this has no noticeable performance implications on modern hardware.

[unclewilly]

Looks like we are getting down to the nitty gritty with compatibility issues.


So are we looking at a vp9.3 dx9 final soon. Or is there still a lot to do.

I'm eager to see the vp10 development.

Thanks for your patience and hard work on this.its truly amazing how far you've come in such a short time

[jimmyfingers]

Can this value be something that we set ourselves so that tables that require it can have one value and tables that are now having problems because of the current value can set at a different / previous value? Would this be something globally or maybe it would be ideal to have in the light object itself this bias value so that it can be tuned as needed?  It definitely will have lot's of problems in likely many more tables, as is now requiring .8-1.4 height unit increases in various objects to resolve, than the several previous ones with only light issues and may have had a more suitable work around.  Seawitch and Blackout were ones with previous issues and for which it was changed, correct? I'm curious if they have an easier work around then all the tables that have roll-overs for instance.  Also, decal issues usually in the past have been resolved by using the recommended approach of converting to ramps anyway as the same thing can be achieved and gives greater control (using ImageModeWrap mode instead of ImageModeWorld is the same as a decal).

[jimmyfingers]

This issue is almost certainly related to the depth bias value applied to the lights. The basic problem is that you cannot render a flat light on the table at exactly z=0 -- it will get hidden by the already existing table surface at that height. 

I'm confused by this as I can make a test table with a PF sized light that has no surface (at 0) and has no graphical issues / is not hidden by the already existing table surface (table surface being set to an image using a test solid green texture) using the previous test5a build.  

 

Here is a screenshot using the previous tet5a build, a playfield sized light with GION, and a image bound to the table itself with using a solid colour texture. It displays fine:

 Capture of Playfield level light with no problems in Test5a.PNG   691.56KB   17 downloads

 

Here is a screenshot of the same table with the light shifted over half way to better demonstrate that the green table surface is not obstructing it:

 Capture of Playfield level light with no problems in Test5a (light shifted half way to left to demonstrate).PNG   696.88KB   17 downloads

 

I'm again attaching this test file / table itself for your reference / testing:

Attached Files

•  Test table for with playfield level light with no problems.vpt   3.97MB   1 downloads

[naboodiver]

Wow... I am seeing a large number of issues I discovered (and I am sure others) that are now gone with Test6..  Great work as most of the table image layering is fixed.   The one I noticed in the hour of testing I did last night is that Homers Head (no movement and black square around the head) is still not rendering correctly in the current version of The Simpson's Pinball Party.    A second is Whitewater, it is showing the black circles where light are suppose the be.    I assume this is related to problems with transparent black already noted.   The third one is Elvira Party Monsters - The Boogie Men are missing.     Keep up the great work as I agree with others here that this is getting very close to being golden. 

 

Oops forgot one:   Hook playfield still goes black with the game is started.

Edited by naboodiver, 26 February 2014 - 04:15 PM.

[mfuegemann]

Hi mukuste,

 

the big 2 picture EMReel (apron card) on the Rugby table is working now with Test6.

 

Regards

Michael

[mukuste]

 

This issue is almost certainly related to the depth bias value applied to the lights. The basic problem is that you cannot render a flat light on the table at exactly z=0 -- it will get hidden by the already existing table surface at that height. 

I'm confused by this as I can make a test table with a PF sized light that has no surface (at 0) and has no graphical issues / is not hidden by the already existing table surface (table surface being set to an image using a test solid green texture) using the previous test5a build.  

 

 

That's because the mentioned depth bias gets applied internally. It's transparent to you, the table author, but it does happen during rendering.

[jimmyfingers]

 

 

This issue is almost certainly related to the depth bias value applied to the lights. The basic problem is that you cannot render a flat light on the table at exactly z=0 -- it will get hidden by the already existing table surface at that height. 

I'm confused by this as I can make a test table with a PF sized light that has no surface (at 0) and has no graphical issues / is not hidden by the already existing table surface (table surface being set to an image using a test solid green texture) using the previous test5a build.  

 

 

That's because the mentioned depth bias gets applied internally. It's transparent to you, the table author, but it does happen during rendering.

 

I still don't get then why the examples above are fine then.  Whether it's internal / tranparent to the table author or not, the net effect - in the examples above at least - are that there is no issue with that light object / image at table surface 0.  Does it work in some cases and not others for some reason or when there are more objects on the table?  Even if that's the case, it can't be a global / general / all the time thing in at least the test table above shows no issues regardless of lights at 0 with the playfield surface.