HDA Derivatives - Workflow Question

[9krausec]

Good morning all (or at least morning for me). Longer post about pipeline and workflow. Thank you in advance for taking the time to read through it.

HDA workflow question for a pipeline that I'm currently developing for a product-centric rendering operation.

At my place of work, we have many different SKUs (products. ~600 in total) that need to be accounted for. I'm thinking it would be really tidy to have each SKU be represented by an HDA. This would allow for all SKUs to be easily shared on network between users and allow for data per each SKU to be recorded into the HDA.

What I'd like to do is have a master, template HDA, that SKU HDA derivatives can be created from. I'm assuming there is a way, via HOM, to author a new HDA by copying a pre-existing template to perform this task. If this is not the case or is not the best way of working, please let me know what you'd recommend.

The biggest concern I have with working in the way above, is global versioning of all pre-existing, derivative HDA SKU assets to match the parameters and functionality of the template. Let's say, I initially have the template HDA setup to only manage the geometry CAD data of the SKU, but down the road I want to build in a system to store lighting profiles or product configuration profiles or whatever other feature additions I want to develop into the template HDA down the road. These feature additions to the template HDA will not reference down to the per SKU HDAs as at this point, the pre-existing SKU HDAs would be their own, independent HDA.

To help mitigate challenges in versioning, I'm considering nesting internal HDA's into the Template (and therefor the generated SKU HDAs), that will act as containers for certain functionalities. These containers would be blank at first, but would be placeholders for features I'd plan on developing into the template HDA. This way, when I want to develop certain features, I'd develop on the internal HDAs that are nested and referenced in all the SKU HDAs. This may work for general, global HDA features, but I'd worry that I may run into roadblocks if these nested HDA's need to be configured to any specific product. If that sounds like the appropriate workflow, please let me know. If not, please let me know what you'd recommend.

The last piece of the puzzle that I haven't figured out yet is how to actually version all the pre-existing SKU HDA's at the top level (derived from the template at creation) such as embedded python modules, additional support files or additional top level parameters. The only way I'm thinking this would be possible would be to perform a target batch HOM operation to modify all pre-existing SKU HDAs along with the template HDA. This however seems sloppy and potentially error prone. If you have suggestions or recommendations on handing this type of versioning, I'd be interested in your input.

Thank you for reading this post! I'm in the process from switching our entire operation from Maya to Houdini. Exciting times, but there are a few unknowns that I'm trying to workout before I get too deep into development and corner myself.

Best,

Clayton

 

 

 

[kiryha]

Hi, Clayton!

Sorry, I did not understand very well what workflow you are suggesting to build in Houdini, but data management is an interesting topic for me, so I am trying to participate as I can
What is SKU? What is your current process in Maya for each of the products? What do you deliver at the end for each of the products? 

In general, I think there is nothing wrong with having 600 assets/HDAs, but it might require some sorting. As for the HDA versioning one thing, I would like to notice, is that if you version asset with namespaces, it stores all versions in one file, so if the HDA is not very small the file could become too heavy. 

[9krausec]

My apologies as I may not of explained the clearest.

A SKU (stock keeping unit) is how different products are typically referred to. One SKU represents a specific product. If a company that makes coffee machines offers 5 different models of coffee machines, they have 5 SKUs. Where I work, we have ~600 SKUs, so lots of different product offerings. Most comparable thing I can think of is a car company. Ford may offer 30 different vehicles (cars, pickup trucks, vans, etc..). All are "vehicles" and each model vehicle has it's own SKU.

I'd like to make a template HDA, that is setup to house the geometry of a SKU/product. Setup the template HDA with all of the basic functions and parameters that we may need in our production. Then, when authoring a new SKU, the template would be copied, renamed and the geometry CAD data of the product would be infused into the copied template HDA.

Back to the vehicle example, create a template HDA with parameters, functions for the options you'd want to manipulate/render the vehicle with. For example, setup the HDA to have two modifiable object subnets in it, titled "doors" and "body". Have a HDA function initiated by a button parm that would toggle the visibility of the doors. Then, when a new "SKU" HDA needs to be generated (let's say a car), via HOM, the template is copied, renamed to match the name of the SKU/Product, the product geometry, is then parsed into the obj subnets. The doors go into the "doors" subnet, the "body" goes into the body subnet.

Now do this for a few more vehicles, a truck and a van. You now have 3 independent HDA's derived from the template vehicle HDA, representing those vehicles (car, truck, van) with the parm button that would toggle the visibility of the doors on each HDA. NOW, let's say down the road, you want to add to the template HDA to have another function of the HDA that doesn't hide the doors, but toggles movement by 1 meter along the Y axis. So doors would move up when the parm button is clicked, doors would move down when the parm button is clicked again. The template HDA would be modified to have this additional functionality for all vehicles derived from the template HDA onward, BUT the pre-existing vehicles (car, truck, van), would not reflect the changes of this template HDA as they are independent copies of the template HDA.

Think object oriented programming, but with HDAs. I'm looking to have ~600 HDAs to represent ~600 different products, but all derived/copied from one master template HDA. Contrast to have a single tool HDA that may be referenced 1000 times through different scenes. Make a change to the single tool HDA, and those changes are then reflected in the 1000 different references of that single tool.

To add, the only reason I'm going with "independent copies" route derived from the template HDA is because I want separate HDA's for each product and copying to create a completely new HDA is the only way I'd know how to go about it.

Cheers! Let me know if that helped explain a little better.

[9krausec]

A smart pal of mine suggested that instead of making many HDAs, to build a singular Loader HDA that would be able to populate the product/SKU on demand by reading in instructions (like JSON). This seems like it would be far more manageable then having a billion HDA's to represent each product. I was blind, but now I see.

Thank you for the replies!

[kiryha]

Understood about SKU! Actually, I work in the automotive industry and do exactly what you describe as an example . We call it configurable products. We treat each vehicle as one asset no matter how many configurations it might have. That makes a total number of assets more manageable. And at the high level, we do like your describe, populate each SKU on demand.

Edited October 23, 2019 by kiryha