Draw priorities?

Please have a look at this file

drawpriorities.toe (4.42 KB)
/geo/bg has draw priority of 1
/geo/text1 has a draw priority of 2
/geo/someContainer/text1 also has a draw priority of 2

Changing draw priority of /geo/text1 makes it draw in front or behind the bg (as expected)
But if you change the draw priority for /geo/someContainer/text1 it has no effect on the render.

Couldn’t find an answer in the wiki. Can some please explain why this behaves that way?

Thanks!
Achim

And another example

anotherexample.toe (4.27 KB)
Please create a geometry (/geo2) node and delete the default sop
Then copy /text1 into the created /geo2

/geo2 is drawn behind /geo1

Now save and reopen the file

/geo2 is drawn in front of /geo1

Bug?
Achim

For your first example: Draw Priority is hierarchical. So in your example, /geo/text1 will get drawn first. That means ALL of /geo/text1’s children get drawn. If there were more COMPs inside /geo/text1, their draw priority affect how they are drawn vs. sibling COMPs, but not other COMPs elsewhere.
Next /geo/bg/* gets drawn.
Then /geo/someContainer/*.

COMPs that don’t have a Draw Priority parameter (like most Panel COMPs) have a draw priority of 0.

So changing the draw priority of /geo/someContainer/text1 will change how it is drawn vs. other nodes in /geo/someContainer only.

It’s a toss up if this method is better than a ‘flat’ method where every node’s draw priority is compared to every other node. There are benefits to both methods. If you feel on that the flat method is far more useful please let me know why and I can look into changing it or making it an option.
There is a short section on Draw Priority in the Transparency article in the wiki if you want a longer description, but ya, it needs it’s own article for sure.

For the 2nd example: Yes this looks like a bug

1 Like

Didn’t know that panel COMPS automatically get a draw priority of 0. Now it makes sense.

Every to every is probably more expensive and, as far as I understood, not necessary. And you would loose the ability to “move” a whole subtree. But instead of given an auto priority of 0 to panel COMPs, it could use all geo COMPs found inside those panel COMPs for comparison with the geo COMPs directly found in the current render string. That’s not the same as your mentioned ‘flat’ method, is it?

It would give more flexibility in organizing your geos inside containers, without affecting their draw priorities. So if the render TOP’s renderstring is “/geo /geo1” , then

/geo and /geo1 priorities would be compared, and inside /geo

/geo/text1
/geo/bg
and
/geo/somecontainer/text1
would get their draw priorities compared.