Help With Diagnosing a Render Order/Compositing Issue

[Thaumaturge]

So, within a scene of mine, I have three objects. One of these objects is placed closer to the camera than the other two–and yet it renders behind them.

And… I have yet to figure out why!

I’ve disabled depth-testing and depth-writing for it (with override values); I’ve placed it in a higher culling-bin; I’ve re-enabled depth-testing and depth-writing on one of the other objects (the third shouldn’t have either of those disabled anyway).

I’ve tried printing out all relevant-seeming attribs applied to its immediate branch of the scene-graph.

I’ve also looked at it in PView–and I note that this render-issue persists there, so the problem is presumably not related to my shaders.

So far nothing has revealed why it’s rendering in this way, nor had any clear impact on how it renders with respect to the other objects.

I’m really not sure of how else to diagnose what’s going on here–does anyone have any suggestions…?

(Is there some way to examine how and why objects are being rendered as they are…?)

[serega-kkz]

I think maybe it’s just attached to a node that was added earlier to the graph.

DirectButton parenting issue

Based on a quick test, serega would seem to be correct: The issue isn’t that the button isn’t being rendered, it’s that it’s being covered by a huge DirectFrame that happens to have a grey colour, and which thus looks like the default clear-colour. Parenting the DirectFrame to the “a2dBackground” node just forces it to be “behind” the button, thus not covering it. This can be seen by taking the code from the example labelled “wrong”, and replacing the alpha-value of its frame-colour with a va…

[Thaumaturge]

The thing is, the object has depth-writing enabled, and at least one of the other objects–those that are rendering “over” it–should have depth-testing enabled (since it can be occluded by level-geometry). As such, even if the problem object was placed into the scene-graph earlier, it seems like it should render “over” the other objects just due to the depth-buffer… :/

Actually, that’s a thought: I should display the depth-buffer…

And doing so… well, this is odd. It looks like the object isn’t writing to the depth-buffer! Or at least, it’s not showing up.

This despite the following line of code:

effect.model.setDepthWrite(True, 1000)

Even if there were something else in the scene-graph above or below it setting depth-write to “False”, that override value should, well, override that setting!

[rdb]

Here’s a thought: is there transparency enabled on either of the objects? That will change the bin it’s (partially) rendered in.

You might want to try enabling depth writes on the object that is supposed to go in front so that objects rendered after it will not overwrite it.

Otherwise, if you can replicate it in pview, perhaps you can share the model with me?

[Thaumaturge]

@rdb

Here’s a thought: is there transparency enabled on either of the objects? That will change the bin it’s (partially) rendered in.

At least two of the objects–the one that’s ending up “behind” the other objects, and one of the objects that it is “behind”–does have transparency enabled, I believe. The third object I’m not sure about without checking.

That said, the objects should all be at least under parent-nodes that are assigned to explicit bins, which bins should all have a sort-order higher than that of the default “transparent” bin.

I did quickly try explicitly assigning the “behind” object and one of the other objects to the same bin as their parents, but doing so had no effect.

@rdb

You might want to try enabling depth writes on the object that is supposed to go in front so that objects rendered after it will not overwrite it.

Likewise no effect, I’m afraid. :/

@rdb

Otherwise, if you can replicate it in pview, perhaps you can share the model with me?

I’ll take a look at doing so, I intend.

I’d rather not use the actual models, ideally, but if I can perhaps replace them with stand-ins, place them in a simple scene, and then use “writeBamFile” to create a single PViewable model, that might work…

[Thaumaturge]

Update!

Okay, so, attempting to build a minimal demonstrative sample led me to investigate further–and that has led me to what appears to be the source of my trouble.

Specifically, it looks like the primary cause of the issue was that I was setting depth-testing to “False” on the object that was appearing “behind” the other objects!

I did also discover that one of the other two objects had both depth -testing and -writing disabled, which was causing that specific object to render over the first object–but that doesn’t explain the case of the third object, which should not have had this issue, I believe.

(I have now re-enabled depth-testing for this second object.)

I really don’t understand why the disabling of depth-testing on an object should cause that object to render “behind” others. If anything, I’d expect it to have the opposite effect, as without depth-testing the object should just render regardless of occlusion by other objects.