Diference on mesh normals karma CPU vs XPU
2333 19 2- Mirko Jankovic
- Member
- 98 posts
- Joined: Aug. 2015
- Online
- sniegockiszymon
- Member
- 67 posts
- Joined: June 2022
- Offline
- jsmack
- Member
- 7796 posts
- Joined: Sept. 2011
- Online
- Mirko Jankovic
- Member
- 98 posts
- Joined: Aug. 2015
- Online
- brians
- Staff
- 473 posts
- Joined: May 2019
- Offline
- Mirko Jankovic
- Member
- 98 posts
- Joined: Aug. 2015
- Online
- Mirko Jankovic
- Member
- 98 posts
- Joined: Aug. 2015
- Online
- Mirko Jankovic
- Member
- 98 posts
- Joined: Aug. 2015
- Online
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
Edited by Mirko Jankovic - Nov. 18, 2023 05:00:49
- Mirko Jankovic
- Member
- 98 posts
- Joined: Aug. 2015
- Online
- jsmack
- Member
- 7796 posts
- Joined: Sept. 2011
- Online
- Mirko Jankovic
- Member
- 98 posts
- Joined: Aug. 2015
- Online
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]
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]
- brians
- Staff
- 473 posts
- Joined: May 2019
- Offline
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
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
- Mirko Jankovic
- Member
- 98 posts
- Joined: Aug. 2015
- Online
- brians
- Staff
- 473 posts
- Joined: May 2019
- Offline
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.
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.
- jsmack
- Member
- 7796 posts
- Joined: Sept. 2011
- Online
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?
- jparker
- Member
- 289 posts
- Joined:
- Online
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]
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]
- jsmack
- Member
- 7796 posts
- Joined: Sept. 2011
- Online
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.
- brians
- Staff
- 473 posts
- Joined: May 2019
- Offline
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
- jparker
- Member
- 289 posts
- Joined:
- Online
jsmackjparker
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.
- jparker
- Member
- 289 posts
- Joined:
- Online
briansGreat to know, thanks Brian. Hope a good solution is found. Enjoy the holidays.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
-
- Quick Links