Just finished the video, and I think it's a fantastic intro to using lights in Godot! I want to mention though that SDFGI runs terribly whenever you move the camera quickly, so I wouldn't recommend it for any serious projects. There's a PR to replace it with something better (also mentioned in the video) but there hasn't been movement in a year, so who knows when that'll come around.
this post was submitted on 08 Jun 2025
78 points (100.0% liked)
Godot
6761 readers
41 users here now
Welcome to the programming.dev Godot community!
This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.
Make sure to follow the Godot CoC while chatting
We have a matrix room that can be used for chatting with other members of the community here
Links
Other Communities
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
Rules
- Posts need to be in english
- Posts with explicit content must be tagged with nsfw
- We do not condone harassment inside the community as well as trolling or equivalent behaviour
- Do not post illegal materials or post things encouraging actions such as pirating games
We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent
Wormhole
Credits
- The icon is a modified version of the official godot engine logo (changing the colors to a gradient and black background)
- The banner is from Godot Design
founded 2 years ago
MODERATORS
SDFGI is basically realtime global raytracing, so that makes sense.
Ever wonder why so many modern games run so poorly?
A big part of it is that game devs are increasingly using their engine's version of realtime raytraced global illumination as the default... because it is very simple to for a dev to implement on a high powered computer...
... But actually properly doing all the tricks required to do well optimized, almost as good lighting, with other methods... is much more time intensive, so its either done poorly, or not at all.
Its wild to me that nowadays lightmap baking is seen as some kind of crazy, arcane, super special secret optimization technique.
Prior to about the last 4 or 5 years, its been the industry standard and norm for almost the entire history of 3d game engines.
Like, it has been the 'obviously, duh' standard to bake light/shadow maps for everything in a scene that is static, and only sparringly use dynamic lights... for nearly 20 years.
But here in this video, its 'secret sauce', its 'cheating.'
Lol no, it is not, it is the way actual pros have done this forever.
...
Rant over, I do agree that this is a very good tutorial nonetheless.
Comprehensive, engaging, information dense, doesn't waste your time, pretty easy to follow.
... fuck those crows.
I was seriously looking up online how to improve my lighting earlier today. Gonna have to give this a full watch later.
Lighting in Godot is one of those few things always making it hard for me between it and Unity... If I can accomplish it successfully, then it makes decisions around that much easier!
Honestly lighting principles translate regardless of whether you're programming in Godot, unreal, blender etc, or whether you're a photographer or filmmaker. It's unclear if the improvements you're looking for are about how to use Godot specifically or lighting in general, if the latter, then may I recommend studying general lighting information like for example aimed at filmmakers, remove the 3D component aspect because a lot of the content available there is made by folks that are very good at using software, but aren't necessarily experienced gaffers or DoPs, and those are the ones that actually know how to light stuff to make it look good.
It's actually more to do with their lighting systems leaking through walls (even thick 3D walls that are like 0.25m thick) and also still processing behind grid map walls even though they're not in camera view (obstructed/occlusion). I've had to make complicated grid maps with lights work by adding custom occlusion parts to the walls that send signals to enable or disable the entire light object scene, which is a little tedious to have to do.
So, it's mostly the performance part that's had me in a pickle. That being said, the default lighting from my experience between the two engines require more work on Godot to be smooth and work to the scene whereas Unity it's always felt like "it just works". Not that it's impossible, just that it does require some extra time to work. This is where I'm now kicking off to watch this video and see if I can get something good out of it!
I have been tinkering with those settings recently. I really enjoy how powerful editing the environment is, though I was getting freezing (not just Godot itself)... I think caused by multi-window mode.
I'm using untextured*+low-poly models though, so the advanced stuff is a bit hit-or-miss. Or maybe it just seems that way as small issues like light leaking are more prominent without textures.
Also when self-shadows are ugly I'm not sure how you fix that (other than perhaps not making concave details) when creating models. Doesn't seem like you can just disable shadows via material without also scripting the sun to hide when indoors (masking likely is the solution, but that is node config).
* vertex colors, I was messing with a shader (altering normals) until I found that lambert_wrap is what I'm looking for to improve vertex shading. Also, fog is applied to unshaded (though you can also disable fog per-material)