Ah. That makes sense and works!
Thanks again. 🙏
jsmack
Where/when do register translator calls have to happen? Can they happen in the 456.py? Especially how to deal with Studio HDA libraries that are installed from a DB using 456 hooks.
registerTranslators(manager)
function needs to be *defined* inside the Python plugin script(s) in husdplugins/objtranslators
.jlapre
It looks like scene import LOPS will import custom HDAs, if they are based on subnetworks with geometry nodes inside them.
robp_sidefx
Without a translator for hdaSubnet, the fourth entry in the list will be dropped, since we don't know how to translate it. The fifth entry, however, is a geo node again, however, and we do know how to translate that. So what will happen is that we'll recreate any missing bits of the hierarchy (in this case just the hdaSubnet1 part) using Xform prims.
tamte
so if it had translator for hdaSubnet1 would that somehow block the creation of hdaSubnet1/geo3 ?
Or is there a choice during hdaSubnet1 translation to choose which nested objects it would translate?
robp_sidefxjlapre
It looks like scene import LOPS will import custom HDAs, if they are based on subnetworks with geometry nodes inside them.
Sort of
What will happen is that Scene Import will scan /obj (or whatever location you tell it to) and will find all the Object nodes, be it directly at the /obj level, or inside subnets (including HDAs). So, let's imagine we have:
/obj/geo1 - a geo node
/obj/subnet1 - a subnet
/obj/subnet1/geo2 - a geo node
/obj/subnet1/hdaSubnet1 - an HDA version of a subnet
/obj/subnet1/hdaSubnet1/geo3 - a geo node
Scene Import will find all five of these Object nodes and consider them for translation. Since we have translators for geo and subnet, it's a pretty straightforward story for the first three entries in the list above. The last two is where things get interesting(?). Without a translator for hdaSubnet, the fourth entry in the list will be dropped, since we don't know how to translate it. The fifth entry, however, is a geo node again, however, and we do know how to translate that. So what will happen is that we'll recreate any missing bits of the hierarchy (in this case just the hdaSubnet1 part) using Xform prims.
Just to break that down again, in Solaris you'll likely end up with a /subnet1/hdaSubnet1/geo3 prim which gets constructed via:
subnet1 - running the subnet translator
hdaSubnet1 - vanilla Xform prim
geo3 - running the geo translator
So you can definitely provide a custom translator for hdaSubnet and it will run, but hopefully this post gives a bit more insight into what's happening when you don't.
Warning Skipped object "/obj/CAScamsBlend" because its type isn't supported. Also skipped 18 other objects for the same reason. Warning Import of SHOP materials is not supported. Ignored material "/obj/CAScamsBlend/shopnet1" and 51 others.