Is there a way to get normal maps to work with subsurface scattering using materialx? It only seems to work using the principledshader. And if so could I get it working with karma xpu? Thanks

I'm not sure what you mean. Normal maps can be used with the standard surface in MaterialX, but the effect of the normal on subsurface is minimal. The VEX subsurface bsdf in for karma doesn't take normal as an input, so it probably doesn't take normal into account under mtlx either.

Normal maps don't seem to be working at all with subsurface scattering using materialx standard surface material in Houdini 19.5.303. I thought I saw in the demo video for Houdini 19.5 a Capybara with subsurface and normal maps using mtlx in xpu. I cant get the normal maps to work with subsurface scattering at all using cpu or xpu.

tarincamarena
Normal maps don't seem to be working at all with subsurface scattering using materialx standard surface material in Houdini 19.5.303. I thought I saw in the demo video for Houdini 19.5 a Capybara with subsurface and normal maps using mtlx in xpu. I cant get the normal maps to work with subsurface scattering at all using cpu or xpu.

normal maps don't affect subsurface scattering. Since the scattering is determined by raytracing inside the surface, normal maps won't have any effect. They will affect fresnel blending and the specular term though, which is what you see with the principled shader.

jsmack

tarincamarena
Normal maps don't seem to be working at all with subsurface scattering using materialx standard surface material in Houdini 19.5.303. I thought I saw in the demo video for Houdini 19.5 a Capybara with subsurface and normal maps using mtlx in xpu. I cant get the normal maps to work with subsurface scattering at all using cpu or xpu.

I see. So I just need to make the character more shiny for bump to show with subsurface scattering. I realized the path for my roughness map got broken so that's why the character wasn't shiny. I reconnected the texture and it seems to be working now as expected. Thank you!

Well atleast with Karma CPU. It looks a little strange with xpu?

tarincamarena
Well atleast with Karma CPU. It looks a little strange with xpu?

I think it's probably texture resolution.
With XPU there is a global texture resolution clamp of 2048
You can change that via an environment variable
eg
export KARMA_XPU_MAX_TEXTURE_RES=8192

Shouldn't all these envvars be exposed as parms on the karma lop?

I could imagine wanting to set this per project or even per shot. It'll get frustrating if we have to keep jumping out to shells or the windows envvar editor to alter these xpu specific settings.

mestela
Shouldn't all these envvars be exposed as parms on the karma lop?

I agree, to get most out of each render the texture resolution limit may literally need to be different for each Karma Settings in the same file, which should be immediately reflected in the viewport when rendered

mestela
Shouldn't all these envvars be exposed as parms on the karma lop?

I could imagine wanting to set this per project or even per shot. It'll get frustrating if we have to keep jumping out to shells or the windows envvar editor to alter these xpu specific settings.

big +1 to this. hopefully these things will largely be exposed once we're out of beta?

ChristopherRutledge

mestela
Shouldn't all these envvars be exposed as parms on the karma lop?

I could imagine wanting to set this per project or even per shot. It'll get frustrating if we have to keep jumping out to shells or the windows envvar editor to alter these xpu specific settings.

big +1 to this. hopefully these things will largely be exposed once we're out of beta?

How would it be exposed though? If it was a primvar on the rendersettings, they you'll see the texture resolution jump around if you display different parts of the graph, potentially requiring a renderer restart and full texture flush every time you move the flag around. That sounds not ideal.
The other way would be as a flag for husk, but then it won't have any effect when rendering interactively. it's not like rendering with a rop where the endpoint is the same no matter what.
An env var seems like the only way to globally control the setting without causing inconsistency within a session.

Once we have full out-of-core texturing working, we're hoping we can get rid of this global texture resolution limit altogether. So that is why we have not worked it into the UI. It's really just a temporary stop-gap.

To give some context

H19
loaded all textures into GPU memory before rendering, with the global 2048 texture res limit.

H19.5
loads texture tiles on-demand (ie when needed) while rendering. Although more efficient with memory, it still applies the global 2048 texture res limit. This is because (especially in IPR mode) the GPU ram can still fill up over time (imagine the camera moving all over the scene) and eventually fail the device.

H20
We hope that XPU will load texture tiles on-demand (ie when needed) while rendering and also evict old texture tiles when the GPU ram gets full. So I would consider this to be "proper" out-of-core behavior, and hopefully, we won't need the global resolution limit. Although the GPU will still be running rather slow in this mode (ie thrashing). Perhaps we can make the per-device indicator in the top-right of the screen glow red when this is happening.


Please note that with H19.5, we actually flush the GPU ram of textures each frame when doing offline (ie husk) rendering.