Closed oumad closed 2 years ago
Thanks for reporting, we're having a look.
Thanks for the repro. From what I understand, the problem here is that MayaUSD isn't exporting the normals when you exported the mesh to USD. Not having normals is what causes these kind of artefacts.
You could try to export to USD through arnold, with the menu "Arnold->Scene Export -> Export to USD" and this will always save out the normals. If I try with your test scene and export the mesh through this menu, then I can load it back (either from mayausd or through a standin), and I can get the proper shading
Thank you @kikou and @sebastienblor
I just tested, with arnold export, the problem isn't there anymore indeed. Only issue is, we don't use arnold usd export since we get issues and limitations with it, for example there doesn't seem to be a way to merge transforms and shapes, and we always get arnold options in usd files even if we uncheck "options" in Arnold-usd export window. Which is undesirable for our geometry usd files.
I suppose I should move this issue to maya-usd repo ?
After further digging and testing exports from different tools, this is what I found :
There is actually a way to get maya to export the normals, it's by giving a boolean custom attribute USD_EmitNormals
to the shape nodes and set them to true for the ones we desire to have their normals emitted (exported). Read more about that in maya-usd repo
Now interestingly, after doing that, I still get artifacts with arnold.
After further testing, I found that this is because Arnold uses primvars for the normals like this : vector3f[] primvars:normals
while maya exports them as just a usd normal attribute like this normal3f[] normals
. By just changing the attribute name in the usd file from normal3f[] normals
to vector3f[] primvars:normals
I was able to get a proper render with Arnold.
Is it possible to get Arnold to take normal3f[] normals
in consideration for normals ? Since that seems the way other tools export normals, it is why I had the same issue after exporting from other tools like houdini or even omniverse.
We have reported this to the mayaUSD team yesterday and they created an internal ticket for that. But you can feel free to create a ticket on the mayausd github. About the limitations in arnold-usd export, thanks for reporting the issue with the options being exported, I could reproduce it and that's a bug (to be fixed on the MtoA side). For the merge transforms and shapes option, you can have this in the render settings, tab "System", attribute "Export Dag Name". You can set it to "Transform" and it will give you what you expect.
for the options, it's actually on the arnold-usd side. But it's currently by design, to be able to save sequences in a single usd file. I created #963 to investigate if we can find a better solution
Hello @sebastienblor Thank you for making the tickets. I don't know if you saw my latest message, but appearently we can export the normals from maya-usd. It's just arnold reads them from a different attribute name.
Hi everyone ! I have exactly the same problem with Arnold. I've checked the Maya USD export and it export well the normals. And the model render well in other render engine. Too bad that Arnold doesn't understand usual USD normals data. I hope it will be fixed soon.
大家好 ! 我和阿诺德有完全相同的问题。 我检查了 Maya USD 导出,它导出的法线很好。 并且该模型在其他渲染引擎中渲染良好。 太糟糕了,阿诺德不了解通常的美元法线数据。我希望它会很快得到修复。
you need setup "smothing" check attribute in the "Render Geometry Setting"
Sorry @oumad I had missed your last message. Thanks for digging into this, we'll look into a fix asap !
This issue should be fixed now with #986 , thanks for reporting @oumad and @Tylius ! I'll close this ticket, we can reopen it later on, or create a new one if something isn't working as expected
I was wondering if a new bug fix release is planned ? This issue has put our pipeline migration to USD on hold since we primarly use Arnold for rendering. And I failed to build arnold-usd after so many tries during so many weekends (tried different python versions, USD versions, VS versions, cmake ui, cmake cmd line, custom.py....).
Hi @oumad it would be great if you could write us at support@arnoldrenderer.com so that we can have your contact and help you with all this, if you're ok. Cheers !
Describe the bug Reflections look broken on tessellated surfaces that are read from a usd file The difference can be seen in the screenshot bellow, the same object rendered in usd (staged with maya-usd or simply as a standin) vs as a maya native object.
To Reproduce
debug_arnold_usd.ma
.Expected behavior The object in usd should render the same way as with native maya or alembic objects.
Screenshots![USDvsNative](https://user-images.githubusercontent.com/17836943/145477665-dc0ab811-6e8a-4f9f-876a-19285bbf4f34.jpg)
Used Software Versions
Additional context The assets we work on come primarly from tesselated surface nurbs in other apps like Vred, so this issue prevents us from using usd with arnold in production. Same usd file can be re-imported back to maya as a native object and it will render fine. Same object can be exported from another DCC (ex from houdinj) and the issue happens again with arnold render.