-
-
Notifications
You must be signed in to change notification settings - Fork 97
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
Improve Default 3D Lighting & World Environment #348
Comments
I think a change to the default one is very welcome |
I agree the default looks rather ugly and some of the changes here would be absolutely amazing defaults. |
New defaults and a tutorial on good practices in the docs would be nice (I didn't see one at least). |
Won't this cause shadows to not fully darken things when you use GIProbe or BakedLightmap? |
I'm not sure. I didn't test these settings against GI/BL. The high Ambient Light is also likely to cause issues with GI/BL as well. My tutorial and resulting proposal was all geared toward a non GI/BL environment, since it's the default and seems to be what most people use for demos/tutorials/prototypes. So assuming there will be an issue, what is better?
As far as all my settings, Shadow Color is one of the least critical. However without it, black shadows do look unusually dark in a non-GI/BL environment once materials are applied. |
Maybe that could be compensated by increasing the sky contribution with a procedural sky (while leaving it below 1)? Either way, it's quite important to have a way to set up a good-looking GIProbe without having to tweak shadow colors. Maybe the shadow color could be adjusted automatically in areas not affected by a GIProbe… |
Sky Contribution makes everything blue. It's the primary thing that gives everyone the issues demonstrated here and prompted me to create this video and proprosal. Sky Contribution is part of ambient light. My settings essentially shift the luminance from AL/sky contribution over to AL color/energy so it retains luminance but not color cast. So yes it could be compensated by increasing ambient light color &/or energy, which lightens up both the shadows and shaded faces. However in my experience this doesn't look good. Shadow gives an object dimension, and if AL is too high, it will cause objects to look flat as they aren't shaded properly. Since DL/Shadow Color affects only shadows and not shadowed faces, it fills in the gap by lightening up the shadows only. It's not technically correct, because mathematically the scene is only lit by a directional light, not a sky. But it's artistically correct as if the sky were lightening up shadows. AL and DL/Shadow Color are both used to provide fake bounce lighting. I suppose we need to do more testing to see how the lights respond under a GI probe. |
This is my default setting, maybe it will help It would be a good idea to add a directional light when the 3d Scene button is pressed |
Definitely worth looking into it. |
'These are white materials, and these object should be white' - while you do know the color theory and how light works, you don't really mention this in the video, I think this should be stated here so there is no misinformation: White materials in real life are blueish under a diffuse lighting from the sky, since the atmosphere scatters blue light more, and so the sky 'emits' blue light. You can see it in this hdr: Godot's base scene setup doesn't have the sun as the light source, while having a lit unclouded sky, a scenario that does not happen in real life, which makes it look unnaturally blue. Adding the light back in, by using a directional warm light for instance, brings the scene back to looking more natural: Switching to Filmic makes it more natural still. I'm guessing the developers (@reduz?) left those kinds of decisions (how to add the sun light etc) to the user, and just set up a blank canvas in default_env. There may be a bit too much sky contribution because as you said, the warm light from the sun is not properly bounced around and mixed back in into the blueish light.
Procedural Sky works just like an hdr in the end, and hdr give light from all directions, including from below, to give that natural lighting. Now, the Sun option in Procedural Sky in straight out broken as you mention in the video. The energy is far too low, and is not really helpful if it can't cast shadows. For the defaults I would go with a bit less sky contribution, and a warm properly working sun with enough Energy, preferably that can give shadows like a directional light. Also maybe Filmic on, unless there are arguments against that. |
Do we also want a directional light added automatically by default, at the right default Personally I would vote yes. I would also like a cube in a default new scene. Things like these are easy to delete (or to turn off in the preferences) but tedious to set up every time and complicated for the uninformed newcomer to get right. It's always easier to return to the defaults that look good after fiddling with the settings to find out why they look good, than to tiring to make defaults that don't look good, to look right. |
I think I saw an issue or a comment that suggests a directional light being added automatically to 3D scenes. Extending that to having a directional light automatic with proc sky is a good idea. That way the proc sky sun doesn't have to be extended to casting shadows. |
@reduz said we could have a default DirectionalLight in Environment that would be removed automatically as soon as you add a DirectionalLight node to the scene. Its angle could match the sun angle automatically when using a ProceduralSky. This way, you can get good-looking lighting out of the box without having to add a node to every scene. Edit: This was implemented as the Preview Sun and Sky functionality. |
Aaa, my bad. Still, an extremely good idea. |
I really like that idea, but it may seem unintuitive to new users to have
a node/light source disappear when you manually add one in for the first
time.
…On Sat, Jan 4, 2020 at 10:46 AM Zireael07 ***@***.***> wrote:
Aaa, my bad. Still, an extremely good idea.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#348?email_source=notifications&email_token=ABBEIS2SJUXAE3EVRL242ADQ4C4NLA5CNFSM4KCONBH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIC3ROA#issuecomment-570800312>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABBEIS7XMJIV6P24FO6BQX3Q4C4NLANCNFSM4KCONBHQ>
.
|
@Two-Tone Maybe we could have the DirectionalLight node display a configuration warning when it's newly added. This could be done by checking for its property values and checking whether they all match the default – it's very unlikely that you'll use a DirectionalLight that points straight towards a wall. While we're at it, we could also make DirectionalLight point straight down when it's newly added. However, there's a slight chance you may actually use this direction in a real project, so this would conflict with the aforementioned warning. |
I think the least confusing is to add a "3d Scene With Lighting" button, just like "3D Scene" but with a directional light set as sun. |
@Simiopsis The issue is that if someone instances such a scene into another scene, they'll end up with multiple directional lights. This may not be obvious to a beginner, especially if the directional lights have the same angle. |
@Calinou I think what @Simiopsis means to have an additional button next to 3D Scene: |
@golddotasksquestions I understood that, but the concern I raised still stands 🙂 |
Can you explain why? I would assume if someone intentionally creates a scene with Lights, instead the basic one without, they would delete the directional light once they instance that particular scene into another, or not click the button in the first place. |
The simplest thing that comes to mind is the following.
|
This means you lose the advantages of the default light when you run the project. Moreover, this will also confuse a lot of people out there 🙁 We had an editor-only default light in Godot 2.x; many people wondered why the running project was darker compared to the view in the editor. |
@Calinou I think what @reduz mentions is more appropriate, but instead of destroying the directional light by adding another, the directional light generated by the world environment must be able to be configured in the world environment, allowing this light to be activated and deactivated. for example SunlightEnabled: this bool would generate the light and destroy it. On: just turn the light on and off. |
I would go with fixing Procedural Sky so that it's sun can give light like a directional light, like proper hdr's do, and adding a Shadow option to the Sun, that can work like a shadow from a directional light placed at the Suns angle. This makes everything work like before, no extra objects added, but sun and shadow can be set in the default_env then. |
I have updated the top of the proposal with an issue tracker as there are a lot of threads here. I'll provide my responses on separate messages so people can thumbs up or down on individual ideas. @Calinou I'm still going to get back to you on GI + Shadow color. ProceduralSky Ground
I played with it more, rotated my cube, and I get it now. It's a little odd because the light is not occluded by other objects. But I think the biggest problem is that Sky Contribution is so strong that it didn't appear to behave like HDRIs. When SC is reduced it doesn't seem as odd. Ok, no need to do anything here. I have removed this point. Do we even need a ground? However, this is still an open question. IMO, having an HDRI/ProcSky ground is ugly and something most devs would try to hide in their games. UE4 devs apparently agree since they have only sky below the horizon. I discuss having no ground in my video and show examples with an HDRI 14:29 and ProcSky 19:37. What do you guys think about hiding the ground by default as per my settings? |
@aaronfranke I will review it this weekend. |
Per @aaronfranke 's request, I'm reviewing the progress on the master branch in regards to default lighting. Let's review the purposes for this proposal:
Regarding 2, The new buttons for lights and environment, are simple to use and a big improvement over 3.2. Barring bugs and default settings, I think the functionality will clear up a lot of confusion for new people. Regarding 1, Aside from defaulting to filmic, it doesn't appear that any of my recommendations were incorporated. So now let us review the default lighting environments. Sun and SkyIn the image below I have included these photos, left to right:
Thoughts:
Horizon
Thoughts:
Sample SceneFinally, lets' look at a scene under various lighting conditions. The box has no material, so is pure white. The prisms are pure red, green, and blue. The ring is gold metal, and looks terrible in all of these samples. I think the problem is that reflection probes didn't work at all, and the sky is too plain to accurately show good reflective metal. It might look better under a more full scene or an HDRI, and working reflections. Pure white studio lightsWe'll start with the scene under a pure white sky and lights, and perfect white-balance. This is what it would look like if I took a picture on a cloudy day. Under this lighting, the top of the box becomes a light, pure grey (228, 228, 228). The shadows are soft and well illuminated. I added SSAO and a direct light to more accurately represent what reality would look like. The light gives hotspots on the gold ring, which would not be there. Default settings / Procedural SkyWith the default settings, the scene looks OK. There is a blue cast still. It's better than 3.2 because of the default light, but its still blue. If you take the white box into photoshop you'll see the color is (217,226,235). Compare with the above picture you'll see the white parts of the fox are bluish, and the red prism, gold ring, and grass have a bluish tint. The back end of the fox looks greennish. The gold ring is very odd. I can't accurately create materials under these lighting conditions. They would likely come out too yellow if moved to different lighting. I would have to create a studio with pure white light in order to work on materials. Bottom line: While the default lighting is ok though a little blue, the sky is unattractive, and the two are connected as we shall see. My Procedural SkyUsing my proc sky, the sky becomes more realistic, but now the scene lighting is no good. You can see that the shadow side of the box and under the fox are too dark and too blue. Even if I enable GI, as it is in this picture it doesn't help. The only material difference with GI is the gold light reflecting on the fox's chest and in the ring's shadows. In order to have an attractive sky and have good lighting, I would have to add another light source or ambient light to fix it. Enabling SDGFI does help illuminate the shadows, but it's still too blue and offers no control over the color. Instead here I use ambient light to brighten the shadows and leave them just slightly blue. This is more realistic to what you would see if you were actually there. Can you see it? Can you imagine seeing the previous picture in real life? You'd only see the above with a cheap digital camera with low dynamic range. Your eye has a lot of dynamic range and below is what it would see. Default Physical SkyThe default physical sky scene lighting is ok, though it is a little dark. Blue tint is subtle and fine. Here I've added GI for the ring to look somewhat normal, it looks washed out without. Again, the only material difference is a little reflective gold light shines on the fox's chest, the ring's shadow on the box, and in the nearby grass. Comparing closely with studio lighting, I would say that the color fidelity is pretty close to what it should be. The sky itself is unattractive, and again the lighting and sky appearance are connected as we shall see. My Physical SkyIf I adjust the sky to look normal, then we reveal negative side-effect 2. The shadows are extremely blue and have the odd color from the horizon. The only way I have found to fix this is with ambient light. In that scenario the picture looks a lot like the one above with ambient light. So, in conclusion I would say the current state does not provide reasonably good looking defaults, failing objective 1. The new functionality meets objective 2 very well. And for objective 3, while all of the old functionality is maintained, some of the new options (PhysicalSky, SDGFI) don't provide enough control. While the default ProceduralSky lighting on the scene is OK, the bluish cast is still a problem for accurate materials. The default sun and skies are unattractive on both P*Skies, and if you correct those settings, it destroys the lighting. @clayjohn expressed a desire to maintain a PBR workflow. Unfortunately, I do not see how to achieve a realistic looking sky, with realistic looking scene lighting, without cheating with ambient light. I'm not concerned about the math, only about the look. If it can be done using PBR only, but I can't figure it out, it's way too hard for a new person. However, if someone can do it, then those should be the defaults. Edit: Regarding my default recommendations, though the sky colors remain the same, the values for ambient light have changed slightly in the new setup. Perhaps an ambient light of #878e9c w/ sky/energy @ 1. Directional light energy @ 2 and a color of white or very soft yellow. I didn't do anything with direct light shadow color as before. |
Bugs:
The white one is a very good environment with beautiful scene lighting. It should be the default. Or as I suggested before, have templates which include a studio setup like this one, and a good looking blue sky as I made above. PanoramaSkyRegarding using HDRIs, here I used the same image as before. I bumped the tonemap whitepoint to 6 so the sun didn't blow out, and boosted my directLight to 3. No ambient light. This is the only image where the gold actually looks good. No GI, no reflection probes. The skycontribution property appears to be missing so I can no longer control it. Even without that setting, this is the only lighting setup I would use in Godot 4 right now. I would create an HDR with sun, sky, and clouds and no ground as I did in my tutorial video. This is far easier to get accurate results, rather than using either of the procedural skies. Metalic reflection (roughness) looks amazing here. Roughness under procedural skies are broken in 3.2 and if my above tests are any indication it doesn't appear to have been fixed in 4 yet. |
The issue with not including any ground in the sky is that it makes reflections much less correct if you don't use GIProbe/SDFGI/ReflectionProbe. In testing setups, people are unlikely to use any of these (SDFGI isn't affordable on low-end hardware).
Edit: The
This is a known bug, see godotengine/godot#45895.
Note that godotengine/godot#34798 was never merged as reduz didn't like the idea of having filmic tonemapping as the default in all 3D scenes. Still, changing the default whitepoint to 6 is a good idea, as the whitepoint value won't affect anything when using Linear tonemapping. |
@tinmanjuggernaut I shared these images on Discord. The general thoughts are that both of your custom procedural skies look nicer than the default procedural sky, and that the physical sky is a mixed bag but that the default physical sky looks a bit dark but better than the physical sky with a blue color because it's just too intense of a blue color. I'm glad that you're working on this, and I look forward to any specific changes that you propose, as you are doing a good job :) |
Regarding using tone mapping, if we drop GLES2 support, we can have tone mapping enabled out of the box! Also @tinmanjuggernaut try the PhysicalSkyMaterial with proper tone mapping and increased exposure (in the material, not in the environment) I've artificially reduced exposure in the PhysicalSky so that it works with an LDR workflow. But with proper tone mapping you get a crisper sun and better blues without resorting to too much trickery. |
@clayjohn What is preventing us from having different default settings based on which renderer is chosen? |
@Calinou lol, what?! Anyway, the default is filmic (sometimes. When using the top buttons). Other times its linear, depending on how you create it (when using the inspector). @aaronfranke Thanks. I have made my suggestions, and provided workarounds and tutorials for gamedevs. It's now out of my hands. @clayjohn What do you mean |
@tinmanjuggernaut sorry, that was autocorrect. Try adjusting the You shouldn't really tweak Raleigh or Mie unless you want to aim for a non-earth-like atmosphere. Edit: also thank you for your detailed comparison! Your notes are very helpful. @aaronfranke ease of use for users switching between the backends. It makes sense to have different defaults if users are locked into a rendering backend. But it becomes a problem when users switch back and forth between the two. |
This comment has been minimized.
This comment has been minimized.
One more newbie who got caught out by no default light: godotengine/godot#47474 (comment) At least the part of this proposal where it suggests a default light added to 3D scenes should be done ASAP. |
It would be nice if once you create a new project, you have some sort of a basic scene with basic lighting, a camera and a mesh. |
This is now the case in the |
Can the proposer and other relevant parties review the master version and comment? |
@fire I can look next week. |
Default Preview EnvironmentI opened my basic fox scene and looked at the default environment. Overall the light shining on my scene looks great and the sky is not terrible, though the blue is not natural. Here is the default look. The fox looks normal. RGB look normal. The white box looks as it would under that default sky. The gold metal looks reasonable without any reflection probe or gi. Issues:
Procedural SkyIncluding the default preview sky above
Compare the preview sky color. Preview default vs mine. ProcSky default is close to mine. Physical SkyThe goal with procedural skies is to have an attractive sky AND attractive lighting on the environment AND to be able to use Filmic or ACES with tonemapping. These were previously not attainable with the procedural or physical sky or if they were it was too difficult to figure out. I was able to figure out something this time, with the addition of SDGFI. However it's still very challenging to get a good looking sky and scene lighting simultaneously.
I have to play with many settings to get a reasonable looking sun with an actual intense disk, and w/ tonemapping enabled.
With this sky, I then have to boost the directional light and sdgfi energy to get a reasonable result. This is with filmic white:4. ACES turns blue into purple though. This sky is really hard to control. I still wouldn't use it for that reason alone, but maybe other reasons (eg roughness issue - which is unknown if it is present, see below). HDRI would still only use an HDR sky (or a shader, see below). I wouldn't use this HDR, rather a custom one with just a sky and clouds as discussed in my tutorial video above. Here it is with sdgfi enabled which is nice. Final thoughtsOverall the goal of this proposal was to get the default settings to look reasonable so that projects from new devs didn't look terrible, they didn't get frustrated, and Godot didn't look bad. I'd say this has been achieved. This is a tremendous improvement. The issues I mentioned above (all bulleted) should be fixed for improvement, but otherwise, this proposal can be closed any time the core devs are satisfied they have addressed what I brought up. For my use, I won't use the procedural skies for the reasons I mentioned. I'd only use an HDR or certain shader skies. We recently shifted our game from an HDR to the Time of Day plugin, which gives us not only a dynamic sky and great control over the lighting, it also doesn't exhibit the problem with unusable roughness under a ProceduralSky. This is a deal-breaking issue in the 3.x renderer, which only HDR or certain shader skies like this plugin address. I'm not sure if roughness under procedural skies has been fixed in the 4.x renderer. I haven't seen it yet, but haven't tested materials extensively. |
Oh, I'm seeing this in my project, too - not related to the sky at all. |
I'm closing this proposal because overall the default settings have already been considerably improved in 4.0 as shown by @tinmanjuggernaut's most recent comment in January. Thank you for continually posting high-effort detailed explanations. We do still want to ensure that the defaults are as good as possible for 4.0, since changing these defaults in the future will break compatibility. If there are any specific outstanding issues, please open dedicated proposals for them, like this one #4524 |
Issue Tracker
This section summarizes and tracks progress on this proposal. Detail follows.
Merged:
Pending Issues/PRs:
n/a
Discussed Topics:
Sky Color: #36508d, Horizon: #8bafcf, Curve: 0.13
Sun: Latitude: 50, Angle max 30 Energy 30.
Ground: both colors = Sky Horizon color
Minor/No Discussion:
The Issue
Describe the problem or limitation you are having in your project:
The default lighting environment is extremely unattractive. Unaware devs use the defaults, which detracts from their demos, as well as makes Godot look bad. For comparison, UE4 has a great lighting setup by default - no configuration is necessary.
These objects are white, but appear blue:
Materials look terrible by default:
Highlights are blown out by default, which also makes HDRIs unattractive:
Is this a real problem for people?
Look on facebook, twitter, youtube, or reddit for 3D demos from devs. Many of them use the default lighting and their demos look bad.
Examples. All of these have a heavy blue cast and muted colors, even if they've added a light:
https://twitter.com/dalton8000/status/1208794768337190912
https://twitter.com/m4gr3d/status/1210249791017570304
https://twitter.com/nightblade99/status/1209324080907857925
https://twitter.com/skooterkurt/status/1210625650807263233
https://www.facebook.com/groups/godotengine/permalink/1764599440343309/
https://www.facebook.com/buzzmandt/posts/10216181547837595
https://www.reddit.com/r/godot/comments/eiv38x/getting_better_at_working_with_vehiclebodykinda/
https://www.reddit.com/r/godot/comments/eik633/20_days_with_godot_so_much_fun/
Further, this twitter thread was very popular and seemed to hit a nerve with people:
https://twitter.com/TokisanGames/status/1210610419556999168
"it's not easy to get lighting right in Godot"
"I'm really looking forward to that, the unnatural blue hue and lost contrast has been a big problem in a project I'm working on!"
"I agree. The default environment make anything bluish."
Referenced tickets showing its a continuing issue:
#30
godotengine/godot#18226
godotengine/godot#20786 (It was really bad before this, now it is only bad)
godotengine/godot#10451
Users should not have to hunt to find an obscure Sky Contribution setting just to remove the blue cast. Or even know they need a light before their materials will look good. The first brand new scene should just look good by default.
Other Template Questions
Describe how this feature / enhancement will help you overcome this problem or limitation:
Anyone can work around the issue now. However, most don't because the knowledge of how to do it takes months of using Godot and trial and error to learn how.
Describe the project you are working on:
Voxel Tools demos, YT Tutorials, prototypes w/ voxels.
If this enhancement will not be used often, can it be worked around with a few lines of script?:
It will be used by everyone. A script is insufficient.
Is there a reason why this should be core and not an add-on in the asset library?:
ProceduralSky and WorldEnvironment are in core.
My Proposal
Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:
I made a 30 minute tutorial video showing devs how to work around all the limitations and setup a good scene. It also illustrates the issues highlighted in this proposal. TLDR - here is where the issues are demonstrated:
It would be ideal if the default environment was just set up as I show in the video. Some suggestions require code changes.
Describe implementation detail for your proposal (in code), if possible:
Here is my proposal, but these points and values are open to discussion on how best to achieve an attractive default lighting setup. I've created the settings based on a decently calibrated monitor, and comparing and tuning settings with white materials, grass/rock materials in my own prototypes, and all the materials in the 3D materials demo. This took me about 5 weeks of testing and retesting. I had to make my video 3 times as I tweaked my settings.
Once there is a consensus as to the best way forward, I can create individual issues if desired.
Tonemap
* Mode: Filmic (like Blender; UE4 uses ACES, but I think it's too contrasty for a default). I can't think of any reason why we'd leave this at Linear.PR* White: 6 (at least 4, up to 16. 4-8 allows the very center of the sun to blow out, giving it the effect of a ball with a coronoa. The ball is also visible in reflections. See the white plastic in material demo.)PRAmbient Light
* Color: value 50 (128,128,128)* Energy: 3* Sky contribution: 0.3Edit; I no longer recommend adding ambient light as a default, especially with SDGFI. However reducing sky contribution or turning ambient light black I do recommend.
At 1, procedural sky is unnaturally blue. It appears far stronger than it is with HDRIs - maybe reduce the ProcSky scale to 1/3rd. Some HDRIs look fine at 1. So I'd either default the settings for both at 3/0.3, or reduce the internal ProcSky Sky Contrib scale down to 33-50% of what it is now, and boost energy x3, then you could leave both HDRI Sky Contrib and ProcSky Sky Contrib at 1 and 1.
Procedural Sky
Colors were chosen under filmic, based on my reference photos below. I recently took these here in the Philippines. The air has very little pollution and it's an equatorial sky, so perhaps it's the ideal reference sky. The deepest part of the sky has a hue of 219-222.
Ground
Decouple it from shadows and shaded faces on objects. Energy/color of the ground should not affect the lighting on objects!- Edit: apparently the sky works like an HDR, wholly illuminating the scene, so this isn't a problem anymore.Sun
Nice to have: Embed a directional light in with the sun, matching the angle so we can get shadows (but only one energy setting). Or just automatically calculate shadows directly from the procedural sun. There's no reason to have the procedural sun emit light unless it can also cast a shadow. If it won't, then for all games that need shadows, it only makes sense to disable the sun energy effect, use a directional light, then manually align it with the sun. Why not just embed all of that together?PRPanoramaSky (HDRI/Shader)
Nice to have:
Directional Light
New Scenes
Sample Project & Summary
Project file
Here is a sample project. Start by downloading the 3d materials demo. Then drop these files inside. Load
cory_scene.tscn
which should loadcory_procsky_env.tres
, and you can view the white cube with all the other materials.You can also switch to
cory_hdr_env.tres
. But note, that all of the HDRIs included in the demo are 50% the brightness they should be. So adjust Tonemap/Exposure to 2. People should use properly exposed HDRIs, so this setting should default to 1.The text was updated successfully, but these errors were encountered: