Adding visual grouping to scene tree

[Alfredoes234]

I think that it would be really cool if you could group the nodes in the scene in a more visual way to reduce visual clutter from more packed scenes and makes it at least in my opinion less confusing. Such as used in design software such as this image.

But I am interested to hear other peoples opinions and reasons why the current method visually works or doesn't.

[Meorge]

I'm not sure how what you used here as an example differs from Godot? This sounds like it'd be the equivalent of having a Node with children in it.

[Alfredoes234]

It's because if I make say I have a bunch of coins and I want them to disappear when they are collected if I put it in a node with a coin being the top node then it will get rid of all the nodes in the tree but I don't want that whereas grouping would allow them to be collected individually whilst being part of a a collective. Technically I could order it using a blank node but I feel that grouping would make sense because that is all you are doing and there is already grouping but not visually.

[Meorge]

If you have a coin scene, you could just place instance of it as children of your world scene, and then have a script on the coin that runs queue_free when it's collected to destroy only itself without destroying any other coins.

If you want a way to find all of the coins in your world, you may want to look into groups.

Other than that, I think using a blank "coin container" node that you make all coins children of would make the most sense. Keep in mind that the node hierarchy shown in Godot's editor is important for things like execution and drawing order; it's not just there for organizational purposes on the user side.

Providing ways to change the visual tree's hierarchy while keeping the underlying node structure the same would likely lead to confusing behavior. Users may not understand why their game logic isn't executing in the expected order, when it's because they're viewing it in "visual mode" versus "actual mode", if that makes sense.

[Alfredoes234]

I did not mean to suggest messing up the hierarchy but as I said in reply something similar acting to a blank node that maybe hooks into the pre-existing group system could be quite cool. As I don't think that mess anything up to do with hierarchy because it would still execute in order and I feel it makes more sense visually rather than an indicator on each individual node in the group as shown below. But I could potentially see an issue where you don't want to group the same thing hierarchically and that would be hard to figure out.

[Alfredoes234]

Or in the groups node section you could have a tree showing all the items in the group with items you can click on and will take you to them. keeping the functionality without making it more complex. Basically a little UX.

[theraot]

What I'm understanding is that you do not want to use a Node or a Node2D/Node3D because it lacks semantics. You could make a new class for that, all it need is a name, and I bet you want an icon:

@icon("node_group.svg")
class_name NodeGroup extends Node

Or extend Node2D/Node3D.

[sancho2]

I believe what he is asking for is similar to regions in the code editor.
Simply a foldable area to keep a set of scene nodes.
Maybe a better analogy is layer groups in GIMP. It does nothing but collect a large number of layers under a single banner freeing up space in the layer window.

You can use a node to do this but then you gain the overhead of the parent node that does nothing as well as an additional path step.

The idea has been asked for before and (imo) it really is a good one. A large scene can contain 100 nodes but most of the time you are working on a handful and you end up having to scroll back and forth through a bunch of nodes.

[theraot]

The node might be better for performance depending on what you are doing. And while I see the path argument, usually people who have a lot of instance and want to group them this way are not refering to them by path.

The parent node might have other benefits, for example it would be trivial to ask it the number of children to get a count of the instances, So it becomes an obvious place to manage them if you need to spawn or keep track of them dynamically.

[sancho2]

1 node and 1 path step not a big deal.
Multiple nodes and multiple overlapping or intertwined path steps, yeah a pretty big deal.
And there are some plug ins that add two dozen nodes to a scene that are never to be worked on.
Many that need to be placed where get_child() or get_parent() can get to them without an intervening node.

[theraot]

One thing those plugins could do is adding scene instances.

With that said, perhaps Godot could use a way to hide nodes in the tree (while still saving them with the scene). Not folding, but more like a permanent filter. Addendum: That you could toggle on and off, of course. Addendum 2: Perhaps it could piggyback on node groups.

[sancho2]

There is one additional negative to using nodes to do this.
The children of a node get their position relative to their immediate parent so the user would also have to manage that aspect.
Filtering could work so long as it could filter multiple node names/types; a filter list applied to the scene perhaps.

[theraot]

In engines that have a group function, I've seen it used to group objects that belong to the same zone. And that's frustrating if you want to move the zone as a whole. At least saving it as a scene would fix that problem in Godot. However, I'm worried that a group function will be misused in a similar way.

If we want to group by zone, a parent node that can be used to move the zone as a whole is good. The use cases where that's not desirable is when we have nodes that are of a common type but span different zones. I think the metaphor of a layer is a good fit for that.

The filter idea I was talking about is of course inspired by the filters Godot has. At first I was thinking you could have a list of saved filters... But now I'm thinking a function to hide groups of nodes directly from the scene tree would work. So you can add the nodes you want to hide to the groups you hide. The advantage of these would be that they don't add a ghost object to the scene tree or have any impact on runtime.