Database traversal

[Ian]

This one has puzzled me for sometime. Why are there so many transparency errors in games ..
Testing with scud, I was wondering if a 1 pass draw was possible, instead of the 2 passes we are currently doing. But it turns out it's not possible, it doesn't matter how you theoretically sort the higher level nodes it's just not possible.

Anyway moving onto ocean hunter, part of ocean hunter looks identical to what we are doing currently. I found that that this is only happening with polygon transparency.
I've marked the transparent polygons in red.

Doesn't look transparent, but the value is 31/32 so it's almost fully opaque.


The original hardware looks the same. There is no sorting going on here, because both contain the transparency error. The objects should be drawn the other way around. But this is how they come out of memory.


A different scene with a similar issue


Again the hardware is identical. So no depth sorting here


Here is a different scene. Notice no red polygons, these polys only have texture transparency. The poly alpha value is 255. Notice the white areas, these are related to the fact the polys are drawn in the wrong order.


The hardware doesn't contain these errors. This can only be possible if the hardware is sorting the scene. And I am pretty sure it's doing it at the list level, which should be fairly trivial.


I am pretty sure this would fix lemans24 too, because it has tonnes of these transparency errors.

So the too lazy didn't read, is my conclusion is. For texture transparency the hardware is sorting the scene by depth, probably at the list level which is probably quite cheap.

Polygon transparency seems to be handled completely differently, and the polys are drawn the same order they appear in memory. It also seems to stencil test them if they are translucent enough. Maybe less than 50%? Not sure.

[HarryTuttle]

Excellent findings!

Polygon transparency seems to be handled completely differently, and the polys are drawn the same order they appear in memory. It also seems to stencil test them if they are translucent enough. Maybe less than 50%? Not sure.

Or maybe when they aren't textured? Just a guess...

[Ian]

Possibly, although not really sure.

The stenciling is weird though, it seems to traverse viewport priority layers which makes no sense really. Here is an example from spikeout. Check out the shadow and the green overlay.



It seems to prevent the shadow being drawn and blended underneath it.

[Ian]

I need to do some more testing but I am pretty sure .. that the shadows in virtua striker are actually textured. Which would mean that stenciling would also be applied to textured polys

My current theory is it must be turning this on for polys with less 50% opacity.

This is my current build with the infamous balloon scene

[Ian]

This is the texture being used as the shadow for the virtua striker series, or at least vs98



So stenciling is definitely happening with textured polys ..

[HarryTuttle]

This is the texture being used as the shadow for the virtua striker series, or at least vs98

Confirmed. Don't know why I said that stencil could be limited to non-textured polygons... when I hacked, long time ago in my own build, the stencil-enabled (layered attribute) condition for many specific cases, including Virtua Striker series... and I discovered that the shadow was infact a black semitransparent texture...

[Ian]

I assumed originally that it would be just untextured polys .. but that turned out to be wrong.
I checked the balloon transparency in ECA and it's like 80%. So I really don't know how the hardware is deciding to turn on stenciling. There must be some poly / node flag somewhere.

[HarryTuttle]

Ian, the following caught my attention (from the devguide):

p.50:

LAYERED POLYGONS
A layered polygon is a polygon that lies in the plane of another polygon. The visual
priority of layered polygons is based on the hierarchy of the polygons. A layered
polygon has a lower priority than its children, and the same priority as its siblings.

Also p.376:

(Culling Node Functions)

SetGroupLayerNumber

Sets the layer number for group layering.

void SetGroupLayerNumber ( long layer_number ) ;

Description
Sets the layer number for group layering. The group layer number sets the drawing
priority for all polygons under the culling node.

Arguments
long layer_number Group layer number. Zero indicates the
lowest priority layer.

Return Value
None.

Application Notes
When group layering is used, the geometry being layered must all be coplanar. In
addition, all culling nodes whose drawing order is to be controlled by this attribute must
be children of the same parent node.
See also FormatAndFlushPolygons for special application handling of group layering.

Finally p.382:

(Culling Node Functions)

FormatAndFlushPolygons

Formats polygons and downloads to hardware.

void FormatAndFlushPolygons ( long stencil_polygons, long enable_vertex_sharing ) ;

Description
Formats polygons and downloads to hardware immediately. This function is useful for
applications such as database loaders which process large amounts of data and want
to format subsets of this data incrementally.

Arguments
long stencil_polygons Indicates whether to stencil (layer) child
polygons. This is necessary if the application
is dealing with group layering.
long enable_vertex_sharing Indicates that vertex sharing should be used
during formatting.

Return Value
None.

Application Notes
Under normal conditions (when FormatAndFlushPolygons is NOT used), group layering
is automatically handled by the PRO/API. However, when the application takes over
the order of formatting of objects by using this function, the layered polygon attribute
(stencil) must be defined by the application.

So it seems that when FormatAndFlushPolygons is used the stencil attribute must be also set (the Saga Rally 2 case). For other cases is the API that, looking at a particular group layer number, sets the priority automatically, with zero being the lowest.

Could be possibly the Node ID value ((node[0] >> 10) & 0x1FF) that sets this priority?

[Ian]

So it seems that when FormatAndFlushPolygons is used the stencil attribute must be also set (the Saga Rally 2 case).

Yes that's exactly right. I found that one when digging through the decompiled SDK with IDA pro.

The layer number must be it. I either couldn't find it before or just couldn't work out how it worked. I thought the node ID was simply a number of the node. Kind of like how the polys and view ports have optional numbers.
In node[0] there are some bits that we don't know what they do. These ones

-------- ?????--- -------- --------

[HarryTuttle]

In node[0] there are some bits that we don't know what they do. These ones

-------- ?????--- -------- --------

In <pro_culling_node.hh> they're labeled as "spare". My interpretation is that those "spare" bits (present also in other nodes) are just useless or, maybe, left for future features.