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

Improve Default 3D Lighting & World Environment #348

Closed
2 of 9 tasks
TokisanGames opened this issue Jan 3, 2020 · 65 comments
Closed
2 of 9 tasks

Improve Default 3D Lighting & World Environment #348

TokisanGames opened this issue Jan 3, 2020 · 65 comments

Comments

@TokisanGames
Copy link

TokisanGames commented Jan 3, 2020

Issue Tracker

This section summarizes and tracks progress on this proposal. Detail follows.

Merged:

  • ProceduralSky Sun - Combine with a directional light or calculate shadows. PR 37179
  • New default light/environment Buttons - PR 46315

Pending Issues/PRs:
n/a

Discussed Topics:

  • Tonemap/Filmic, White: 6. PR 34798 but then not merged
  • Attractive default Environment Settings:
    • ProceduralSky
      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:

  • ProceduralSky Sun - Decouple power output from visual size.
  • ProceduralSky Sun - Increase energy scale 20x (or equal to DirectionalLight)
  • "New scene" templates for Blank Scene or scene w/ included default items (probably moot)
  • PanoramaSky - Embed a directional light along with the hottest point on the HDR. (nice to have)
  • PanoramaSky - Embed a shadow projection plane. (nice to have)

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:
white-cube

Materials look terrible by default:
materials

Highlights are blown out by default, which also makes HDRIs unattractive:
tone-mapper

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.) PR

Ambient Light
* Color: value 50 (128,128,128)
* Energy: 3
* Sky contribution: 0.3
Edit; 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

  • Sky
    • Color: #36508d
    • Horizon: #8bafcf
    • Curve: 0.13

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.

reference-sky-philippines
reference-sky-boat
reference-sky-clouds

  • Ground

    • Do we even need a ground? Won't every dev put in their own plane/level/landscape? UE4 has no ground, just sky underneath. I recommend that it is removed entirely, or it's set to the sky horizon color by default to hide it.
    • 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

    • Latitude: 50 (just so it's not so late afternoon as 35)
    • The size of the sun as it currently appears with Angle max: 30, Energy: 30.
    • Decouple angle/curve/energy from size. Let us control image and power independently.
    • Increase energy scale 10x, minimum. Maybe 12-20x so we have some headroom. The sun needs an energy level of at least 640 just to start being in the range of properly exposing a scene (it's about the equivalent of a directional light at around 1.5-2), but then the size takes up half the sky.
    • 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? PR

PanoramaSky (HDRI/Shader)

Nice to have:

  • Detect the hottest point of the HDR and embed a directional light there, just like with the ProceduralSky. Or we can set its position manually.
  • Provide a ground shadow projection plane. UE4 seems to do some trickery with the HDRI, adding a virtual ground plane to catch the shadow. But it's not clear if they require a light to do this. I haven't experimented with HDRIs in UE4 in a while, but I seem to recall that a lot of it is automagical.

Directional Light

  • Energy: 2
  • Shadow enabled
  • Shadow Color: value 60 (153,153,153)

New Scenes

image

  • I recommend that the new 3D Scene button only (the one visible when starting a new project, "Create Root Node") sets up a white directional light with shadow enabled, and maybe a cube and a camera pointing at it (like in blender), and a WorldEnvironment node. All other new scenes are created empty.
  • Also maybe we use scene templates, like with new scripts where you can specify a script with comments, or blank. Maybe 'give me a scene with stuff in it', or a blank scene.

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 load cory_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.

@Norrox
Copy link

Norrox commented Jan 3, 2020

I think a change to the default one is very welcome

@srcrip
Copy link

srcrip commented Jan 3, 2020

I agree the default looks rather ugly and some of the changes here would be absolutely amazing defaults.

@fakedeltatime
Copy link

New defaults and a tutorial on good practices in the docs would be nice (I didn't see one at least).

@Calinou
Copy link
Member

Calinou commented Jan 3, 2020

Shadow Color: value 60 (153,153,153)

Won't this cause shadows to not fully darken things when you use GIProbe or BakedLightmap?

@TokisanGames
Copy link
Author

TokisanGames commented Jan 3, 2020

Shadow Color: value 60 (153,153,153)

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?

  1. To provide a good looking default environment that is set up with GI/BL? (UE4 does this and has baking lights as part of the workflow).
  2. Or to provide a good looking non-GI/BL environment. (which is Godot's current setup, except it doesn't look good.)

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.

@Calinou
Copy link
Member

Calinou commented Jan 3, 2020

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…

@TokisanGames
Copy link
Author

TokisanGames commented Jan 3, 2020

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.

@ghost
Copy link

ghost commented Jan 4, 2020

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

Repo

@davthedev
Copy link

Definitely worth looking into it.
Now I'm getting why all my objects look blueish with the default environment.

@PLyczkowski
Copy link

'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:

image

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:

image

Switching to Filmic makes it more natural still.

image

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.

Do we even need a ground?

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.

@golddotasksquestions
Copy link

golddotasksquestions commented Jan 4, 2020

Do we also want a directional light added automatically by default, at the right default translation Transform, if the user creates a new scene with Procedural Sky?

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.

@Zireael07
Copy link

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.
BTW the only thing that dir light needs is rotation, not translation.

@Calinou
Copy link
Member

Calinou commented Jan 4, 2020

@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.

@Zireael07
Copy link

Aaa, my bad. Still, an extremely good idea.

@Two-Tone
Copy link

Two-Tone commented Jan 4, 2020 via email

@Calinou
Copy link
Member

Calinou commented Jan 4, 2020

@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.

@ghost
Copy link

ghost commented Jan 4, 2020

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.

@Calinou
Copy link
Member

Calinou commented Jan 4, 2020

@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.

@golddotasksquestions
Copy link

@Calinou I think what @Simiopsis means to have an additional button next to 3D Scene:
3D_scene_with_lighting

@Calinou
Copy link
Member

Calinou commented Jan 4, 2020

@golddotasksquestions I understood that, but the concern I raised still stands 🙂

@golddotasksquestions
Copy link

golddotasksquestions commented Jan 4, 2020

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.

@ghost
Copy link

ghost commented Jan 4, 2020

The simplest thing that comes to mind is the following.

  • Pressing 3D Scene adds a directional light marked as editor only.

  • The editor only mode, should throw a warning icon.

  • The editor mode should only deactivate the light when the scene is the daughter of another.

@Calinou
Copy link
Member

Calinou commented Jan 4, 2020

Pressing 3D Scene adds a directional light marked as editor only.

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.

@ghost
Copy link

ghost commented Jan 5, 2020

@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

Sunlight

Enabled: this bool would generate the light and destroy it.

On: just turn the light on and off.

@PLyczkowski
Copy link

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.

@TokisanGames
Copy link
Author

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.
@Eko7 I'll get back to you after looking at your repo as well.

ProceduralSky Ground

@tinmanjuggernaut: Decouple the ground energy from shadows and shaded faces on objects.

@PLyczkowski: 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.

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?
Thumbs up for yay (ground colors=sky horizon color), down for nay (no change).

@TokisanGames
Copy link
Author

@aaronfranke I will review it this weekend.

@TokisanGames
Copy link
Author

TokisanGames commented Feb 27, 2021

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:

  1. Provide reasonably good default lighting for blank and outdoor scenes. Good being defined by photographic and artistic standards.
  2. Make lighting and environments easier to manage for new people.
  3. Maintain control over the environment for experienced people.

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 Sky

In the image below I have included these photos, left to right:

  1. Reference photo
  2. Default ProceduralSky, Editor default
  3. Default PhysicalSky
  4. My settings for the ProceduralSky
  5. My settings for the PhysicalSky

image

Thoughts:

  • I have never seen a sun or sky that looks like the default skies in 2 and 3. Our sky is blue, not cyan. Our sun is a bright disk with a corona. In 2, the disk is too small and vague. In 3 there is no disk. It appears to be a bright cloud for a sun.

  • In order to achieve a good looking sky as in 4 and 5 it takes a lot of experimentation. 5 looks good, and could look a little better with a bit more tweaking. However it takes extreme values to get here and has no further flexibility should I want to make an artistic sky. I'm at the end of the variable ranges. This also has other negative side effects as we shall see.

  • So these settings do not meet objective 1 for good looking defaults.

Horizon

  1. Reference
  2. Default ProceduralSky
  3. My ProceduralSky
  4. Default PhysicalSky
  5. My PhysicalSky

image

Thoughts:

  • In the reference photo we see that close up, the horizon is dark, and far away, it slightly fades to blue.
  • In 2, it fades to white, and the fade is a bit extreme. Instead it looks like the ground is turning transparent. In a game with a real terrain, I would use Fog to provide a proper fade. If using the procedural ground, this fade is too strong.
  • My proc sky just uses a hard ground without fade, and provides a subtle blending of the atmosphere based on reference photos. Though I would recommend defaulting to no ground at all as previously stated, and as on the PhysicalSky.
  • The default physical sky has no ground and instead includes a muddy cloudy color. The transition is rather vague. I suppose it's ok. It's better than a bad, fake ground. This set up encourages them to make their own terrain and won't distract from it when they do.
  • My physical sky horizon shows side effect 1. The horizon is too blue. The color is odd and I have no settings to control it. This one fails objective 3, lack of control where the tool has slipped off the rails.

Sample Scene

Finally, 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 lights

We'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.

image

Default settings / Procedural Sky

With 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.

image

My Procedural Sky

Using 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.

image

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.

image

Default Physical Sky

The 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.

image

My Physical Sky

If 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.

image

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.

@TokisanGames
Copy link
Author

TokisanGames commented Feb 27, 2021

Bugs:

  • When I select the WorldEnvironment and click New Environment in the inspector, it creates a default tonemap of linear instead of filmic.
  • The tonemapper defaults to a whitepoint of 1 instead of 6 as previously merged. If its boosted to 6 again, any lights and ambient light need to be boosted.
  • When I delete the world environment, it shows me a white sky environment instead of the default blue one. Sometimes I get the white environment. Othertimes I get the blue one.

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.

PanoramaSky

Regarding 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.

image

@Calinou
Copy link
Member

Calinou commented Feb 27, 2021

Though I would recommend defaulting to no ground at all as previously stated, and as on the PhysicalSky.

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).

I think the master branch allows you to use entirely different skies for the background and fallback reflections, but this isn't something casual users will naturally look into.

Edit: The master branch doesn't allow using separate skies for background and reflections, just like 3.x.

I think the problem is that reflection probes didn't work at all

This is a known bug, see godotengine/godot#45895.

The tonemapper defaults to a whitepoint of 1 instead of 6 as previously merged. If its boosted to 6 again, any lights and ambient light need to be boosted.

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.

@aaronfranke
Copy link
Member

aaronfranke commented Feb 27, 2021

@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 :)

@clayjohn
Copy link
Member

clayjohn commented Feb 27, 2021

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.

@aaronfranke
Copy link
Member

@clayjohn What is preventing us from having different default settings based on which renderer is chosen?

@TokisanGames
Copy link
Author

TokisanGames commented Feb 27, 2021

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.

@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 Physically material? Where is tone mapping and exposure in the material? Which material? I see no tonemapping in my object materials, nor in the PhysicalSky material settings. In these settings sun disk scale does nothing. I had to boost PhysicalSky Exposure, and heavily tweak the rayleigh and mie settings to get a good sun. The environment is at default exposure and other settings, including filmic.

@clayjohn
Copy link
Member

clayjohn commented Feb 27, 2021

@tinmanjuggernaut sorry, that was autocorrect. Try adjusting the exposure property in the PhysicalSkyMaterial along with good tonemapping in the Environment.

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.

@jasperbrooks79

This comment has been minimized.

@Zireael07
Copy link

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.

@Soupstraw
Copy link

Soupstraw commented May 19, 2021

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.
If the user wants to start from scratch, they can simply delete that scene, but if they are new, they will have something to play around with right off the bat.

@Calinou
Copy link
Member

Calinou commented Jun 19, 2021

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.
If the user wants to start from scratch, they can simply delete that scene, but if they are new, they will have something to play around with right off the bat.

This is now the case in the master branch, except for the Camera3D node. Not all scenes you create will need a camera node, and you can use the project camera override feature to preview the running 3D scene without having to add a camera. (Click the camera icon in the top bar while the project is running, then move the camera in the editor.)

@fire
Copy link
Member

fire commented Jan 6, 2022

Can the proposer and other relevant parties review the master version and comment?

@TokisanGames
Copy link
Author

@fire I can look next week.

@TokisanGames
Copy link
Author

Default Preview Environment

I 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.
image

Issues:

  • The UI is super buggy. Click a slider say to rotate the light angle and you can't let go of it. Tab doesn't work.
  • The preview environment looks enabled when it is disabled. That blue should be desaturated. It looks proper when you add the environment to the scene. The icon that disables the preview isn't good:
    disabled_environment
  • Looking at my scene and configuring the default preview values is a bit annoying because the window is in my way. I'd prefer it to pop up in the inspector, or at least on the side of the viewport. Also the three dots does not suggest to me "configure the default environment".
  • Clicking GI to add it to the scene doesn't add any secondary bounce. I'm not sure why it's there. Preview or added to the scene, it just makes the scene look worse. Here is GI allegedly enabled with default preview settings. You should enable sdgfi_read_sky_light in the preivew.
    image

Procedural Sky

Including the default preview sky above

  • The default preview blue sky is different from the Procedural Sky default color. The latter is better, but my recommendation is even better. They are the same hue, but mine has much more contrast and produced from equatorial reference photos.

Compare the preview sky color. Preview default vs mine. ProcSky default is close to mine.

image

Physical Sky

The 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.

  • The default sun is a vague nebula in the sky, not a sun.

image

I have to play with many settings to get a reasonable looking sun with an actual intense disk, and w/ tonemapping enabled.

image

  • But then the glow from the corona is camera-direction sensitive, so when moving the camera around the glow shifts unnaturally. Copy these settings, look at the sky and move the camera around to see the strange coronal shift.

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).
image

HDR

I 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.
image

Final thoughts

Overall 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.

@Zireael07
Copy link

ACES turns blue into purple though.

Oh, I'm seeing this in my project, too - not related to the sky at all.

@aaronfranke
Copy link
Member

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

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

No branches or pull requests