If the Godot4 user runs a scene with no Light or Environment, run the scene with the Editor Viewport Directional Light and Environment

[golddotasksquestions]

Describe the project you are working on

This applies to any Godot4 3D project.

Describe the problem or limitation you are having in your project

When running a 3D scene which is not the main scene or a level, the scene looks vastly different from the Editor viewport and Godot4 users can't see anything. (Edit: When pressing the play scene button or F6 in the Editor!) Edit2: Two community examples from just this week: https://www.reddit.com/r/godot/comments/yxkcs1/how_to_view_individual_scenes_in_godot_4_ive/ https://www.reddit.com/r/godot/comments/yy12dn/3d_model_looks_ugly_while_debugging/ Edit3, more: https://www.reddit.com/r/godot/comments/13pnf0b/instantiate_in_40_is_driving_me_crazy_please_help/ https://www.reddit.com/r/godot/comments/1ah14xx/scene_appears_in_black_when_i_run/

Editor viewport:

Running scene:

This is different compared to Godot3.X where the running scene would get the same default environment like the Editor viewport if there is no custom Environment present in the scene. This means even though there is no default DirectionalLight in Godot3.X, at least I could make out more than a silhouette of the object in my scene when I run it.

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

Add the Editor viewport DirectionalLight3D and WorldEnvironment to the running scene if there is no Light or custom Environment.

Same behaviour as clicking the Toolbar Preview Dialog buttons: "Add Sun to Scene" and "Add Environment to Scene".

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

See above

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

It's a usability feature which needs improvement. Workarounds don't improve usability.

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

Same reason as above.

[Calinou]

The preview sun and sky system is designed to be just that: a preview. It's not designed to be relied upon in final projects. It's not even saved to project.godot, so there is no way this could work in an exported project anyway.

Instead, we should print a warning on startup if the scene tree contains at least one node inheriting from Node3D and there is no node that inherits from WorldEnvironment or Camera3D in the current scene tree. (To handle deferred initialization, this should happen after a small delay such as 3-4 process frames.)

[YuriSizov]

I think it's fair to expect a little bit of a setup when making your project. Sure, it will hinder quick experiments a bit, but that's solvable by having your favorite scene preset stored somewhere and reused. Any real project would need to configure their own environment and camera to their liking, art direction, game design choices. I don't see much point in trivializing the initial setup, as tutorials can cover the requirements, and as mentioned we can fire warnings when applicable to help guide first-time users.

(same applies to #5801).

[golddotasksquestions]

@Calinou

I don't understand. Where is the problem of saving that preview WorldEnvironment and Directionallight as nodes and adding them to the scene automatically when I press F6 in the editor or the play scene button? I can do this manually. Why can't this be done automatically if there is no Light and Environament in the scene I am trying to run when clicking here

@YuriSizov The point of this has nothing to do with Art Direction. Its about NOT do additional work, but the bare minimum of usability. To be able to at least have the same level of userfriendlyness as Godot3 and be able to see your scene by default when you run it like in Godot3. Godot4 is a regression in this aspect.

[YuriSizov]

The point of this has nothing to do with Art Direction. Its about NOT do additional work, but the bare minimum of usability.

You're missing my point. I'm saying that any project would need to configure this stuff for themselves anyway (with art direction being one of the reasons to do so, but not only). As such having a default environment adds nothing of value, except giving a little boost for temporary projects and test scenes. Which is not the main goal of using a game engine, so it's not a big deal.

[golddotasksquestions]

No Yuri, you are missing my point. Please read the proposal again. This has nothing to do with art direction or existing WorldEnvironments and Lights in any project.

This applies when you try to run a scene independently from the "main scene" by pressing F6 or the above "play scene" button. Think enemy or player characters. Think items, weapons, bullets, vehicles. Anything you want to run on it's own for testing.

This is part of a normal development procedure and actually one of Godot's main selling points: You can run any scene on it's own as long as you encapsulate it properly.

But in Godot 4 the issue is, you always have to manually add a WorldEnvironment and Light in order to test-run your scene, because otherwise you can't see shit!

What is worse is how you then also have to always remove those Lights and WorldEnvironments before you play that subscene in your one of your other bigger scenes (like the map, level, inventory etc). It's super annoying and cumbersome and a massive step down in usability compared to Godot3 which was not pretty (because no default DirectionalLight) but at least useable for that purpose.

[Zireael07]

Anything you want to run on it's own for testing.

This is part of a normal development procedure and actually one of Godot's main selling points: You can run any scene on it's own as long as you encapsulate it properly.

Agreed +100, I am doing this quite often

[YuriSizov]

@golddotasksquestions I see your point, but your ability to configure a default environment didn't go anywhere.

Admittedly, you do still need a camera (but that's also a problem in Godot 3, even in 2D, which is eh... a pain point, just not a new one). And you still may want a sun or other light source. Calinou is correct, though, that if we were to somehow replicate the preview settings for those, it would create inconsistencies between the debug run and the exported run. So I'm not really sure how we could improve that.

Not to mention, there is no good way to communicate the need to create specific nodes with specific settings to the debug instance.

[golddotasksquestions]

Calinou is correct, though, that if we were to somehow replicate the preview settings for those, it would create inconsistencies between the debug run and the exported run.

No, Calinou is not correct on this point. Since this has nothing to do with any exported project! This is about pressing the "run scene button or F6 in the Editor only. Exported projects don't have this play-scene button and don't have F6.

The fact that you can customize and configure the default environment does not help with usability, does not help beginners who get confused over issue, does not help with having no DirectionalLight.

[YuriSizov]

The fact that you can customize and configure the default environment does not help with usability, does not help beginners who get confused over issue, does not help with having no DirectionalLight.

You can enable SDFGI, actually. It decently replaces the need for a directional light.

No, Calinou is not correct on this point. Since this has nothing to do with any exported project. This is about pressing the "run scene button or F6.

That's because you're focusing on this being only about F6. But please consider a person starting a new project, setting up their scene with the preview environment and lights, running it with F6 and seeing exactly the same, then exporting the game and "not seeing shit", as you've put it. We're replacing one confusion with another, though I guess we can start arguing to death which one is worse.

[golddotasksquestions]

To enable SDFGI you have to add a WorldEnvironment or change the default environment.

That's because you're focusing on this being only about F6.

Yes, because this is where the issue is. As you and Calinou has stated, playing the whole project (play button, F5, or exported project)) this does not apply since a project may have any kind of art direction. Some might not want or need DirectionalLights or a specific WorldEnvironment. So it's a good thing to force users to set those things up for their project (as it is right now).

However even if the uses sets those up in their project, they still "can't see shit" when running a scene with F6 or pressing the "play scene button". They would also have to change and customize the default environment (which is likely not desirable if all you want is to test-run the scene). And even then it would still lack the DirectionalLight3D and the Camera3D (see https://github.com/godotengine/godot-proposals/issues/5801).

[YuriSizov]

To enable SDFGI you have to add a WorldEnvironment or change the default environment.

Yep. That means at least 2 of your 3 problems can be covered by the default environment, which, yes, you have to configure at least once this time around. Otherwise, this seems to be on par with Godot 3 (even better, I guess, since you don't need any light node with SDFGI).

Yes, because this is where the issue is. As you and Calinou has stated, playing the whole project (play button, F5, or exported project)) this does not apply since a project may have any kind of art direction. Some might not want or need DirectionalLights or a specific WorldEnvironment.

But you can run any scene directly, including the only scene, the main scene, which you would expect to behave the same when exported. So an inexperienced user may still get confused in a scenario such as the one I've described above. I think a warning is a must to indicate that you're running your scene without any environment, local or project-wide. Your proposal can work if we can make sure people understand that what they see is temporary and not a persistent part of their project. (Plus we need to somehow communicate to the running instance that specific nodes need to be inserted with specific settings, which is not trivial).

which is likely not desirable if all you want is to test-run the scene

I think it's a perfectly fine way to use the default environment. You can always override it per-level for the actual project content.

[golddotasksquestions]

Yep. That means at least 2 of your 3 problems can be covered by the default environment, which, yes, you have to configure at least once this time around. Otherwise, this seems to be on par with Godot 3 (even better, I guess, since you don't need any light node with SDFGI).

No, none of the problems I stated here are solved by changing the default environment manually.

1.: Because this would have to be done for every project, totally defeating the purpose of improved usability 2.: Because project settings are often totally obscure to beginners 3.: Like Godot3 the Environment alone does a bad job at lighting up the scene. Which is why the Preview has both DirectionalLight as well as a Sky Environment 4.: SDFGI is not enabled by default for a good reason: Because it tanks performance on low-end hardware.

All of these are a step down from Godot3 usability. Godot3 was not great in the regard of test-running a scene independently. Having to manually fiddle with the default environment or manually add scripts, add nodes or anything else to that effect is all stuff making the experience worse, not better.

Yes, a better general default environment for everyone would help. If the default environment would have the sky like it has in the Preview, we would at least be on par with Godot3. But I assume whoever decided to change the Godot3 procedural sky default environment for this solid grey default environment, did so for a good reason. So far I thought the reason might have been for make it more obvious one can and should add a World Environment to customize the the look of their game (a process which is also painful btw, but that's a discussion for another day). Given how awful the process of recreating something like the preview default environment, I really would not mind if the default environment which comes with Godot4 matches the preview.

I think a warning is a must to indicate that you're running your scene without any environment, local or project-wide.

Warnings are good for additional background information. What they are not is a good replacement for intelligent design and UI. Unfortunately in Godot, Warnings are misused all the time to replace good UI flows, sensible defaults and intelligent designs.

Instead of doing the most common thing for you, which would be sensible, Godot already hides tiny yellow triangles everywhere, which you then have to mouseover in order to learn "you have to this same thing a million times every time you want to proceede, or else what you did before will have absolutely no effect".

Not only is this lazy design, it's bad design! Instead for the user to change a sensible default only 3 out of ten times, they have to set the thing 10 out of ten times, every time!

If you and other core devs and contributors continue to push this mindset, what we will have (and what we already have in Godot for a lot of workflows, for example in the WorldEnvironment Sky) is running into stopper warning signs constantly on every flow, constantly asking the user to constantly do the same stupid clicks a million times a day for abso-fcuking-lutely no good reason. Be brave, make a decision on what would be a sensible devault, and adjust according to user feedback. It's not that hard.

So an inexperienced user may still get confused in a scenario such as the one I've described above.

They are also getting confused for the same reason right now just the same. This has nothing to do with my proposal here.

[YuriSizov]

Because project settings are often totally obscure to beginners

Everything can be obscure to beginners. Not everything can be compromised in a way that would be absolutely frictionless yet sensible for people using the tool professionally. Once again, the point of being user-friendly is not to trivialize everything. It's to lower friction where we can. With Godot being multi-purpose game engine, we can't satisfy everyone's needs from the first screen. There is going to be a learning curve, a time you are clueless and have to read help articles or follow tutorials. Things being obscure to beginners is an issue, but not a good enough reason for a change by itself.

You've been around long enough, you are no longer a beginner. You seek things that are convenient to you, and very often when others don't see it from your perspective you claim that they don't think of the beginners or ignore usability, or commit some other cardinal sin. The problem that you describe exists. Yet it can be worked around with a sensible approach, and it can be worked around in a way that you set it up and forget it. It's a nuisance at times, it can be a PITA. But I don't understand the need to get upset when people don't see it as critical, or think workarounds are okay, or just don't agree with your POV in principle. And I don't understand the need to extrapolate these different views into a critical problem with the project as a whole, painting it almost unusable and incomprehensible.

This makes it very hard to discuss the subject and take your comments with good faith.

---

Anyway, as I've said if technical issues can be resolved, and if we make it clear to the user that what they see is transient and not persistent, this suggestion of your could work.

[golddotasksquestions]

You've been around long enough, you are no longer a beginner. You seek things that are convenient to you,

No, often I create issue on things which have been a issue for me ever since I was a beginner. Now that I am no longer a beginner and know the ins and out and everything I would find out about the issue I have experience with it for years, I can open up a proposal saying "Hey guys, this is not me, this is has been a problem for long" here is an idea on how we could fix this. Never did I mention anything about this being critical. Stop insinuating I say or do things I don't do Yuri!

In this particualr case we are discussing here, it is about a regression in terms of userbility and user friendlyness compared to Godot3.

I get that most things have a good reason for why they are the way they are, but your solution of "lets make it harder for users to do discover and fix something manually which previously worked automatically", (by manually changing the default environment on every single project every time) is just not an improvement, it's a step down coming from Godot3.

[ptlthg]

I would personally like to see this added. It would be a nice QOL improvement for testing individual 3D scenes. I don't think keeping the lighting and environment should be enabled by default, though, I'd be happy with an editor setting for that. A hover menu on the world environment toggle button in the editor to keep when running would be nice as well.

Edit: I came here from #5801, didn't realize that this proposal doesn't mention the camera. Sorry about that, I've moved my comments concerning the camera to there.

[timothyqiu]

In 3.x, you always get a default_env.tres and it's the environment used when no environment override exists. For beginners, everything works out of box. They don't need to know the difference between default environment and preview environment. Just change that Environment resource.

In 4.0, the preview environment is enabled by default. So out of the box, what you see in the editor is different from what you see in the running game. For beginners, I think this is worse than 3.x. (Missing preview camera is a separate issue, here I suppose you click "Project Camera Override" to preview the scene.)

Some scenes should not contain its own environment override (e.g. a weapon scene, a wall scene). default_env.tres serves as the environment for editor preview and when running that individual scene. In 4.0, you can still create the default environment file manually, but that option is considered advanced and hidden by default.

When the main scenes' environment is not suitable for editor (e.g. very dark with fog enabled), a workaround is to put the environment on camera so the editor is not affected. But as a result, it makes it hard to see how the scene looks when running. This is the problem a separate preview environment toggle should solve I think. But unfortunately, in 4.0, the preview environment won't work when a WorldEnvironment exists.

[adarcher]

I'm confused why there is such a heated argument here. Please be more polite.

This change from 3 -> 4 is like the old joke of a Bank saying: "For the convenience of our customers we've removed all ATMs. You are welcome!".

I'm a beginner who's dabbled for a year or two and I definitely appreciated the default environment and lighting when testing prefabs. I just ran into this issue after using Godot 4; I thought I broke something and spent an hour looking for the setting.

Please bring it back, don't remove QoL.

edit: I'd like to add that I actually have no idea what the old settings and setup were. I'm wasting time trying to replicate what was given to me for free and my convenience in 3.x.

[Calinou]

Please bring it back, don't remove QoL.

The default environment option is still available in Godot 4, but you need to point to a default Environment resource in the Rendering > Environment > Defaults > Default Environment project setting. Make sure this Environment is saved to an external .tres file so you can point to it in that setting.

[adarcher]

Please bring it back, don't remove QoL.

The default environment option is still available in Godot 4, but you need to point to a default Environment resource in the Rendering > Environment > Defaults > Default Environment project setting. Make sure this Environment is saved to an external .tres file so you can point to it in that setting.

That’s still removing the ATM and requiring users to enter the bank to get the feature.

How do we get this change reversal request approved? Let’s work on that.

Obviously there’s quite a few people who are affected adversely by this change. Or would benefit if it was back.

[clayjohn]

The default environment in Godot 3.x was an endless source of confusion for users and it led to a lot of wasted time in bogus bug reports and users asking for support on community channels. Further, even for users that didn't notice any problems, it hurt performance and load times unless the default_env.tres file was removed from the project entirely.

To bring it back, we would have to resolve the issues that it caused. Removing the default_env.tres was discussed for years and we finally took the chance to remove it when releasing 4.0. We won't simply reverse that decision years later and re-introduce all the problems that were solved with its removal.

While its understandable that you enjoyed having a default environment, it was overwhelming unhelpful for most users. In these situations our usual approach is to improve the situation for the majority of users and leave the door open for users who have specific workflow needs that don't match the rest of the community (and who are willing to accept the tradeoffs implied by the workflow).

[adarcher]

Don’t you think leaving the door open would be to add an option and warning for this functionality? This is more akin to removing the door.

I didn’t know this was a multi-year decision. There might not have been more vocal votes for keeping it because it “just worked” for many, and they didn’t know it was in danger. I didn’t.

I can see that there is very little wiggle room here—with valid project planning reasons even if some disagree.

Could this feature be reimplemented with a plugin or something else that can be downloaded from the asset store or whatever would be best?

If this isn’t the best place to discuss an alternate fix, please direct me. I and others are interested in this enough, that something maybe possible from combined effort.

Thanks for your patience.

[Calinou]

Could this feature be reimplemented with a plugin or something else that can be downloaded from the asset store or whatever would be best?

Yes, a plugin can do what the editor internally does when the Default Environment project setting is set (i.e. setting a fallback environment on World3D). Here's the implementation:

• https://github.com/godotengine/godot/blob/923ef2b46a04e8f54c0a60bae8a0a6269fa52ed2/scene/main/scene_tree.cpp#L1825-L1854
• https://github.com/godotengine/godot/blob/923ef2b46a04e8f54c0a60bae8a0a6269fa52ed2/scene/main/scene_tree.cpp#L532-L553

[adarcher]

Thank, I’ll look into it.

[golddotasksquestions]

@clayjohn

The default environment in Godot 3.x was an endless source of confusion for users and it led to a lot of wasted time in bogus bug reports and users asking for support on community channels.

So is the current solution of having no default environment.

Further, even for users that didn't notice any problems, it hurt performance and load times unless the default_env.tres file was removed from the project entirely.

Why would the default environment have their load times hurt for users who did not notice any problems? Those users did not have a problem, because there was a default environment. Those users now have to figure out they have to add the default environment themselves (which is a problem), and then are hurt just the same by performance and load times ...

Also what I am proposing here has nothing to do with the default Environment: I'm proposing to add the Viewport WE+Environment whenever someone runs a 3D rendered scene (F6) which has no WE+Environment, in a project without a default environment set in the Project Settings.

While its understandable that you enjoyed having a default environment, it was overwhelming unhelpful for most users.

This is absolutely the opposite of what I have experienced in more than 5 years hanging out daily in the r/godot and Godot discord communities. The Godot3 WE sucked because the the Sky ambient was too blue and it had no DirectionalLight liked to the procedural sun. But that's it. The fact that the default Environment was there by default, never was the problem.

In these situations our usual approach is to improve the situation for the majority of users and leave the door open for users who have specific workflow needs that don't match the rest of the community (and who are willing to accept the tradeoffs implied by the workflow).

I really dislike how you paint this issue as @adarcher specific problem. 1) because a single user can always be the just the first person who speaks out, 2. Because it's very clearly not just one user as many have already spoken out being confused and irritated about this issue. 3. Because I have even listed such user community issues in my original proposal. 4. Because at the very least, it's @adarcher and my and probably the issue of those 13 others who came by and thumbed up the proposal. This comes up on the Godot subreddit like clockwork at least once a week. Unfortunately I can't make them all come here and thumb up this issue.