So when rendering in Karma XPU, if you make a standard surface MTLX shader and set the base color rgb to: 10, 1, 1. The render output should be white, which is correct.
Now when you lower the exposure of the viewport/renderview the material should turn red, since the R value was way beyond 1, but it just stays white and gets darker.
Karma CPU doesn't have this clamping. Does karma XPU have some sort of internal clamping/am I missing a button, or because of Karma XPU is still beta?
Kind regards,
Chris
Karma XPU clamped materials?
2966 8 2- Klonkel
- Member
- 79 posts
- Joined: March 2016
- Offline
- No_ha
- Member
- 123 posts
- Joined: Sept. 2018
- Offline
- jsmack
- Member
- 8043 posts
- Joined: Sept. 2011
- Offline
Klonkel
So when rendering in Karma XPU, if you make a standard surface MTLX shader and set the base color rgb to: 10, 1, 1. The render output should be white, which is correct.
Now when you lower the exposure of the viewport/renderview the material should turn red, since the R value was way beyond 1, but it just stays white and gets darker.
Karma CPU doesn't have this clamping. Does karma XPU have some sort of internal clamping/am I missing a button, or because of Karma XPU is still beta?
Kind regards,
Chris
shouldn't albedo be clamped? Although, I've abused it not being clamped for sure
- Klonkel
- Member
- 79 posts
- Joined: March 2016
- Offline
jsmack
shouldn't albedo be clamped? Although, I've abused it not being clamped for sure
Hmm, yes that could be.
I was actually recreating the hextile asset from the tech challenge, butnthen for karma xpu:
https://www.sidefx.com/community-main-menu/contests-jams/tech-art-challenge-2022/ [www.sidefx.com]
Big props to: Mohsen_Tabasi!
When I ‘finished’ recreating the asset in mtlx I saw something was off, so started debugging and then came to notice that after the ‘texturing maths, deforming uv spaces etc’ the greens for example were just straight clamped (XPU). But when I switched to CPU it wasn’t and the uv tiles started to appear when lowering the viewport exposure.
Then checked it with just the basecolor of mtlx standard surface with the reds, same thing, the beauty was clamped on white when xpu, but got red when changing the exposure on cpu.
It’s probably bot clamped when getting lit by an extreme bright light, but the mtlx shaders clamp something it seems like. Atleast for xpu?
- Klonkel
- Member
- 79 posts
- Joined: March 2016
- Offline
Sorry for the late response, didn't have access to houdini lately.
Anyway, this is the example, everything is the same (shader etc) and this is what the render looks like.
And this when having toned the viewports' exposure down. Whereas the CPU render (right) does it correctly and shows the diamonds and the XPU render had just clamped everything.
EDIT: When I increase the intensity of the domelight to +10 the image does get values way above 1, so it seems like it isn't the renderer which clamps, but the material.Still XPU:
Anyway, this is the example, everything is the same (shader etc) and this is what the render looks like.
And this when having toned the viewports' exposure down. Whereas the CPU render (right) does it correctly and shows the diamonds and the XPU render had just clamped everything.
EDIT: When I increase the intensity of the domelight to +10 the image does get values way above 1, so it seems like it isn't the renderer which clamps, but the material.Still XPU:
Edited by Klonkel - March 8, 2023 06:56:42
- brians
- Staff
- 531 posts
- Joined: May 2019
- Offline
I can confirm that XPU clamps things like albedo (ie basecolor) to 1.0, because that is what the control is physically meant to be. Albedo should only reflect (at most) 100% of the light that has reached it. An albedo >1 would be adding light to a scene, which is outside the scope of what albedo represents.
A minor benefit is that it reduces memory usage too (a 0->1 number can be stored in 16bits, going above 1 needs full 32bits)
So the question is...
- should XPU behave like CPU and allow albedo/basecolor to go above 1.0?
- or stay the way it is
It seems XPU should allow it to go above 1.0 given its a feature some people make use of now and then?
A minor benefit is that it reduces memory usage too (a 0->1 number can be stored in 16bits, going above 1 needs full 32bits)
So the question is...
- should XPU behave like CPU and allow albedo/basecolor to go above 1.0?
- or stay the way it is
It seems XPU should allow it to go above 1.0 given its a feature some people make use of now and then?
- tamte
- Member
- 8833 posts
- Joined: July 2007
- Offline
briansSince SideFX is trying to be compatible with MtlX it's the best to conform to the specs? (I'm not sure how it's defined there)
So the question is...
- should XPU behave like CPU and allow albedo/basecolor to go above 1.0?
- or stay the way it is
Or submit a proposal of what would be the ideal way
Then there is highest chance that CPU, XPU will produce similar renders not only between each other but also among other renderers using the same MtlX shader networks
Tomas Slancik
FX Supervisor
Method Studios, NY
FX Supervisor
Method Studios, NY
- jsmack
- Member
- 8043 posts
- Joined: Sept. 2011
- Offline
brians
So the question is...
- should XPU behave like CPU and allow albedo/basecolor to go above 1.0?
- or stay the way it is
It seems XPU should allow it to go above 1.0 given its a feature some people make use of now and then?
The classic shader had the old 'conserve energy' toggle. Maybe something like that could be exposed somewhere?
- JasonSlab
- Member
- 1535 posts
- Joined: March 2020
- Offline
tamtebriansSince SideFX is trying to be compatible with MtlX it's the best to conform to the specs? (I'm not sure how it's defined there)
So the question is...
- should XPU behave like CPU and allow albedo/basecolor to go above 1.0?
- or stay the way it is
Or submit a proposal of what would be the ideal way
Then there is highest chance that CPU, XPU will produce similar renders not only between each other but also among other renderers using the same MtlX shader networks
This is the way!
fx and lighting @ rebelway
https://www.youtube.com/@jason_slab
https://www.youtube.com/@jason_slab
-
- Quick Links