Enhancement: Make Houdini Creator deduce family/families using creator identifier

[MustafaJafar]

Is there an existing issue for this?

• [X] I have searched the existing issues.

Please describe the feature you have in mind and explain what the current shortcomings are?

Deduce families from creator identifier in Houdini.

Quoting BigRoy comment:

Having this always defined by the creator and not saved into the node will also allow us to maintain the code easier since we don't need to ensure whatever data is on the node matches what the Creator has as family (or families; which has been an occurrence with bgeo + alembic in Houdini; but also with USD families in Maya which I solved exactly like that; the Creator always defines the families and is not embedded onto the container, see this PR

How would you imagine the implementation of the feature?

Quoting BigRoy comment:

This should happen on create AND on collect_instances, since that's when the Creator creates the instances for the CreateContext. Additionally this data should not be stored on the instance node in the scene (it should not be stored in parms on the node, it should not be serialized because the Creator defines the families).

One could argue it's actually transient_data but the publish system needs it in instance.data["families"] due to how pyblish works.

Are there any labels you wish to add?

• [X] I have added the relevant labels to the enhancement request.

Describe alternatives you've considered:

No response

Additional context:

No response

[cuID:OP-7105]

[MustafaJafar]

Also, we can extend this enhancement to have consistent categorized product-types (families) names which may include representation type.

Identifies/Product types suggestions:

# cameras
io.openpype.creators.houdini.camera.abc

# pointcaches 
io.openpype.creators.houdini.pointcache.abc
io.openpype.creators.houdini.pointcache.bgeo

# static meshs 
io.openpype.creators.houdini.staticmesh.fbx

# render
io.openpype.creators.houdini.render.mantra
io.openpype.creators.houdini.render.karma
io.openpype.creators.houdini.render.redshift
io.openpype.creators.houdini.render.arnold
io.openpype.creators.houdini.render.vray
io.openpype.creators.houdini.render.usd

# No categories
io.openpype.creators.houdini.imagesequence
io.openpype.creators.houdini.hda
io.openpype.creators.houdini.usd
io.openpype.creators.houdini.vdb
io.openpype.creators.houdini.review
io.openpype.creators.houdini.workfile
io.openpype.creators.houdini.arnold_ass
io.openpype.creators.houdini.rsproxy

Families could be computed as such:

identifier = "io.openpype.creators.houdini.pointcache.abc"
families = identifier.split(".")[4:]

[BigRoy]

families = identifier.split(".")[4:]

That doesn't sound right? For:

io.openpype.creators.houdini.render.usd

That'd make it:

families = ["render", "usd"]

However, it's not of family usd? It's render.usd maybe?

Anyway, I don't see why we need to do the identifier splitting - I'd rather just be explicit about returning the families instead of requiring it to be in the identifier, etc. I can imagine there even being cases where an Extra 'batch' creator gets to exist which ends up generating other instances of another type, etc.

Simpler is better.

[MustafaJafar]

@BigRoy Do we need this ? For information, we have get_publish_families implemented. e.g.

https://github.com/ynput/ayon-houdini/blob/b2ceb5efdc93aed78b105a4f706d678a2e124a28/client/ayon_houdini/plugins/create/create_usd_look.py#L72-L73

[BigRoy]

I believe it's still relevant for pointcache specifically in AYON - but I'd say... we're looking to refactor bigger than just this one. It's fine to put it on the backlog and move to ayon-houdini - but at the same time it's not something that I'd "fix" in isolation - rather focus on the overall publishing redesign of AYON x Houdini

[MustafaJafar]

Should we close it then ?

[BigRoy]

Burn it with fire until it becomes an issue again - if we don't end up solving it magically via our other goals. 🔥