Do you match the color profile between S. Painter and the rendering engine (Blender, UE, Unity)
Hello everyone, I've been researching how to match the 3D viewer of Substance Painter with Blender or other engines, for example Unity, Unreal engine. I've seen that there is an ACES color profile to standardize the visualization of 3D viewers but I have some questions.
Do you usually use color profiles, or do you simply roughly match the color without using any standard outside of the one that comes by default in Substance?
I want my assets to look good in Unreal, Unity, Blender or even Godot, I don't know if it's easy to use ACES in all these software or if you consider that it is not necessary to use it.
At a personal level, do you work with these color profiles or simply accept that each software will render textures differently and try to create textures for models in Substance with the default color profile and use accumulated practice to look the best in the rest of the software?
I will publish some screenshots showing what I mean.
In the screenshots I use Substance painter 2019.1.3 (default color profile) and Blender 3.4.0 (default color profile in viewport shading and the same HDRI as in Substance Painter)
As you can see, the 2 results are not exactly the same in the two software.
I know that Substance already comes with the ACES profile as an option to select, in my case, I have an old version of Substance since I haven't updated the license since then, so if I want to use an ACES profile in my workflow I will have to use the ACES LUT For Substance Painter alternative (https://bleleux.gumroad.com/l/lHiVg)
I would like to know if you use the ACES color profile in your workflow, since I don't fully understand the importance of this, I am confused since Blender does not have the ACES color profile option by default considering it a standard and not finding it in updated software makes me feel confused, I also don't find much documentation on this online.
Thank you very much for your attention. Greetings!
Replies
The thin
gwith ACES is not that much standard yet actually. Not in gamedev at least. Rather sRGB still is . That small "s" is for "standard". And Aces itself has different implementations.An amazing thing is that when you look at Unreal page about ACES tone-mapper you instantly see how wrong it is .
https://docs.unrealengine.com/5.1/en-US/color-grading-and-the-filmic-tonemapper-in-unreal-engine/
Notice how blue ball gets magenta magically under an intense light . A thing you would never see in reality . Blender Filmic view transform does it more realistically IMO. Something with so called gamut mapping .
ACES is still in the process of sorting out its weird stuff.
Our renderer guy says ACES while doing many right things still a sort of video-card atmosphere heating in half . In VFX they do it most complicated and convoluted way ever possible just because they can and their budgets. In games it have to be simple.
So my suggestion just ignore it altogether until it's absolutely necessary. The look depends on illumination intensity, tone mapping and auto exposure settings. It would be different anyway.
The standard practice in games is... there are no "standards" because everyone has a different pipeline. Different DCCs and different engines.
In general, it helps to limit your pipeline to only relying on the game engine as your "source of truth".
It helps to try to adjust your DCCs (Maya and Substance, for a common example) to use similar render settings as your game engine (Unreal for example). However in practice we never get an exact match.
So the key is to use PBR guidelines which assure you physically plausible materials, that will work in a wide variety of lighting.
And then verify in your target engine, with representative in-game lighting.
You want your assets to look good in Unreal, Unity, Blender or even Godot... but all these will not match each other. The best thing you can do is to work within PBR limits.
Perfect is the enemy of good enough. It's a good idea to have Substance and your target render engine setup to look very similar so what you're seeing is what you're getting, but it doesn't need to be perfect, no one is going to notice.
Thank you very much for all your answers. So I will continue as always and won't take the trouble of worrying about this, I will accept that my models look different between each software. Ultimately, I will continue with the same workflow that I have been doing for years.
Sometimes, when I see some news about the subject, I have doubts if I am doing it wrong and that's why I generate these topics in the forum.
Greetings and thank you all for responding and sharing your opinions on the matter.