Hi guys, I guess there is a problem in the texture exporter. The folder is correctly created. However, the name is copied from the original texture name. Therefore, if all textures have the same name, let’s say “texture.png”, all elements in the scene will have the latest texture. It would be wise to link that to the name of the object in the scene. So the texture of the mesh “Box.001” becomes “Box.001.original_name.original_extension”. Can you point out where this export/conversion is being done in the code so that I can apply locally a quick fix?
Also, custom properties gets the “:” changed to “_”. Why is it so?
Hello @eliabntt94! I contacted the Blender team for more help regarding you post. I will post back when I have more information. Thanks for reaching out to us!
Hi, thanks for your reply.
I’ve also an additional question. When exporting to USD my animation, the resulting USD is kinda huge (300MB for 300 frames). Is there a way to reduce it’s size except for sampling every n-th frame?
Hi @eliabntt94 . The code for exporting materials/textures is here:
However, please note that all of the material and texture export code is being heavily revised and reorganized at this time, so this file will probably look very different in a week or two when that code is committed.
What about saving each texture in a folder with the material name, rather than naming it after the object? So, for example, if ‘texture.png’ is referenced in material ‘foo’, it would be saved to:
./textures/foo/texture.png
Would this be an acceptable solution? If so, we could add this feature to the revision we are working on.
This is because USD naming conventions don’t allow the “:” character in a name, so it’s being replaced with an underscore. Here are the USD naming rules:
An identifier is valid if it follows the C/Python identifier convention;
that is, it must be at least one character long, must start with a letter
or underscore, and must contain only letters, underscores, and numerals.
The reason is that, by default, deforming geometry gets exported as essentially a vertex cache. If your animation is being driven by an armature, consider exporting the armature animation, which would probably be much smaller. Just be aware that this is still an experimental feature and also that you would not be able to import the armature back into Blender at this time. (We’re working on adding the armature import feature now.)
To export armatures from Blender, simply toggle on the Animation and Primitive Types / Armatures check boxes in the export options. Please see more information in the documentation.
That would be perfect actually. And a must needed feature :)
Yep that was my guess too. I was able to use directly omniverse script console to change it back to the orginal :)
Thanks, I’ll try this today
Dear @makowalski can you also take a look to this blend file?
You should be able to open it and see clearly that meshes are not overlapping during the animation.
However, when I export it from blender to usd I notice problems in the trousers (around frame 50/60) and also on the back of the subject while it is walking.
Do you have any suggestion?
strange_thing.blend (77.9 MB)
Hi @eliabntt94 . The skeleton representations in Blender and USD are a little different, so I’m not surprised if there are small differences in the mesh deformation. I noticed that the clothing animation is baked out as a vertex cache, is that right? Could you export the clothing animation as an armature as well? Maybe if the USD skeleton animates both the clothing and figure then that will help with the intersection issue.
Unfortunately, not it cannot be exported as an armature, unless you have a simple way to convert the representations without a pre=existing rigging of the mesh (I was not able to find anything able to do that).
What is strange is that in blender everything is rendered correctly. Probably the two meshes are too near one with the other.
Sidenote, please consider providing an option to suppress the output when bpy.ops.wm is called manually as it floods the terminal.
Might it be that in the code you are cleaning/limiting the weights of the vertices?
What I noticed is that Shape Keys in blender are relative while in omniverse it seems that you use the interpolation for the skinning method.
Any idea on how to solve this would be highly appreciated. Otherwise I will have to use vertex cache also for the body (that one I have), but that will double the filesize when in output unfortunately.
Hi @eliabntt94 . I’m investigating a fix currently and will have another update for you soon, once I confirm that it’s working. Thanks very much for reporting this issue. The feedback is appreciated.
@eliabntt94 Unfortunately, I don’t think there is anything I can do immediately to fix the intersection issue, as I believe the way the vertex weights are currently applied is correct. Of course, we’ll keep looking into this. I will open an internal task to continue investigating this question and will let you know if we find a solution…
In the near term, to work around this, is there any way you can generate the cloth animation for the clothes with a larger offset from the body?
Otherwise, saving a vertex cache animation might be the most reliable approach. One way to reduce the size of the file on disk is to split the shirt, trousers and body into separate USDs that you can then load as individual layers in Create. You can save a particular object to a USD by making just that object visible in the scene and enabling the Visible Only toggle in the USD export options.
(Also, I’ve noted your request for suppressing the output. Thanks for the feedback on this.)
I’ll try with the split. Unfortunately, when I scale the shirt/trousers everything gets moved around since the applied meshcache is no longer correct. Indeed, armature bone locations seem correct. I’ve only noticed that, in the exported USD, changing the skel:skinningMethod does change the shape of the body. Might be that this is the different component between omniverse and blender.
The output is noticeable when one call bpy.wm.ops.usd_export either from console or script. Calling from the UI it is suppressed. I tried to redirect the output through python coding but it does not seem to work.
Hi @makowalski, I’ve a related question. Do you know how I can add a collision to my animation (considering that I use the vertex cache)? I’m not able to make it work, it just considers the first frame.
Hi @eliabntt94. My apologies for the delayed reply. I’ve directed your question to the physics team and will let you know when I hear back. Thanks!
@eliabntt94 I’m told that collisions against deforming vertices isn’t currently supported, unfortunately.