Nested Node categories in the scene tree

[fire]

Describe the project you are working on:

3d game project.

Describe the problem or limitation you are having in your project:

Nested nodes are hard to understand

Describe the feature / enhancement and how it helps to overcome the problem or limitation:

Create series of icons that lists the type of the nodes and its count.

Clicking will give a menu sorted by alphabetic? recency? tree order?:

• Search text field
• Node 0
• Node 1
• Node N

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

• Add a section aligned at the end of the scene tree section.
• Start a list of the most popular categories and count the instances.
• Display the count.
• When the icon is clicked on show the search
• Add a way to click to go to the node from the search.

If this enhancement will not be used often, can it be worked around with a few lines of script?:

This is an editor feature and is expected to be accessible to new developers.

Is there a reason why this should be core and not an add-on in the asset library?:

Downloading the asset from the library means you'll need to explain the asset store and that is not common for new developers.

[fire]

People who are confused, can you write more about why it's confusing?

[bojidar-bg]

I think the usecase is a bit confusing for this issue: It is not clear-cut why "Nested nodes are hard to understand".

Myself, I haven't had trouble seeing that a node with children nodes is collapsed. If this is tripping some people up, maybe the collapsed icon can be made more prominent and obvious?

Another thing that might be confusing is the relation between the usecase and the solution. Is it necessary to add a searchbox, long menu, node count, and "most popular categories" to the tree icon? If so, why?

[fire]

The enhancement is the ability to go to a specific node in the tree and sorting it by type.

The filtering enhancement in the other proposal is one way of searching for a node, this is another proposal for searching for a specific node.

Let me compare the two approaches.

In the other proposal, we only display the nodes that are of a certain category. You have to scroll / type in the name to filter enough nodes to find the node.

In this proposal, we at a parent node show the categories as an icon and a count. We're using mesh instances in this example. At a glance we can see how many mesh instances are in the children. Perhaps we can use the same filter tree as the filter proposal, but I think the ability to click on the icon and have it set as the filter (proposal) would remove the extra search box.

So a revised proposal is that you would have categories on the right side (with count), but clicking on them will set it as the filter category. The filter search box will be as implemented as previously in stable Godot Engine.

How does that sound? It'll look exactly the same as the mockup.

[Zireael07]

Ooh, clicking them to set them as filter sounds like a great QoL feature!