Add AgX and AgX Punchy tonemapper options to Environment #87260
Conversation
Calinou
force-pushed
the
tonemap-add-agx
branch
from
8ca7b7d
to
4217f1e
Compare
Calinou
force-pushed
the
tonemap-add-agx
branch
from
4217f1e
to
7e101f9
Compare
Calinou
force-pushed
the
tonemap-add-agx
branch
from
7e101f9
to
37ec580
Compare
|
Maybe not related to this pr, but why does the red light for example, leak through? 
|
That's just due to how the reflection probe is set up in the scene (one probe near the red box covers the entire scene). It's not related to this PR 🙂 |
|
Hi. What version of AgX is being implemented? Troy's / or Eary's branch (the one included in blender) 
|
This relies upon the implementation found in this article, which I believe is closer to Troy's version (but not 100% identical). |
|
Thanks for the clarification. You are right, if you compare the example of the sweeps (from Troy) with the one on the website you shared, they are similar, only the red seems more saturated than in the original implementation, and since in the code the punchy version has an increase in saturation of 1.4 I think that can end up creating unwanted clipping, and it seems to be messing with the luminance values?. |
|
Not sure if it's helpful but you can also look at three.js's implementation as reference: BTW the term "white point" has a very specific meaning in RGB color, it means the chromaticity of R=G=B, in a lot of colorspaces like Rec.709, sRGB, Rec.2020 etc. it's D65, for other spaces like DCI-P3, they have their own white points like the DCI "theatre" white point. So when the PR says something about white point being 16, it looks very confusing. |
Godot doesn't have color management, so it uses an arbitrary whitepoint unit. Higher values result in less blown out highlights, but will slightly darken the whole scene. There are diminishing effects to increasing the whitepoint value, so usually, a value like 10 will look pretty close to something like 20. |
My point is, "white point" is a widely accepted language for chromaticity, I.E how warm, how cold should the white be, not brightness or intensity. A white point value is usually a CIE XYZ or CIE xyY coordinate (For example, D65's CIE XYZ is [0.95047, 1, 1.08883]), not a scalar value. If Godot uses a scalar value to refer to an intensity value and then call it "white point", the terminology is confusing. As for the white clipping point, how steep the curve is also affects the rate of change in gradients. It's best to test against EXRs like Red Xmas etc. to make sure things are still smooth. |
|
@Calinou Greetings! Is the feature gonna be in 4.3? Would be nice to have alongside with the new Global Illumination to achieve overall proper lighting and coloring in complex scenes. |
I can't give an ETA for merging this, as this PR still needs a review from other contributors before it can be merged. |
|
Google's Filament uses slightly different matrices. It says that the matrices are taken from Blender's AgX implementation. Below are the differences between the implementation in this PR and the Filament (Blender) implementation using a custom software renderer as an example. There is almost no difference, but the Filament (Blender) implementation gives a slightly darker image.
|
There was a problem hiding this comment.
I absolutely love the AgX Punchy tonemapping. I have merged this pull request in my custom build and have been using it in compatibility mode in VR with the meta quest 2.
I'm a big fan of cartoony saturated colors, and I always need to do color correction after the fact with a LUT or with the "adjustment" post processing to adjust contrast/saturation, with the AGX Punchy tonemapping I feel I don't even need further color correction, I'm getting pretty much the colors I want right away. I'll be using this in all of my projects moving forward, thank you!
All images taken with Exposure 0.7 and White 10 in Compatibility Mode with the Compatibility Mode Glow PR
| Tonemap | Far view | Close up |
|---|---|---|
| Linear |  |
 |
| Reinhard |  |
 |
| Filmic |  |
 |
| ACES |  |
 |
| AgX |  |
 |
| AgX Punchy |  |
 |
|
Thanks! I really enjoy how "natural" AgX looks, as I did not like how ACES compressed the dark colors. This is really noticeable when using global illumination. AgX seems a bit brighter than the others. AgX punchy is a bit too punchy for my use-case (I'm sure it looks better after tweaking the assets for a bit.)
(Car model CC-BY Link to Sketchfab ) |
|
It would be really nice if you guys could prioritize this for 4.3 Tonemappers affect the whole asset production pipeline, so with this we could go ham on making the assets without worrying that they'll look different later when upgrading to the release build. |
There was a problem hiding this comment.
Did a quick test, big fan of the results. AgX is doing a better job at compressing bright values compared to ACES
Exposure was adjusted to get approximately the same look (AgX needs about twice as much exposure compared to ACES)
With ACES it's always a struggle for me to not get overexposed values (notice how in AgX the pavement isn't overexposed while the shadows still retain the details):
|
Comparison on Tonemapping a HDRI:
(Used 6.0 for white in Godot)
|
This feature is also important for any global illumination upgrades since it will help a lot to achieve properly exposed areas (with more accurate colors in both dark and lit areas). Currently it's nearly impossible to achieve with existing modes. |
Want to comment on this. Originally Troy's original Punchy included a boosting of "CDL Saturation", on top of the original AgX that DID NOT HAVE OUTSET MATRIX!. And afterwards in later edition, we added the ouset matrix to the Base AgX, then in Troy's version, "Punchy" was then completely removed. (Note there we also designed a "rotation" included in the inset/outset matrix, reason will be stated later in this post.) I choose to add back the Punchy look, but since the boosting of "CDL Saturation" has already been replaced by the outset matrix, it's not needed anymore. So in the version I submitted to Blender, the Punchy look is a simple darkening without the boosting of "CDL Saturation". The original Punchy was a simple 1.35 power curve after AgX Base formation (which darkens the image), but due to OCIO's constrain, OCIO Looks are required to be pre-AgX-Base-Formation, so I had to move it to AgX Log pre formation, I tried to use some different curves to achieve in the final image the approximately the same middle grey and roughly the same "black level" as the post formation 1.35 power curve, though of course not going to be completely identical. If the doubling of outset + "CDL Saturation" is what you folks think looks better, then feel free, but I have to stress the importance of checking out those EXR files I linked up there, please make sure after your modifications that those gradients in those EXRs are still smooth as always! Too much post formation chroma boosting can lead to unsmoothness, as some boundary condition might be triggered.
I advise either go make your own rotation matrix by testing against many different challenging EXRs, or use the same one right there, it's for some compensation for Abney Effect etc. (note it's not a fix, it's currently impossible to fix Abney Effect, but the rotated matrix was tested by myself to at least somewhat compensate for it.) (Also note that the matrix was supposed to be used in BT.2020 formation space. I have already mentioned this in the three.js PR page I linked here earlier.) |
|
Using the EXR EaryCrow provided, you can see something is off with Godots AgX. |
|
Blender Cycles CPU viewport clips negatives. Better view it in compositor. Just click use nodes, drag and drop exr, and shift ctrl left click. Or at least use Cycles GPU viewport. |
|
Rebased and tested again (with no other code changes), it works as expected. |
|
Took some time today and manually recalculated the inset and outset matrices. They should now be more in line with the fork of AGX that blender uses: const mat3 agx_mat = transpose(mat3(
0.544813, 0.37379614, 0.08139087,
0.14041554, 0.75414325, 0.10544122,
0.0888119, 0.17888511, 0.73230299));
const mat3 agx_mat_inv = transpose(mat3(
1.96489403, -0.85600791, -0.10888612,
-0.29930908, 1.32639189, -0.02708281,
-0.16435644, -0.2382074, 1.40256385));In my own fork I also switched to a 7th order approximation, but that had very little impact on the final result. In my own test these matrices result in slightly better results, e.g. look at the faces when viewing https://github.com/sobotka/Testing_Imagery/blob/main/red_xmas_rec709.exr. The overall image is still a bit too bright, but setting white to 16 (to match AGX default value) and slightly reducing exposure now results in results that (at least on my monitor) are near identical to blender. |
|
@Ansraer Thanks 🙂 I've incorporated the suggested matrices: See OP for updated screenshots. Note that ReflectionProbe cubemap filtering has changed since then, so the rough reflections can appear to look different, but this is not due to the tonemapper. The whitepoint issue makes me wonder whether it should just be hardcoded to Comparison between the previous matrices (before) and the ones that are used now (after):
|
Calinou
force-pushed
the
tonemap-add-agx
branch
from
b65fa87
to
e8a24fa
Compare
@Ansraer Do you have an implementation that does not use an approximation that we could play with as a reference? This would help us give a second set of eyes on this choice. |
Calinou
force-pushed
the
tonemap-add-agx
branch
from
e8a24fa
to
c3647bf
Compare
|
As discussed in yesterday's rendering meeting, I've amended the PR to hardcode the whitepoint to This is ready to merge on my end. |
|
I've updated my previous comment with new screenshots from c3647bf ("Before" screenshots are from before the new matrices were integrated with whitepoint set to 16.0.)
Before the new changes were made, I didn't take screenshots of Punchy with a 16.0 whitepoint, so those aren't as good for side by side comparison. |
|
Been using this in a personal project - would really love to see this get merged into the engine. Finally a tonemapping that looks good! |
|
@Calinou can someone merge this? IMO: looks good already, can be further improved later. |
It first needs code review from rendering team like clay. |
We could 100% put this in a future PR and merge this into 4.4 |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@ArseniyMirniy You already made your point once, that's why I hid your second comment. But please, don't comment to pressure the team to merge features. We, as a team, don't want to merge an half-baked feature, and then break projects that worked around the issues in a future release. And these kind of comments aren't useful, development-wise. |
|
@WrobotGames can you do a comparison between Godot and Blender again like you did above, but using the updated version of this PR? I want to ensure that we are as close as possible to the results in Blender before merging |
|
@WrobotGames when doing the comparisons, please also make sure to actually render the image. I am no expert when it comes to blender, but apparently the colors in the viewport/editor itself might not always be 100% correct. |
|
@clayjohn Here is a quick comparison of some test images. This PR looks a lot better since the last time I looked at it! While I think it looks good, it still deviates quite a bit from blender.
Other than that, there are some minor differences visible, for example the hair in the last photo is ever so slightly more blue in the Godot render, but I am not sure how close we can get to replicating blender AxG, as Godot is a real time renderer. This PR handles bright colors way better than the ACES in Godot. The 'punchy' look in blender is just the exposure turned one stop down, while the Godot version also increases saturation. I do not mind this as it is just a non-default 'look' in blender anyways. I enjoy how the Godot punchy makes the images pop: |
I've made a couple of HDR images that can also be used for comparison. Here's the Godot project:
Edit: Here's an updated project that has borders on the HDR image for easier alignment of screenshots for a better 1:1 comparison: There are two OpenEXR files and one Photoshop source file alongside the Godot project and test scene. Here's what it looks like with the Linear tonemapper in Godot:
Looks like I was slow to the punch for getting this into your comparison, @WrobotGames, but if you are able to share your Blender scene, I could try the comparison myself. (I'm not that experienced with Blender... I can see in your screenshots how to change the tone mapper, but I'm not yet sure how to set up an image and scene correctly.) |
|
@allenwp No problem, here is a quick comparison. |
|
Thanks @WrobotGames! Now that I see them in practice, I can tell that it's hard to align the images for comparison, so I've updated the HDR images to have borders for easier alignment in future tests: Godot-project-HDR-sRGB-saturated-colors.zip (with borders) This is what I see when I try to align the first set of images, but they don't align quite right, so take it with a grain of salt. 2024-10-29.14-30-48.mp4 |
I'm a complete newbie when it comes to Blender, so I'm not sure how to set up a scene in Blender that is "unshaded", like an unshaded material in Godot would be. It seems that you were able to get a very good 1:1 comparison to an unshaded Godot material in your Blender test scene, @WrobotGames... Would you be able to share this scene for us to review? I just made a third update to my OpenEXR test images that could be included in this scene if you'd like. I say this because I think it would be good to get a second set of eyes on exactly what it is we're trying to "get close to" and whether that even makes sense with the differences in Godot rendering and Blender rendering. Further to this, if the decision is made to make more changes to this PR before merging, it would be good to have a standard test scene that we all agree upon as a reference to target with our Godot implementation of AgX. |
Connect the color directly to surface output |
When doing this, make sure the renderer is cycles with the gpu. (Cycles CPU and Eevee can sometimes differ a bit.) Another method (and the one I used) is to go to the compositor tab in blender, click "use nodes," and then drag in the image and connect it to the output. Since the image is not getting rendered, you do not have to worry about which renderer you selected. |
|
punchy looks great in my game |
|
I've created a new way of comparing Godot to Blender with EXR files. The SDR renders are in here: https://github.com/allenwp/godot-tonemap-comparison/tree/main/sdr_renders You can use a tool like https://www.diffchecker.com/image-compare/ to compare the renders. I'll add notes to the repo on how to use it sometime in the next week. It includes a Godot project that automatically generates SDR webp files from HDR textures using different tonemappers in Godot. It also includes a blender file that has the compositor set up for easy saving of SDR renders from Blender. |
|
...And here's a full comparison of AgX and AgX Punchy in Blender vs. this PR. I recommend opening the Blender and Godot render in two different tabs, and then tabbing back and forth to compare. Of course, there are lots of other ways to compare the two images, since they align and have the same dimensions. If you want to also see Blender's Filmic vs. Godot's Filmic with a 6.0 (I've listed these as links instead of embedded images because this PR conversation is already image-heavy. I think for the goal of making the Godot render as close to the Blender render as possible, side-by-sides are less helpful than other comparison methods.) Saving the Blender SDR renders was a manual process, so let me know if anything seems out of place with any of them. It was pretty fast and easy because of the compositor method that @WrobotGames suggested. Thanks for the tip! Please let me know if you want any of these regenerated or if you want me to add additional HDR textures to the comparison. It’s really not much effort now that I’ve got it scripted. |
Thanks to @begla for providing this code under MIT license and helping with the whitepoint configuration 🙂
Testing project: godotengine/godot-demo-projects#857
TODO
Preview
All images use whitepoint 6.0 unless otherwise mentioned.
Footnotes
This demo is currently not designed with Compatibility in mind, so the surface colors are incorrect. Nonetheless, the tonemappers work. ↩