I am trying to render a speedtree as point instances on Karma but I am having issues with some textures rendering black and dark on XPU where in CPU it working correctly.
I know that XPU have some requirements about proportion and size which I made sure that at least the limit size is inside the limits but I am not sure about how proportion/size works.
Any tips?

Hi
you need to make a basic scene that demonstrates the issue (textured quad using the texture which is giving issues).
Then post the scene + texture, so we can load it on our end to see what the issue is.

If the material is sensitive (ie you can't post it publically), then make a bug report instead and post it there

cheers

Thanks for the feedback!
Sure I will do that, can you tell if uvs values much bigger than 1.0 and non squared textures can give issues on XPU?

Here it is, you just need to update the $JOB to fix the paths for all textures, point to the root of the folder that you are extracting.

It is a tree generated by speedtree trial so you are going to see holes in the mesh, there are 10+ material x's shaders with different textures.

Here is the link to the file:

zip file 15MB [drive.google.com]

Let me know if it is working on your end.

mzigaib
can you tell if uvs values much bigger than 1.0 and non squared textures can give issues on XPU?

Should be working fine

mzigaib
Let me know if it is working on your end

Sure, will do!
thanks for sending it through

Well.... I was expecting a single textured quad, but instead I got your actual scene?

In any case I've found the issue.

There are a lot of missing textures in your scene.
When the MtlxImage node cannot find a file on disk, it (should) instead return the value of the "default color" parameter, which defaults to black. XPU implements this. But KarmaCPU does not, instead returning the standard "houdini missing texture" color of pink.

When channel 0 of "black" is fed into the MtlxStandardSurface.base value, it renders pretty much black. (this is what XPU is doing)
When channel 0 of "pink" is fed into the MtlxStandardSurface.base value, it renders normally. (this is what KarmaCPU is doing)

In this case, XPU is the one that is behaving more correctly, even though it appears that KarmaCPU is giving a better result.
I've attached a simple textured quad scene to demonstrate this issue.
And I'll file a bug report so that KarmaCPU can implement the more correct MaterialX behavior.

Thanks for sending through this issue
Brian

Dude! Thank you for this awesome feedback!
I did install build 400 and I though that was working better I was thinking that the issue was the aspect of some textures where this fix on 400 build was addressing:

"XPU: fixed an Optix texture bug which could happen with very tall or wide textures (eg 256x4)"

Which I think was the case of a lot of issues but this was just my impression.

Anyway thanks again for looking at the file.

mzigaib
"XPU: fixed an Optix texture bug which could happen with very tall or wide textures (eg 256x4)"
Which I think was the case of a lot of issues but this was just my impression.

hmm...
the fix that comment is referring to was when a texture is VERY thin (in either X or Y direction)
eg
- 256 x 4
- or 4 x 256
(saying "tall or wide" was probably a poor choice of words come to think of it :/)

typically this would only happen when people bake ramps to textures. Its hard to imagine an artist actually authoring something of that shape. Perhaps it may have occurred with auto-generated textures/data from the speedtree output? I'm not sure, I didn't look very deep into the speedtree scene

Here is another example also from speedtree and texture issues/differences between CPU top / XPU Bottom. I am using point instancing by the way with build 368.
It seems that in XPU the some textures are not mapped correctly mainly with the leaves but the color is there, maybe an uv issue?

As a note, in today's daily build of H19.5, Karma CPU should be respecting the default color when there are missing images in Mtlx shaders - so the initial scene should be much closer between CPU and XPU.

mark
As a note, in today's daily build of H19.5, Karma CPU should be respecting the default color when there are missing images in Mtlx shaders - so the initial scene should be much closer between CPU and XPU.

I will double check but I don't think there is missing textures as you can see on the CPU render, if that is the case what could be the issue?

mzigaib
I will double check but I don't think there is missing textures as you can see on the CPU render

The scene you posted on October 12th had many missing textures.
The missing textures exposed a difference between KarmaCPU and KarmaXPU which Mark says is now fixed.

mzigaib
if that is the case what could be the issue?

Do you mean with this UV issue?
Please test with the latest version of Houdini (as Mark says), and if you still have issues, please...
- isolate the problem (ie a single/minimal asset, not your whole scene)
- post another repro case
- and we'll take a look

thanks very much

Thank you very much for the feedback!

brians
The scene you posted on October 12th had many missing textures.
The missing textures exposed a difference between KarmaCPU and KarmaXPU which Mark says is now fixed.

This is another scene.

brians
Do you mean with this UV issue?
Please test with the latest version of Houdini (as Mark says), and if you still have issues, please...
- isolate the problem (ie a single/minimal asset, not your whole scene)
- post another repro case
- and we'll take a look

thanks very much

Yes with this current uv issue.
I will test with new build soon as I can install it, and I will send a file soon as I can.

Cheers and thank you again.