Jump to content
timmwagener

[Digital Assets, Pipeline] HDA workflow and local/global edits

Recommended Posts

Hi guys,

 

i might be asking a complete noob question here (i'm a beginner with Houdini...) so i'm sry if this is totally rtfm.

I'm the pipeline TD of a project (this one :)) and we are running a Houdini/Maya pipeline.

 

Our pipeline is asset based which means that artists are doing chunks of work with well defined in/output (a shading hda for example, or a maya rig) and then publish

this work either into an HDA or just copying a maya file to where all references are pointing to. (Publishing in fancy TD speech)

 

These assets are then used by other artists (for example an animator might reference a rig to do his animation, or a lighting artists brings in the shading HDA from the

Shading OTL and apply it to a prop in the shot).

 

So it's important that the artists coming later on are able to change stuff specific to a shot on the base asset.

They need to make local edits, while still remaining the *live connection* to the global changes that are made on the base assets,

which are ment to ripple through the whole production.

 

How is that happening in Maya:

Maya stores local changes to references as MEL script automatically. The *live connection* to the reference always remains, and local changes are

layered on top. This way you always have the latest & greatest global version + your local edits. (As long as you dont break on what the scripts rely on....names)

 

What is the way to achieve that in Houdini?

As far as i understand, when you want to make local edits to an asset, you say "Allow editing of contents". What that does is, it breaks the connection to

your global asset and uses a scene embedded definition instead, where you are doing your local edits. You can then either choose to publish your local

changes globally into the otl again or match the global definition back to your local asset (loosing your local changes).

 

Once again, i might be totally newb here and overcomplicating things, but i'm wondering about the Houdini way to enable people to do local edits on assets while staying live to global changes?

(Since we always relied upon exactly that with the assets/references in Maya).

 

 

PS: Maybe that's all a bit theoretical so let me try to illustrate this with a totaly figured example:

 

Lets say we have a very highpoly prop to populate a shot. It is most of the time entirely in the frame but we have one artists that is rendering a close up shot where only 10% of the prop are visible.

In order to save translation time he deletes the 90% of polies that are invisible. (We now has a blast node between the UVGenerate and the OUT node).

To be able to do that he clicked "Allow editing of contents", embedding the HDA into the scene.

Later on the guy in charge of the base asset changes something on the UVs. He puts a UVPreGenerateFix node in front of the UVGenerate node in the HDA and publishes it.

Everybody gets the new assets now, just not the guy who clicked "Allow editing of contents" and modified the HDA.

In Maya the global and local changes would have been preserved since after referencing, the MEL scripts would have serached for a node called "UVGenerate" and a node called "OUT" and

connected the local blast node inbetween.

Edited by timmwagener

Share this post


Link to post
Share on other sites

I think your understanding is correct.  Let's see if anyone else answers. I am curious about this, too. I run into this problem a lot in my studio, as well. Usually, we have to update the main asset to add the extra functionality.  Artists unlocking production assets is generally not a good idea.  In your case, you could put a switch to enable/disable the blast node chain and promote that as a more general tool for the asset.

Share this post


Link to post
Share on other sites

Hi,

if I understand correctly in case of maya you would have an untouched reference which would evaluate for 100% of mesh and then unnecessary mesh would get deleted.

So your options are:

   You could do the same in houdini without editing the asset but rather building on top of it.

   Include option of culling unnecessary geo with second input

   

for extra functionality if its not breaking the asst probably everyone would benefit from it so it can be committed back to global storage with default state set to be like the old version of asset. 

if its a functionality that changes the asset itself it could be set as a new version and wouldn't break the old scenes but would be used in new ones (http://www.sidefx.com/docs/houdini13.0/assets/namespaces)

Share this post


Link to post
Share on other sites
You could do the same in houdini without editing the asset but rather building on top of it.

 

Artists unlocking production assets is generally not a good idea.

 

Ok, so i think the takeaway here is, that the general workflow is to better dont unlock production assets and try to do your local changes afterwards in the graph.

In cases where this might not be possible, and you need to make changes within the asset (probably like crazy one shot AOV exports in shading assets....), you can only do those changes globally to ensure the proper deployment.

Edited by timmwagener

Share this post


Link to post
Share on other sites

well, probably yes - build on top and try to make your assets as versatile as reasonably possible :) 

Share this post


Link to post
Share on other sites

Or you could pursue a cleaner node structure and create smaller digital assets that make up the bigger digital asset.

So, for example, the part that makes the UVs is a digital asset and when somebody makes an improvement to that, everybody gets that update. As for the guy who regularly needs to delete some points: He could make the blast a procedural part of the bigger digital asset and make it turned off by default (circumvent it with a switch for more complex stuff). A little bit more work, but if you don't have too many people, it should be possible to organize such things in folders and by keeping a common log (google documents). - Well, that's the workflow I would use.

- But I see the problem when different people work on the same thing at the same time.

Edited by DASD

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×