-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
Blackbody Light Colors? #29122
Comments
PS: Here's how Filmic Blender looks with "Very High Contrast" Look: It's much closer to the "Default" Blender display transfrom, but it's free of the color distortion and clipping! If you want to play with it, here's my Blender project for this: |
It is relatively easy to approximiate with the help of a gradient or color ramp like this: If you need more accuracy, then you can utilize a table like this: Which results in the following plot: Unreal has a blackbody node too, which is similiar to the one in Blender: Further, Unreal features physical lighting units, which are equally useful: I suppose that something like that would be everything you might need to create a correct physically-based lighting setup in Godot. Also, white balance controls might be better suited for the Environment resource? |
That graph is clipped at 255! Since we can have RGB values higher than 1.0 I guess we should be able to represent the blackbody curve without clipping. I think it makes no sense to limit ourselves here to colors that can be expressed with a hex code - that notation only makes sense for display-reffered imager (like screenshots) - in scene reffered imagery (like 3D rendering) there's no "highest possible value" to anything. I think going with the Unreal engine's way would be beneficial - physical lighting is awesome. |
The blowout is because tonemapping doesn't work right. Instead of tonemapping it's clipping. #18181 has not been fixed. I just posted an updated example there. |
@CptPotato responded on that other thread. You can fix the blowout by changing the Environment/Tonemap mode to Filmic and increasing the White value. |
I think it'd make sense to have this, but then, we'd have two ways to set a light's color in the Inspector, which can be confusing. (For the record, we currently have a similar issue with RigidBody mass and weight properties.) The same concern applies if we want to expose other kinds of physically-based proeprties (such as light radius/energy based on real-world units). |
Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine. The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker. If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance! |
The idea is to use real-world color temperatures for lights in the scene.
This allows the artists to use measured real-world values in Kelvins to model different types of light sources.
Here's how that works in Blender:
This is another step towards physically-based lighting - a.k.a. photorealism.
Maybe it'd be good to also have white balance controls in the camera?
Note: this above render uses Filmic Blender display transform with The Base Contrast look.
Color Management is a huge deal in getting good looking CGI.
Below is a "Default" Display transform instead. Look how burned out and distored the colors and light falloffs are, looking completely unnatural, yet familiar to anyone doing CG.
The text was updated successfully, but these errors were encountered: