My rationale for reducing the R&G by the net amount I increased the blue by was to prevent bounces from having more energy than the albedo could actually reflect. It may warrant more tweaking, but like Ibex said, I also found about 4-5% extra to be a good balance. Greater than that made it noticeably blue.
Not sure how Ibex did it, but I simply used a raytracing quality switch node.
I think that the incomplete precision of blue causes it to lose energy, so I would only add blue, but it would not be 5%, because there are not 10 possible errors, if not 9, since 0 or 10 would not be an error since it is fine inside of precision, so I would add 4.5%, more than that would cause there to be more energy than there should be
̶I̶’̶m̶ ̶n̶o̶t̶ ̶s̶u̶r̶e̶ ̶i̶f̶ ̶t̶h̶e̶ ̶p̶r̶e̶c̶i̶s̶i̶o̶n̶ ̶e̶r̶r̶o̶r̶ ̶c̶a̶u̶s̶e̶s̶ ̶e̶n̶e̶r̶g̶y̶ ̶t̶o̶ ̶b̶e̶ ̶l̶o̶s̶t̶ ̶o̶r̶ ̶n̶o̶t̶ ̶-̶ ̶m̶a̶y̶b̶e̶ ̶i̶t̶ ̶d̶o̶e̶s̶.̶ ̶N̶o̶r̶ ̶a̶m̶ ̶I̶ ̶d̶i̶s̶p̶u̶t̶i̶n̶g̶ ̶t̶h̶e̶ ̶p̶r̶e̶c̶i̶s̶i̶o̶n̶ ̶m̶a̶t̶h̶,̶ ̶b̶u̶t̶ ̶w̶e̶r̶e̶ ̶r̶e̶a̶l̶l̶y̶ ̶j̶u̶s̶t̶ ̶s̶p̶l̶i̶t̶t̶i̶n̶g̶ ̶h̶a̶i̶r̶s̶ ̶a̶t̶ ̶t̶h̶a̶t̶ ̶p̶o̶i̶n̶t̶.̶ ̶T̶h̶e̶ ̶e̶n̶e̶r̶g̶y̶ ̶l̶o̶s̶s̶/̶g̶a̶i̶n̶ ̶a̶n̶d̶ ̶t̶h̶e̶ ̶h̶a̶l̶f̶ ̶a̶ ̶p̶e̶r̶c̶e̶n̶t̶ ̶f̶r̶o̶m̶ ̶r̶o̶u̶n̶d̶i̶n̶g̶ ̶a̶r̶e̶ ̶n̶e̶a̶r̶l̶y̶ ̶i̶m̶p̶e̶r̶c̶e̶p̶t̶i̶b̶l̶e̶ ̶d̶i̶f̶f̶e̶r̶e̶n̶c̶e̶.̶ ̶M̶y̶ ̶t̶a̶k̶e̶ ̶w̶a̶s̶ ̶I̶’̶d̶ ̶j̶u̶s̶t̶ ̶r̶a̶t̶h̶e̶r̶ ̶e̶r̶r̶ ̶o̶n̶ ̶t̶h̶e̶ ̶s̶i̶d̶e̶ ̶o̶f̶ ̶t̶o̶o̶ ̶l̶i̶t̶t̶l̶e̶ ̶r̶e̶f̶l̶e̶c̶t̶e̶d̶ ̶l̶i̶g̶h̶t̶ ̶t̶h̶a̶n̶ ̶t̶o̶o̶ ̶m̶u̶c̶h̶ ̶p̶e̶r̶s̶o̶n̶a̶l̶l̶y̶ ̶b̶u̶t̶ ̶I̶ ̶t̶r̶i̶e̶d̶ ̶i̶t̶ ̶b̶o̶t̶h̶ ̶w̶a̶y̶s̶ ̶a̶n̶d̶ ̶t̶h̶e̶y̶ ̶b̶o̶t̶h̶ ̶l̶o̶o̶k̶e̶d̶ ̶p̶l̶a̶u̶s̶i̶b̶l̶e̶.̶
Edit: Okay I did some more experimenting. It actually seems that both of our numbers still have less light energy compared to the path tracer. Color value is 0.7 as before.
Path-tracer:
When inspecting the histogram of these images, I found 4.5% and 5% both still had less mean average blue levels than a true white or our reference, and they had lower luminance. In this specific scene, increasing the indirect light intensity to 1.11 compensated for the lower light energy compared to the path tracer pretty well.
Histograms:
Path Tracer:
Mean RGB ( 66.85, 66.99, 66.82) Luminosity (66.99)
4.5% blue-shifted lumen
Mean RGB ( 63.06, 63.2, 61.64) Luminosity (63.07)
6% blue-shifted lumen with 1.1 GI boost
Mean RGB ( 66.65, 66.77, 66.71) Luminosity (66.75)
Difference from Path tracer (darker = more similar)
6% + GI Boost:
For the purpose of these tests I did not reduce the other channels, since we we’re already darker than the reference, and it was fewer variables to explore.
Obviously this is just one scene, so I can’t be sure that these numbers are generally useable outside of this instance, but in this instance 6% extra blue corrects the color the best, and boosting the indirect lighting intensity to 1.11 corrects the lost light energy quite well in this case.
I was also doing more experiments, and I think the amount of blue to add is not the same, in a scene with the same increment it can look more yellow than the path tracing, or more blue, and about the energy loss, I also noticed that lumen has a little less energy, I will do more experiments and I will pass comparative photos
Good experiments!
I thought you were doing something more internal into the engine. The problem now is that it must be applied to eevery material.
So, I have making some quick tries with a Post Process material, more “global”, and it seems to work too (maybe not so great as applying it to the “source” material directly). But I can’t find the way to disable it when rendering with Path Tracing view.
You would just add it to your master material as a bool, so that it can be enabled as needed on any instances with the click of a button. The issue with tinting the scene blue as a post process is that areas that are in direct light don’t need to be adjusted, so you cannot linearly apply color correction to the screen.
I have also figured that it is best to cut the R&G instead of boost the B. This is because albedo is clamped from 0-1. In the unlikely event that you have a very high albedo value, boosting will get clamped and not correct the scene. So for example you might multiply the RT pass by ( 0.946, 0.946, 1) instead of ( 1, 1, 1.054). I tried more scenes and lighting configurations and found that the 4-6% range generally offered the most aesthetically pleasing results.
Both R&G and B will suffer from lost precision at certain values in the GI texture. So my theory is the important figure is the difference between how imprecise they are.
I believe the range, more specifically 5.4% or (0.946 RG) is the ideal ratio for white balance after doing lots of math and testing.
Based on the images below. I’ve tested the RGB values in multiple lighting setups and this offers the consistently truest white based on my experiments. Using these values, here are the histograms side by side.
EDIT: swapped comparison out for a brighter image to better show differences.
OG Lumen Left, Shifted Lumen Middle, PT Right:
OG Lumen:
In this specific scene I had to double the indirect light intensity of Lumen to roughly match the Pathtracer. I don’t think that is representative of a typical case - we’re just in an almost pure white box and the PT does a better job of bouncing all that light around.
Sliding Comparisons:
Shifted vs PT
Shifted vs OG
Pathtracer vs OG
Shifted + Boosted vs Pathtracer:
Did a few more experiments to drill down on the blue shift value more. As I still wasn’t happy with the 5.4% figure, even though it looked good in most cases. We can see from my last post’s histogram that it was just a hair too blue.
So I went back to the baseline and tested a bunch of levels. 4.5% works great at most points as Ibex predicted, but it specifically falls apart when the albedo gets very high (above 0.95) and begins to turn yellow again. I didn’t notice anywhere else that it didn’t perform well, as you’ll see below.
Maybe this doesn’t matter, as Krzyztof said, as no materials reflect this much light except mirrors. But I wanted to push on anyway. I found a value of 6.8% corrected the yellowing at a value of 1.
So I decided to color correct using a remapped range. Anything below 0.95 would use a 4.5% adjustment, and anything above 0.95 would begin to lerp towards 6.8%.
Here is an image and histogram of every 0.05 increment from 0.6-1.0 showing proper white balance across the full range of values.
Its not perfect, but it seems nearly so across the full range. At low albedo levels I would disable the effect, as the reflected light no longer contributes enough to be noticeably colored, but the slight tint in reflections would be.
I don’t expect this will come up often or ever realistic scenes. Maybe in a bright, white marble room.
Here’s an example node group. From here on out I propose this technique be nicknamed Blumen.
Great work!
I’m only the “commenter”, you the experts:
Maybe they could (something like) include those nodes internally just before the base color pin.
You commented to disable it for low albedo whites. It could be interpolated with a lerp too. When near to 0, applies 0, and viceversa.
About the reflections, well, I imagine th edifference between the RT part (more blueish now) and the screen traces ones, but it would different too when comparing the yellowish RT part with the screen trace one, isn’t it? Just changing the color, nothing dramatic.
PS: even if it’s the ideal approach, I still see it like a headache to add it for every material, as lot of people don’t have an unique master material.
PS2: Oh, even if somone said, I think it’s quite usual to have interiors with whites higher than 0.8 or 0.85, so this is still quite useful.
You could lerp it to 0% increase, but disabling it saves a few instructions.
The reason that the yellow screen-traces don’t cause an issue is because when it is not adjust is that it will be yellow in both the screen-trace and the reflection.
Bluing adjusts the ray-traces only, not the screen-traces. This causes it to become white in the screen-trace but blue in the ray-trace. It’s not horrible, but it is noticeable.
As to to the P.S., this is exactly why every large project should probably use master materials. You will often find in a production environment you want to deploy a change across a wide number of materials, which is trivial when set up this way. Alternatively, only add it to the few materials that actually need it. I don’t think this is going to be a common issue.
As to the P.P.S.: True. I will add that if I’m looking for the difference, I can spot it down to about 0.3. When I’m not looking for it, Lumen starts to appear visibly warm to me around 0.7.
I guess maybe Archvis might get some use out of it - they love their bright modern walls, but they’re also the most likely to run into the issue of reflections being too blue.
For the Blumen, I will say the contrast between the lights/darks is a BIT more stark than PT, but in a soft way that makes them pop w/o being noticable.
Looks güd.
There is now an official issue created by @FazeDank with a proposed solution to allow changing the target formats to R9G9B9E5_SHAREDEXP.
Quite interesting, thanks for the info!
This was just fixed in UE5-Main: https://github.com/EpicGames/UnrealEngine/commit/a7a195dc7aed6d4f5cef36e961bdfcf4a317525b
OMG! Thank you very much for this!
oh hell yeah
broken link. Is it supposed to be fixed in 5.4 or next versions?
Not broken, you are not logged in.
If it was added in UE5-main, it won’t be added in the current version.
