Search the Community
Showing results for tags 'derivative'.
Found 2 results
-
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
-
Hey I'm having a strange issue. I modeled a fosset to shade but the S & T are just strange. I'm confused since I thought S and T were suppose to have everything to do with the UV map 0-1 space. However, here (see image) I am getting some strange results which cause my shader to appear almost at random. I dropped in a perfect asset (shirt geometry) that works perfectly in production when I textured and shaded it, but as soon as I plug in the S into the color ouput of the material shader builder it appears super strange. I'm confused at why I'm getting these results. Thanks
