I've run into problem on an character with nasty normal on the mesh when rendering, but after switching to CPU, those are gone. Any ideas whats happening and how to sort it out on XPU as well?

Have you tried render to mplay? I've had similiiar issue but it was only in viewport

Could it be malformed USD that XPU is ignoring?

Not sure really, on redshift, tesselation sort this out. It is vissible on mplay as well.

Mirko Jankovic
I've run into problem on an character with nasty normal on the mesh when rendering, but after switching to CPU, those are gone. Any ideas whats happening and how to sort it out on XPU as well?

Is it possible to submit a bug report with repro scene?
thanks

Submitted bug report. Thank you!

Also to add on same topic, same project, different character. Here I can see also couple issues on the surface, along with color difference. Same scene just switching between CPU and XPU

An update on issue about those nasty splotchy parts. Seems like when I use couple specific HDRs for lightning from dome it creates those. I used other HDRs and it is less visible or visible from some angles. And with dome only no HDR or physical sky it looked completely fine. Looking more into it as well. Still works fine in CPU

Just checking in on subject.
I'm now on up to today latest daily build 20.0.599 And I still have same mesh issues and differences between CPU and XPU.
I was wondering if there are any additional options maybe to turn on on USD imported objects to subdivide or sort out this issue on the mesh?

what does the topology look like? Is it just due to poor mesh quality? Does the mesh have normals?

True topology isn't the best but it shows up fine in Maya with smoothing, also Redshift with it's tessellation on works just fine.
If I import alembic and then subdivide mesh that also works fine.
So I'm wondering if there is some step I'm missing to export animated mesh from maya to USD and then loading in Houdini for rendering?
I know that USD is not really just a simple geo cache like alembic but in this case I'm using it like that as it works much faster compared to alembic and looking to expand USD usage but for now trying to transfer animated character mesh from Maya to Houdini to render in Karma XPU.
Am I missing some export / import steps maybe?

I've paste link to that same usd if someone care to give it a try, I'm still finding my way around Houdini so it could be simply some beginners mistake in import.
Appreciate any help!

https://www.dropbox.com/scl/fi/0rwm9k54x599aw198ccnr/Plava_Ptica_0-149.usd?rlkey=0wcyjespysewiptb82eqsydgc&dl=0 [www.dropbox.com]

Hi guys

We've isolated the issue to a bug with XPU dome lights.
Karma XPU performs mipmapping (when combined with sampling produces the issue), whereas Karma CPU does not perform mipmapping.
So nothing wrong with the geometry

In short, we're still working on it.
But in the meantime you can work around the issue by setting the DomeLight setting "Maximum HDRI Size" to the size of your HDRI (eg 8k or whatever). And actually, you can just set it to something massive (eg 100000) and XPU will clamp it accordingly. This will solve the problem in the short term.

Thanks for your patience

Ah thank you! At least I can stop chasing my mistakes
Thank you!

I have committed a fix for this in 20.0.563

In short, we have disabled mipmapping for textured light sources (ie dome lights and textured rectangle lights) in XPU. This means the artifacts will disappear, but lighting will also look slightly darker after this change. But it does at least match Karma CPU more closely.

To get lighting to match 100% what it should be, setting the "Maximum HDRI Size" to the size of the HDRI (or just 100000) is the recommended approach. This will work for both KarmaCPU and KarmaXPU.

We'll be looking to fix this darkening issue in a later version of Karma.

Thanks for your help + patience on this issue.

brians
I have committed a fix for this in 20.0.563

In short, we have disabled mipmapping for textured light sources (ie dome lights and textured rectangle lights) in XPU. This means the artifacts will disappear, but lighting will also look slightly darker after this change. But it does at least match Karma CPU more closely.

To get lighting to match 100% what it should be, setting the "Maximum HDRI Size" to the size of the HDRI (or just 100000) is the recommended approach. This will work for both KarmaCPU and KarmaXPU.

We'll be looking to fix this darkening issue in a later version of Karma.

Thanks for your help + patience on this issue.

does this mean that rat images won't be generated for light textures any longer?

Brian,

Won't this affect the quality of visible dome lights in renders and re-introduce moire crawling on thin features? See the bug filed (and fixed) from a couple months ago here:

https://www.sidefx.com/bugs/#/bug/132299 [www.sidefx.com]

jparker
Brian,

Won't this affect the quality of visible dome lights in renders and re-introduce moire crawling on thin features? See the bug filed (and fixed) from a couple months ago here:

https://www.sidefx.com/bugs/#/bug/132299 [www.sidefx.com]

you could use a textured sphere where it needs to be visible. Then mipmapping would work as usual.

jparker
Won't this affect the quality of visible dome lights in renders and re-introduce moire crawling on thin features? See the bug filed (and fixed) from a couple months ago here:

Oh wow, I was not aware that Karma CPU is now using mipmapping on dome lights (Dan is away on vacation)
I think I'll revert this commit and revisit this issue in the new year.
Thanks for letting me know Jon.

Luckily Mirko has a workaround by setting the "Maximum HDRI Size" light parameter.

jsmack
does this mean that rat images won't be generated for light textures any longer?

Well, it would have meant that, but now I'm going to revert it so the light textures will continue to get rat-ified.


thanks guys

jsmack

jparker
Brian,

Won't this affect the quality of visible dome lights in renders and re-introduce moire crawling on thin features? See the bug filed (and fixed) from a couple months ago here:

https://www.sidefx.com/bugs/#/bug/132299 [www.sidefx.com]

you could use a textured sphere where it needs to be visible. Then mipmapping would work as usual.

Aside from scaling issues we have in our scenes with USD and extremely large transforms which can make using a sphere more complicated than a dome light, there is a measurable render speed difference, with spheres being a fair bit slower.

brians

jparker
Won't this affect the quality of visible dome lights in renders and re-introduce moire crawling on thin features? See the bug filed (and fixed) from a couple months ago here:

Oh wow, I was not aware that Karma CPU is now using mipmapping on dome lights (Dan is away on vacation)
I think I'll revert this commit and revisit this issue in the new year.
Thanks for letting me know Jon.

Luckily Mirko has a workaround by setting the "Maximum HDRI Size" light parameter.

jsmack
does this mean that rat images won't be generated for light textures any longer?

Well, it would have meant that, but now I'm going to revert it so the light textures will continue to get rat-ified.


thanks guys

Great to know, thanks Brian. Hope a good solution is found. Enjoy the holidays.