Blender: USD Point Instancer needs unique names for Mesh and Material
I think I found a bug well... probably a Blender nitpick. Export a map with many blocks as USD Point Instancer. *maybe normal one might have this too Import with Blender, no mesh Block library or materials imported beside point cloud Toggle System Console to see import warns
Apparently Blender doesn't like name collision in general so, many exported prims (Mesh, Material) has the same name. I solved mine manually by editing the file, adding suffix _#
Posted to the Discord Mineways server, in #questions:
I tried looking at this problem today but I can't reproduce it. I exported from Mineways to USDA and clicked the "Export individual blocks" box, which uses the Point Instancer path in the code (IIRC). The USDA files produced all have unique names, like:
def Mesh "water_overlay_9_8"
and
def Material "leaf_litter"
Could you tell me more about how you got this problem? Or, better yet, send me the USDA files produced by Mineways so I can see the settings?
Posted to the Discord Mineways server, in #questions:
I tried looking at this problem today but I can't reproduce it. I exported from Mineways to USDA and clicked the "Export individual blocks" box, which uses the Point Instancer path in the code (IIRC). The USDA files produced all have unique names, like:
def Mesh "water_overlay_9_8"
and
def Material "leaf_litter"
Could you tell me more about how you got this problem? Or, better yet, send me the USDA files produced by Mineways so I can see the settings?
Here you go. I think the settings that cause it is Export all three textures to three large, mosaic images. export_test.usda.txt BlockLibrary.usda.txt MaterialLibrary.usda.txt
Aha, the problem is that exporting the 3 large textures along with instancing makes some mesh names be the same:
def Mesh "export_test_2_0"
gets repeated in BlockLibrary.usda.txt, for example. Exporting with individual textures gives unique mesh names (named after the block name and type). Note to self: I'm guessing consolidated meshes will have the same problem, a non-unique name.
The more I look at this mode (3 textures, instances), the messier it looks. Lots of data structure changes and cross-referencing. I don't really want to tackle that, to be honest, as 3-texture output for USDA seems like a bad idea (is there a reason you like it?). I think I'm basically going to "allow" it but warn the user that they'll probably have to hand-edit things, "here be dragons."
Thanks for pointing it out, though, and I'm sorry I don't have a happier answer for you.
I'll leave this bug open, in case by some chance I have a lot of time on my hands and a wish to add a number of new data structures to my house-of-kludges code. Looking at the problem did uncover another bug, having to do with unique materials output, so at least I'll fix that.
I've at least fixed outputting a material with the same name again and again, when the 3-texture option is chosen. That's not quite the right fix - there probably should be many different and differently-named materials - but this at least avoids confusing duplication.
For now I've tagged the larger problem, using 3-texture output and instancing together, by at least warning the user. Hopefully this catches all the cases where things go bad.
I'm getting this warning pop-up even when exporting "individual textures to tex" is selected. Is this intended? Makes it seem like I'm still exporting with three textures mode somehow.