@milan would you be so kind to drop your amazing brain dump on this topic here?
But let me see if I can give a succinct explanation:
A product type is a pipeline/production agreement of a particular type of product.
A family is a characteristic of the instance to be published.
This to some extent could be somewhat aligned with “traits” in OpenAssetIO terminology.
These may overlap here and there - and due to some implementation reasons this has also been very watery here and there.
Also note that we use the Pyblish framework which uses families to target its publishing plug-ins to define which instances to process or not to process.
So now to explain it more in-depth:
Product type
So a product type is a production definition of what a product is. For example:
- model: static non-moving clean geometry usually with strict requirements, like must have uvs, must match naming conventions, etc. (this may be multiples meshes however)
- camera: a single animated or static camera
- pointcache: animated or static hierarchy of geometries or nulls, usually without materials
- review: a preview media to use for reviewing purposes
- render: a rendered output from a particular integration, like a 3D render from Maya.
The product type does not define what file type it is or extension that it has. That is up to the representation. A model product type may have a usd, abc, obj and fbx representation - however the type in your production hints that it should be a static clean geometry (usually part of an asset).
We also have product types available in AYON like “mayaScene” or “usd”. I deliberately skipped them in the list above because they are outliers in that they hardly have any production rules. Usually these product types are a raw output to be able to export from a scene with little to no validations, just to get the data out that you need in the format that you need. Technically these may have made more sense if we initially would’ve called all of them “raw” product types - where mayaScene and usd is just one of the representations that it may have.
Family
I’ll be explaining this from the perspective of what I think it should be; not what it is now.
So, families in AYON are really only relevant to Pyblish plug-ins as far as I know. Unfortunately there’s been a long history where a product type was also the primary family for the publishing process. So that model product type in Maya for example was tightly coupled to it being a maya scene export and an alembic export - but families should be more than that and be more of tags or targetting of how the publish instance should behave.
For example, we could have one global validator that validates whether an instance has a frame range that matches the current context - that plug-in could for example solely target family framerange so that in any host integration we supply that family to the instance - we can have any “framerange” validators get picked up that way and define those validations in a way that it needs to know nothing else about the instance other than that it happens to have a frame range instead of having to be publish instance type specific.
Similarly, I would argue that we should have a farm family or alike. Then all farm integrations just need to target that family, expose the relevant attributes for anything that is allowed to run on the farm and need potentially just a submit plug-in to be host specific or know some additional specifics to define what type of e.g. deadline job it should generate or run.
Also, with all that said - it’d would mean that a plug-in running on e.g. model family should mean it does something that makes it adhere to that product type - like a validator ensuring a model is static. In the best case scenario a product type validation could be a global host-integration independent validator so that we can ensure the product type behaves as we intend it, no matter the host. But that’s extremely hard to validate in a DCC agnostic way unless we’d validate the exported file itself - after extraction.
I’d love for a family to also allow us to rely on it behaving a certain way - like ‘it has a colorspace’ or ‘it has a frame range’, but even in a way that hopefully from a coding perspective we can “type hint” what data we expect that instance to have so that there’s no more guessing on what data we expect there to be and relying on instance.data dict without any type hints.
However, it’s hardly used that way anywhere in AYON currently.
