Godot: Reverse render order of nodes.

[aspenforest]

Currently, the ordering of nodes in the scene manager window and the rendering
visible on the main editor window are contradictory to each other and counter-intuitive.

If I see layered Control nodes partially occluding each other on the screen, I would expect
the top-most visible node to be the top node in the nodes hierarchy, as that would make
perfect sense: top in the nodes list = top visible in the editor window.

Currently it's set up in the reverse order.
The top-most visible UI control element is listed at the bottom of the nodes hierarchy.

I mean, I can understand that it's because the nodes are rendered on screen from
top-to-bottom in the nodes list, but that's counter-intuitive, because what my eyes see
in the editor window compared with what's in the node list window is contradictory.

It would help new users a lot if the editor was actually intuitive to use.

[bojidar-bg]

Duplicate of (archived) #8163?

[mindinsomnia]

I understand Reduz's answers but at the same time I think OP in this issue and the duplicate have a point.

The "top" rendered object in 2D is the "bottom" object in the list of nodes. From a designer's POV, that doesn't make much sense. In any other visual application, the order of the nodes would be the highest element in the list of elements would be rendered on top of the lower elements.

Changing this would just mean changing visually in the UI how things are ordered, not changing how things are ordered internally.

If it's possible to change how this looks visually, I think it's worth trying. Does anyone want to give it a go to see if it's possible to do this?

[Zylann]

Doing such a change on a deep level will break all games built with Godot, the editor and assumptions everyone else has too when working with nodes, so I'm also with Reduz on this. Because Godot is not just a drawing program, the internal order of nodes may matter for other things. So yes, what happens internally is different from drawing programs, and the editor just reflects this. It also makes sense when you consider that a parent is drawn by default behind its children as well, and there is eventually a Z order property to invert this manually. You could maybe even use a node like YSort node but working with tree order?

If this is too confusing, I think a compromise would be to have an editor option which reverses the order of nodes as they are displayed in the scene tree editor. So within a list of child nodes, node 0 would be at the bottom, and node N would be at the top, while internally nothing would change, which does not break compatibility and developpers expectations while being relatively easy to implement in Tree UI (like @mindinsomnia said).
It could end up being confusing still, but that's a convention, just like the choice of 3D axis with Z being backwards and Y upwards. They might be annoying but people get used to them, they are not a real issue once you get on with your game, and changing them on a deep level would be a real hassle.

[aspenforest]

Major engine update versions are expected to somewhat break
backward-compatibility, The upcoming 4.0 version would be an ideal
opportunity to implement this feature. Although, I must concur that an
option to toggle node render order would be a versatile compromise solution.

On Sat, Jul 6, 2019, 17:30 Marc [e-mail] wrote:

Doing such a change on a deep level will break all games built with Godot,
the editor and assumptions everyone else has too when working with nodes,
so I'm also with Reduz on this. Yes, what happens internally is different
from drawing programs, and the editor just reflects this. It also makes
sense when you consider that a parent is drawn by default behind its
children as well, and there is eventually a Z order property to invert this
manually.
If this is too confusing, I think a compromise would be to have an editor
option which reverses the order of nodes as they are displayed in the
scene tree editor. So within a list of child nodes, node 0 would be at
the bottom, and node N would be at the top, while internally nothing would
change, which does not break compatibility and developpers expectations. It
could end up being confusing still, but hey, that's a convention, just like
the choice of 3D axis with Z being backwards and Y upwards. They might be
annoying but people get used to them, they are not a real issue once you
get on with your game, and changing them on a deep level would be a real
hassle.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/30376?email_source=notifications&email_token=ABVAJRACMCWT4QBE3XF5OWDP6CT7HA5CNFSM4H6TD4BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZK2UBI#issuecomment-508930565,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVAJRHDDQFS77XGN24325LP6CT7HANCNFSM4H6TD4BA
.

[Zylann]

I don't know how that could be done in the renderer tbh, but again, having that kind of feature as an option at deep level would really break everything, even if 4.0 is supposed to break stuff. If someone provides an addon and you have this option in your project, the addon won't work anymore. The editor itself might not even render properly because all things being drawn backwards. And that would require someone available to do such work.

To me, the only good and simple solution to this is to reverse the way in which nodes are drawn in the Tree in the editor for pure convenience, because that's exactly what drawing apps do anyways (as I understand it, that would be an artist need?). There is no point changing everything else. That means it could even be done for 3.2 by anyone more or less used to how UI nodes work ;)
And if no other simple solution is found, then just getting over it is a good way to keep things simple and focus on more important problems IMO.

[mindinsomnia]

I think you're 100% on the money Zylann, no internal code needs to change at all really. Somewhere in the code for Godot's Editor UI, there must be something that is sorting the order of nodes to display in the scene UI element that displays the nodes of a scene in the editor. I guess all that's needed is just an option to reverse that order, it would be basically a cosmetic visual change for the UI just to make the UI match the conventions of other applications.

[clayjohn]

Keep in mind, this should be completely optional, and only available for 2D. For 3D it makes way more sense to order by draw order. Reverse draw order would be confusing and provide no benefit in 3D as depth is handled separately from draw order. However, to optimize certain scenes you may want to control what order objects are drawn in.

[bojidar-bg]

and only available for 2D.

If it is an editor setting which just reverses the order in the scene tree, I see no problem with it being reversed in both 2D and 3D. Indeed, since draw order is independent of node order in 3D, it would make no problem for nodes to be arranged either way.

That being said, it would be nice if the SceneTree displays the fact that nodes are reversed in a somewhat-prominent way, so that when people asking for help share screenshots, helpers aren't thrown off by the node order.

[KoBeWi]

Having order reversed only visually isn't that straight-forward either, because we'd need to mirror all the operations on scene tree. E.g. Ctrl + Up/Down would do opposite things.

[Mantissa-23]

Regardless though it'd be a change made purely to the UI and I/O handling, and there'd be no reason not to include it as an optional project setting.

[girng]

please no omg
edit: i don't mean for this to come off as a non-quality comment, but seriously you also don't want to hear me whine/complain at how this could break so many things, so i just kept it short

[groud]

I don't think this is a good idea, for the following reasons:

• the children should always be drawn on top of their parents, so in a hierarchy, the deepest node is drawn last,
• this means that if we reverse the children nodes drawing, instead of having a simple "lowest node in the tree view drawn last", we're going to have mixed rules depending on whether the nodes are on the same level of hierarchy or not.
• This can be solved by putting the root node at the bottom, and added children would stack on the upper part (completely reverse the tree view in fact), but it means that something like get_child(x) is going to count children from bottom to the top, which is the opposite of a natural behavior.

So basically, for me it does not make any sense to change this behavior. And it is also going to be a pain to maintain two systems. It is definitely not worth the trouble.

[aspenforest]

@groud comment explains exactly why I suggested it as a reversal of render order, not just purely cosmetic visual change in the nodes list window.
The tree functions (init, ready, etc) should still flow from parents to children and in the nodes list window still maintain the visual order of parents at the top and children at the bottom, so the flow of code is from the top to the bottom.
One thing to bear in mind though, that I read somewhere here about the need to change this for C# users, so that the code "bubbles up" instead of flowing down. It had something to do with how C# itself is designed. Unfortunately, I can't find the link to that issue so if somebody can find it, it would be very helpful.
So my original proposition stands: In 2D, code flows from top to bottom and nodes are rendered from top to bottom behind the previous Control element, not stacked on top.

[groud]

As I said in my first point, your solution makes things even more confusing. As the children will always be drawn on top of their parent (that cannot change, the opposite does not make sense). If you reverse the order 2d elements are drawn as children of a given node, you break the "last in the tree (linearly from top to bottom) last drawn". Which is confusing.

[mindinsomnia]

I think the difference here is, one order makes sense from a programmer's perspective, while the other order makes sense from a designer's perspective. From a programmer's perspective, it makes sense that the last child of a node is drawn last, from a designer's perspective, it makes sense that the "thing at the top" is drawn on top of everything else.

[aspenforest]

Should Godot be directed towards programmers or designers, or both?
If we think in the terms of game design companies with multiple employees
with different duties and backgrounds,
would it not serve the effectiveness the most, if the editor could mold
itself somewhat to fit the thinking process of the person using it?
It would lower the difficulty curve for workers who do not necessarily
think like programmers.
It's far harder to force someone to change their way of thought than
implementing workflows which enable and support it.

Hence, perhaps it would best serve all developers of different backgrounds
the most, if it would be possible to
separately change the order of processing and also the order of rendering
graphics 2D?
Therefore, it would not matter if you're programming in GDScript or C# or
what have you, you could tailor the workflow
to whatever suits best for the language you are using, to what rendering
order suits the dev the most.

To achieve this, I propose two additional toggle options in the project
settings window:
1) Flip node processing order. I don't know how Godot knows which node to
process next, but I would assume
it has something to do with iterating over node references in an array. If
that's the case, then just change the order in
which the array is accessed.
2) Visually change the order in which the nodes are displayed in the node
list window.

With these two settings, its possible to achieve whichever processing and
"render" order the dev feels fits him the most.

On Sun, 7 Jul 2019 at 11:07, mindinsomnia [e-mail] wrote:

I think the difference here is, one order makes sense from a programmer's
perspective, while the other order makes sense from a designer's
perspective. From a programmer's perspective, it makes sense that the last
child of a node is drawn last, from a designer's perspective, it makes
sense that the "thing at the top" is drawn on top of everything else.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/30376?email_source=notifications&email_token=ABVAJRDSXROOSASBSJMRNIDP6GP4NA5CNFSM4H6TD4BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZLGWNY#issuecomment-508980023,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVAJRBRC3XVV5PVI2CAPSTP6GP4NANCNFSM4H6TD4BA
.

[groud]

Sorry, but this won't happen. It's a lot easier for people to get used to a fixed way of doing things than allowing them to customize such cosmetic settings, especially because of all documentation and learning materials that will contradict each other. So such thing as an option won't happen.
Not mentioning the maintainance cost.

[KoBeWi]

Should Godot be directed towards programmers or designers, or both?

I am both. Somewhat. I use Godot and GIMP and it never felt counter-intuitive to me that one does sorting different than the other. So there are people like this too.

[aspenforest]

Well, I think I'll close this topic, as the discussion has proved that the render order change is highly unlikely to happen.