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

I believe there is the Color Limit (which should apply to CPU and XPU though)which is 10 by default.
Maybe XPU and CPU handle this differently. Have you tried increasing it in the Limits Tab of the render settings?

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

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?

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:

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?

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

Since 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)
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

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?

tamte

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

Since 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)
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!