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.

The registerTranslators(manager)function needs to be *defined* inside the Python plugin script(s) in husdplugins/objtranslators.

The function is *called* during the cook of Scene Import.

If you're hoping for some interplay with 456, my immediate suggestion would be to try and extract as much common code as possible for both 456 and the plugin to import&use.

There was some confusion as to why some of our custom HDAs would import into LOPS, even though they threw the "Skipped object ... because its type isn't supported" warning.

Some of our custom HDAs originated as a subnetwork with geometry nodes inside them.

It looks like scene import LOPS will import custom HDAs, if they are based on subnetworks with geometry nodes inside them.
They will throw the warnings, but the geometry nodes are still imported.
Does that sound correct?
Please find a simplified example as an attachment. It's an HDA created from a subnet with a torus inside it.

My understanding is that we should still implement the barebones scene import LOPS plugins, to make the warnings go away.
I was just trying to understand why my customTorus HDA (based on a Geometry node) needed the plugins in order for the geometry to show up in LOPS, while some of our HDAs appeared to be working regardless.

Thanks

jlapre
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.

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.

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?

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?

At present, no and no. The geo3 prim is identified independent of the hierarchy it sits in, and will always be created. That said, a custom hdaSubnet translator *should* be able to mark the geo3 prim as inactive/invisible if desired. I just need to double-check the order of operations before saying "for sure". I'll so some experimenting tomorrow.

robp_sidefx

jlapre
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.

This is helpful to know.
Thanks

While I'm working on making a Houdini file Solaris-friendly, I'm getting a lot of warnings in the Scene Import LOPs.



So much so that they are getting truncated.
Is there a way to get the complete list of warnings?
It would help me debug my hip file.

Thanks

Hi Jeroen,

That's an interesting request. At present we always shorten the message into what you've seen, there is no way to get the full list. I'll need to think a bit about what the best mechanism would be for exposing the more complete data. I've created an RFE for this.

- Rob

Thanks, Rob. Maybe a debug mode. e.g. a toggle to show all the warnings. When disabled it reverts to default behavior: only mentions the first few.

One more question (for now).
Currently, I have to quit out of Houdini and reload the scene in order to see my plugin fixes/updates.
Is there a way to force Houdini to re-scan the husdplugins directories for updates and then re-cook the scene import LOPs?
Thanks

Hi Jeroen,

That is very unexpected. The design *should* be to rescan on every cook. If you bypass and reenable the Scene Import node (or change any random parameter on the Scene Import node), you aren't picking up new/changed files?

- Rob