I believe I know why things are not looking correctly on the Airborne table and the WCS '94 table. Both the graphic issues indeed appear to be ordering related / ordering graphic issue type problems. I think I have found a bug in the DX9 VP builds since the new ordering by height has been added that seems to not work correctly with alpha ramps that do not have the Additive Alpha option selected (regular transparent ramps / not flasher type objects).
[...]
Thanks JF for your detailed analysis. Here are two points to hopefully make things even clearer for you:
(1) Since Test4, alpha ramps which are set to additive blending do not write to the depth buffer anymore. For anyone not familiar with the concept of depth buffering, you may read up on it here. This means that, even if an additive alpha ramp is wrongly rendered before another, lower element, it still won't block out that lower element from rendering. This is why setting the ramp to additive fixed your issue.
(2) Also between Test3 and Test4, there was a change to the way the depth of alpha ramps is determined for the purpose of depth sorting. In Test3, it was only based on height, as you assumed. In Test4, it instead first computes a central point for the whole ramp in 3D space, and it takes into account not only height, but the actual depth in the scene with respect to the viewing direction. This improves the sorting in some cases, but can also make it worse in others. Especially for large, curvy ramps like the one in your table, having a single central point is a very rough approximation to the actual position of the ramp, so artifacts like this one can occur.
As I said before, the automatic depth sorting at this point is basically a band aid for some rendering issues. In particular, it is needed to prop up the crucial fix for fading lights (I explained before) since that depends on the engine having free rein over the draw order. It will stay in the VP9-DX9 version, though it's up to debate whether it will stay in VP10. With some improvements, I think it could perform very well and be a huge boon for table authors as they don't have to worry about any draw order issues themselves anymore. In addition, as I said, we do really need automatic sorting if we ever want to have a fully dynamic camera viewpoint since a fixed draw order only works for a fixed viewpoint.
@Mukuste - Thanks for further describing some of the nuances of the back end that are manifesting in these graphical issues still being experienced with the latest builds of VP9_DX9. I'm certainly not trying to ask you to go back at all to the old method, as I once / first had requested, since you've indeed described why you can't / won't but I also don't think my last post read in any way that was asking you to do that. I am looking to point out issues or potential bugs that are still occurring graphically and it seemed that the behaviour I was describing may have been a bug that could have potentially resolved some of the current graphical issues with alpha ramps that don't even involve the additive alpha attribute.
The description of why the changes in the height calculation and effects from it have changed between builds is quite useful to know and it seems like indeed some issues follow the change from version 3 to 4 when you added the more calculated ordering routine for more than just height. I think that this might be causing more graphical issues than what it resolved though as now tables like Airborne, WCS '94, and the Centaur WIP fuzzel and I are working on have new issues since that change vs. just height alone. It seems that one of the only tables that benefited from it was the Monster Bash PcKiller table and that table may be getting almost too much focus as the be all and end all of tables to test, likely because of the it's system demands and the stutter free play now available with it in DX9 builds. But there are a lot more tables to consider in the context of compatibility purposes. The latest Monster Bash uses more up to date techniques that also put it in a class of it's own yet also distance it from the bulk of the tables out there that are arguably better in the name of VP9 general compatibility testing. Plus, nobody has seem to catch yet that the graphic "fix" didn't actually totally resolve the Monster Bash Creature Panel Bottom lights issue. It no longer blanks out the panel behind it at the bottom, but it also does not still properly draw the halo / glow around the bulb.
Here is a picture showing the three versions of VP (test2, test3, and test5a) where respectively Monster Bash creature panel lower light worked, than didn't, and now does somewhat but without the glow:
Capture of Monster Bash Creature Panel Flash Graphic Issues with Version Differences.png 52.54KB
22 downloads
The new alpha (actual) ramp issues like that noticed in WCS '94 and Airborne, as well as the Indianapolis 500 example I provided are going to be wide spread as, well before Additive Alpha options or even using alpha ramps as flashers, the very first use of true transparency was for clear plastic ramps finally being able to be drawn nicely and without the checkerboard aspect. These, by their nature and as you say, wind around the table and as such are going to be a problem for the latest method of height calculation as you describe it with also calculating a central point.
So, how about this, if the current draw order techniques in VP9_DX9 are already a band aid type aspect, cannot we not add an attribute to the ramp object so that one can choose for it to be ordered by height only (VP9_DX9_test 3 style) or be left blank and use the current default placement and height type calculation (VP9_DX9_test 5a style)? Could this not work in still merging all the results into the final "auto-ordered" index or whatever it would be called? The potential result would be more fixes / options for fixing in a quick way for these tables with conflicting ways in which to best benefit from both methods? As I was saying before, a concern isn't just going back to old tables to fix some items to make compatible with the VP9_DX9 final build, but having at least some option at all for which it can actually be done and right now the ordering issue is leaving cases where a fix does not seem possible and having to potentially just live with graphic glitches being the proposed solution.
The table builders are a dying breed here and we / they know a little more about the time and effort involved in both VP and supporting graphics programs to get the best graphical results for a table produced with VP. These new issues with ramp jaggies and drawing borders are something that negates a lot of time and effort previously spent avoiding them.
Here is another couple screenshots of the Centaur WIP that fuzzel and I are working on and it shows how the painstakingly drawn plastics with clear edges are now much worse looking post VP9_DX9_test3 version (bottom picture how they used to look / can look):
Capture of Centaur Alpha Plastics with Transparent Edges Graphic Issue in VP9_DX9_Test5a.PNG 1.47MB
21 downloads
Capture of Centaur Alpha Plastics with Transparent Edges Working in VP9_DX9_Test3.PNG 1.49MB
21 downloads
I'll send you a copy of the table for you to test / assess for yourself and see how the current objects are arranged. Hopefully my suggestion above can be implemented or yields some form of giving us an option to ensure the previous level of image quality for alpha ramps.
Edited by jimmyfingers, 24 February 2014 - 06:42 PM.
Top
are all trademarks of VPFORUMS.