Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a property to make a node visible only in the editor or in the running project #3433

Open
Calinou opened this issue Oct 15, 2021 · 20 comments · May be fixed by godotengine/godot#56446
Open

Comments

@Calinou
Copy link
Member

Calinou commented Oct 15, 2021

Describe the project you are working on

The Godot editor 🙂

Describe the problem or limitation you are having in your project

Making a node effective only in the editor (or only in the running project) currently requires using a script.

There are a few exceptions to this (such as Light3D with its Editor Only property), but I feel a more generic solution is needed here.

#1835 didn't address this, since it was about disabling nodes both in the editor and running project.

This proposal is only about node visibility, not processing. If you wish to avoid unnecessary processing in nodes when they're hidden, use if is_visible_in_tree() to early-abort in your script's _input()/_process()/_physics_process() functions.

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

Add a property to make a node visible only in the editor or in the running project.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Add a property to Node2D, Node3D and Control that controls visibility depending on the current engine operation:

  • Editor and Runner
  • Editor Only
  • Runner Only

Since this toggles visibility, parents' properties are implicitly inherited.

Light3D's Editor Only property can be deprecated (and hidden from the inspector if it's false) after adding the above property.

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

This can be worked around in at least two ways:

  • Attaching a script to nodes that should only be displayed within the editor or running project.
  • Using an autoloaded script by adding groups to nodes that should only be displayed within the editor or running project.

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

Since making nodes visible only in the editor or running project is a relatively common operation in a polished game, it makes sense to have this as a core feature.

@Zylann
Copy link

Zylann commented Oct 15, 2021

It should be noted that the proposal says "to make a node not visible in a game". That is, it seems to revolve around the idea of hiding such nodes at runtime, means they will still be there. So when the property is called editor_only, it could be misunderstood. When the intent is having a node editor-only, the ideal result (or at least meaning) would be for the node to not even be in the exported game. Because it's not just about it not being visible: a hidden node can still occupy resources, CPU, GPU, a place in the tree, a place in the rendering culling data structure, take time to be created if still present when instancing scenes etc.

If using solely "visibility" is really what is wanted, then it should be precised that the node will still be there. I would be interested in having such nodes stripped on export, but maybe other people want the node to remain present.

@berarma
Copy link

berarma commented Oct 15, 2021

Thanks @Calinou.

An option to completely remove the node at runtime would be nice. Sometimes we will want optional visibility, this can be easily accomplished with code, but sometimes it might be useful to ignore "editor-only" nodes completely and that's not totally feasible. We can remove the node only after it has been loaded and has taken resources up.

Maybe it should be called conditional_visibilityor something that implies it only affects visibility. editor_only would be more appropiate for the node removal option if it got implemented some day.

@MaaaxiKing
Copy link

What about replacing the eye by a drop-down list with these three options?

@Calinou
Copy link
Member Author

Calinou commented Oct 16, 2021

What about replacing the eye by a drop-down list with these three options?

Being able to toggle visibility with a simple click is important, so a drop-down menu wouldn't be a good idea here. (Unless you're referring to displaying a drop-down menu only when the user right-clicks the eye icon, that is.)

@MaaaxiKing
Copy link

That was not my initial idea but I find it great.

@gaudecker
Copy link

I played with this idea a bit.

In my take the editor_only nodes are discarded during scene instantiation. I'm not sure how much allocations are made before this point for the node, but this was the earliest point I could find where I could intercept it somehow.

In my opinion, "runtime only" nodes are not that common, and can be trivially implemented by instancing in gdscript, or by hiding using is_editor_hint().

My implementation: gaudecker/godot@daaf711

@Calinou
Copy link
Member Author

Calinou commented Mar 20, 2022

@gaudecker Out of curiosity, did you see godotengine/godot#56446?

In my opinion, "runtime only" nodes are not that common, and can be trivially implemented by instancing in gdscript, or by hiding using is_editor_hint().

I agree this can be done trivially with a script that sets visible = true in _ready(). That said, for emitting particles or shaders that use TIME, these nodes need to be hidden to prevent the editor from constantly redrawing (unless godotengine/godot#53463 is enabled). godotengine/godot#53463 hasn't been forward-ported to master yet; if it ends up being ported, then I guess there isn't much of need for runtime-only nodes.

@gaudecker
Copy link

gaudecker commented Mar 20, 2022

@gaudecker Out of curiosity, did you see godotengine/godot#56446?

I did find it right after I posted the above comment. 😁

It seems to have the same approach.

@ztc0611
Copy link

ztc0611 commented Mar 30, 2022

This would be incredibly powerful for all kinds of creation, fixing several potential problems in my opinion. I think it can be more powerful than it might appear at a glance.

This fixes some unique problems for me that aren't solved by hiding.

  1. I use a sprite to mark entrances/exits in my game, and sometimes the _ready() script that is supposed to hide them immediately can fail on the first frame. (This is usually a Mac exclusive fullscreen issue, but regardless.)
    image
    [The A/B sprite nodes are purely for my benefit and have zero use to be in the game executable.]
  2. I frequently make "scenes" to instance which are just Sprite/AnimatedSprite nodes, and it is frustrating to preview them as by default they appear in the top left corner of the "Play Scene" view. Moving them to the center of the default camera position would cause them to be placed incorrectly when later instanced. I could add a Camera2D to fix this, however that would cause every instanced version of it to have either a Camera2D node bloating things for no reason, or I would have to waste performance queue_free()-ing the Camera2D every single time I instance it. Editor only nodes would let me use this without worrying.

@Calinou
Copy link
Member Author

Calinou commented Mar 30, 2022

I use a sprite to mark entrances/exits in my game, and sometimes the _ready() script that is supposed to hide them immediately can fail on the first frame. (This is usually a Mac exclusive fullscreen issue, but regardless.)

Using set_deferred("visible", false) instead of visible = false might work in this case.

Also, is that macOS issue reported somewhere already?

@ztc0611
Copy link

ztc0611 commented Mar 31, 2022

Also, is that macOS issue reported somewhere already?

Upon further testing I'm unsure if it actually is a bug. I just submitted it anyways in case it technically is. godotengine/godot#59743

@me2beats
Copy link

me2beats commented Apr 1, 2022

If an "Editor only" node will be still in tree, that means I want to make it visible sometime during the game. Or idk why I want it in the tree.
So I'm not sure if the feature should be only about visibility of the nodes.

@berarma
Copy link

berarma commented Apr 1, 2022

If an "Editor only" node will be still in tree, that means I want to make it visible sometime during the game. Or idk why I want it in the tree. So I'm not sure if the feature should be only about visibility of the nodes.

Sometimes I use nodes as anchor points. The game uses their position and maybe some other property but without being visible. In the editor I want to see them and move them around. This is very useful to change the behavior of the game and entities in a visual way.

@me2beats
Copy link

me2beats commented Apr 1, 2022

Sometimes I use nodes as anchor points. The game uses their position and maybe some other property but without being visible. In the editor I want to see them and move them around. This is very useful to change the behavior of the game and entities in a visual way.

Doesn't tool + Engine.is_editor_hint() solve that?

@me2beats
Copy link

me2beats commented Apr 1, 2022

Also it seems this property becomes useless as soon as the game starts.
though this is most likely a minor issue.

@me2beats
Copy link

me2beats commented Apr 1, 2022

And it solves only a particular problem — node visibility.
The solution could be more general.

Looks like the more general problem is that we want something like tool+Engine.is_editor_hint() but more declarative, that could be set up right in the editor, without code.

@Flynsarmy
Copy link

Unreal Engine has this feature. In addition to the 'Visible in game' checkbox (equivalent of our 'Visible' checkbox) they also have 'Visible in Engine'. Having both checkboxes allows you to see everything in your scene while developing, but have it hidden by default as the game fires up without need for a script to do it. Very convenient.

@Flavelius
Copy link

Even unity has an EditorOnly tag that marks objects as stripped from builds, maybe godot could use its groups for this too (a special Remove/StripFromBuilds group or similar). This would atleast not require another property on objects or more checkboxes.

@Calinou Calinou modified the milestones: 4.0, 4.x Feb 3, 2023
@stephanbogner
Copy link

This would be a great feature.

To add to the list of how it can be useful:
I have a node that emits water particles. I added a blue arrow so I can easily see in which direction it shoots out the water and I delete that arrow onReady (so in my case it's a node I don't need at all when running the game).

Screenshot from 2023-05-18 19-33-39

@sun-studios
Copy link

sun-studios commented Aug 22, 2024

I would use a feature like this endless, as I do currently in Unity, and almost all creative applications. When I'm designing, it's very useful to be able to toggle the visibility of objects in the editor. For environment design, I may want to turn off groups and clusters of trees, fog, grass ect so I can work cleanly with objects that I wouldn't otherwise be able to directly select with ease.

Now I could easily add these objects into groups and toggle the visibility in the editor with the 'eye' icon on the scene panel.... but the issue is that I have to turn them back on otherwise they are hidden at runtime. The impact this has on time (particularly for designers) is immense overtime, and it means I cannot work quickly across multiple scenes. In a fast paced working environment, I will easily leave objects hidden when working across multiple scenes. I must be conscious and very mindful when using the visibility toggle as to not leave a 'leaf unturned'. If my job is solely designing, it is very difficult to be effective across multiple scenes, going in and out making edits.

image

Simple example: It would just be nice to be able to toggle the visibility of some of these trees so I can shift some of the yellow ones, or access an object that is hidden in the forest.

Blender handles this nicely:
image
The eyeball icon toggles editor visibility, while the camera icon actually disables the object for render.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet