Jump to content
kiryha

Transfer HDA animation

Recommended Posts

I have a Digital Asset of my character. It is animated in the animation scene. Is it possible to transfer animation to another scene with the same asset with standard Houdini tools?

Share this post


Link to post
Share on other sites

There is no standard tools per say.

But you can copy and paste the nodes/HDA from one scene to another from two open sessions they use the same copy buffer, or merge the hips from the file drop down.

If you want to invest time you can script it, or make the several different nodal methods to copy the info/hda.

 

Share this post


Link to post
Share on other sites

If there are no standard tools than I will have to create my own...

At a high level, how should I transfer animation? Export-import animation curves of HDA as well as parameter values?

Share this post


Link to post
Share on other sites

So an aside that may have found more of what you want...

There are the Python Panels: Autorigs, Pose Library, and Character Picker that ship with Houdini.

These have been updated by I believe Michael Goldfarb. Here as an example: https://www.sidefx.com/tutorials/autorigging-masterclass/ So it may be worth not listening to me, and looking into those and getting in touch with SideFX, before I take you down a more complex path, lol. Sorry these are new tools I do not use in production.

At the heart of it you would want a library where you could save your different animations too. So Walk, Run, Sit, etc... You would need to be able to read and to write from these files to the parameter pane. You may want to split up the rigs export to different components even like upper and lower, or other component pairings.

You can do this with say FBX files, chops with chan files, etc. Storing the animation with FBX may be good if your animators liek to use MotionBuilder, Maya and other programs. I would say your most studio robust and flexible would be encoding all with python. You can even go into the realm of making your own Python Panel in Houdini to help manage the files on disk and help import, including nifty images/gifs of the the different exports. I believe the python panels mentioned above can be used as examples if not used directly to get you started. 

 

 

Share this post


Link to post
Share on other sites

Hi, Ben!
Exactly, I used Autorig tool and learn how to use it with masterclass you mentioned!

Now I need to understand what options do I have to transfer animation data from animation scenes to rendering scenes to build pipeline tools for that. So, as far as I understand I have such alternatives:
1) Export-import (copy-paste) animated assets themselves. Not very reliable and flexible way, I do not consider it as a possible solution.
2) Export-import caches.
3) Export-import animation channels.

The last two solutions are fine (personally I would prefer caches cos you don't have redundant data like rigging nodes in the render scene) but choosing between them rise another question: how to work with materials. And materials workflow is another big question from the list of all pipeline questions I need to figure out. Seems like common practice is to have the same HDA (which holds everything it needs in all production steps: rigging, materials etc) which could be loaded in animation and rendering scene and transfer animation data only between this departments. In the case of geometry caches, the material assignment system needs to be developed.

PS.  I am not using any other software, pure Houdini. 

Share this post


Link to post
Share on other sites

It's good to know you're pipeline is just in Houdini.

* IMHO, you can ignore this part, just don't build yourself too much into a single software centric pipe. One software generally won't be the solution for everything, and production every-software has it's strengths. For instance Shotgun, Nuke and Houdini all go hand in hand.

So if you are doing strictly shot based work from anim to rendering, like a film or commercial pipe. Plus if you are not working on the part of the pipe to help your animators read from a library of animation cycles you can simplify it pretty quickly. Also not working on something to help FX team then it's pretty simple.

For Lighting/Rendering just go with geometry caches. This way the lighting artist/rendering person only needs to read the caches from each respective department. On your character rigs you will just need a render button, that will export your geometry sequence .bgeo.sc to a project/sequence/shot#/department/asset/version structure or something similar, you can get real fancy with the file structures. For instance, for relative common asset just replace common in the corresponding hierarchy, and mirror of authoring scenes, and machine generated content. If you want you can even include an .xml/jsn for meta data on import, or include it in the details attributes for custom tags of information, static asset, frame range viable, render option etc... This way your Lighting artist can just load all assets from the same hierarchy. By having all the geometry cache in the same known structure it becomes easier with out a program like Shotgun to manage the asset dependencies to auto load all assets on launch of the .hip file based on file locations. 

Sometimes it's good to export the animation channels out on the rig/hda, as you can use the same animation caching method that your animators will use. Save you from developing an extra system. But you are going to need a geometry cache system, that is the most common production tool across all studios. Also for FX artist, it is sometimes really needed to have the entire rig for simulations and FX work. Character TDs doing grooming, cloth, or rag dolls for instance would need them depending on the work flow. If you save your T-pose in an easy to access mode on your HDAs this becomes easier, but since DOPs can inherit object transforms easier it can be a toss up depending on your artist. 

For materials yes you can keep them in the rig. The thing to remember is they are only a string attribute on the primitive, so you can bend and twist this string to your hearts content. 

It also really depends on the complexity of your production, or are you building a pipeline for a studio to do hundreds of projects? Are you doing a simple commercial no change in materials for the whole sequence, or are you doing a fashion commercial where every shot is the same pirouetting ballerina rocking different clothing? Also are you shading an entire crowd or just one character. You do not want to have hundreds of the same material loaded in a scene in that case. You would want to have a load detector for a common material area, if this material has been loaded do not reload it. All thousand characters would use the same material, this will certainly render simpler and keep your scene file manageable. Also do you need per shot flexibility on adjusting the materials, especially for the light artist? The possibilities for mantra and comp have gotten so many amazing options than two decades ago you may not need any of those if you have a competent compositor and one person to set up the shot. 

Hope it helps, there are a lot of questions to reflect on scope, scale, desired functionality, flexibility, time and resources... So not really one best answer with out those variables.

  • Like 1

Share this post


Link to post
Share on other sites

Thanks, Ben for that information, really useful!

When I sad pure Houdini I meant major players in 3D area only: no Maya, Blender or 3DS Max, etc. Sculpting and painting tools like Z-Brush and Mari are in implementation plans at a later stage. Nuke and Shotgun are the part of the pipeline already, however, I tend to render final images from 3D and do in comp a very few things only. Also, I am thinking to implement Shotgun as an optional choice cos it's quite expensive and not everybody has an account (and as far as I know there are no free alternatives to Shotgun with Python API) but its quite tricky to manage project data without such system. When I start playing with Houdini I realize that it could handle all 3D operations quite well (opposite to a common opinion that Houdini used mainly for FX), this inspires me to switch from Maya completely and build a Houdini based pipeline. I am doing a personal project in Houdini (almost without a character animation but I still need this functionality to exchange data between different 3D stages) and pipeline developing is a part of this process. As a result, I wish to get the solid pipeline basement which could be scaled for next bigger and more complex projects with a bunch of artists involved. I know this is not the best idea trying to create an abstract pipeline for all possible cases, so I would say full CG animation film is the project I am aiming for (even if it`s very small and could be done with one artist). 

Materials... There are tons of possible options but I am thinking if it makes sense to use in Houdini the same solution I designed for Maya: you create a library of common materials (wood, grass, plastic, metal etc) and apply materials in rendering scenes and each asset has shading attributes (material name, textures names for different channels, individual tweaking parameters, like reflection straight). In such case, every asset in production consists of mashes combined by materials. So you have a very limited amount of shaders in the final scenes ready to be rendered but with an ability to tweak each asset shading individually in each shot if you need. I still don't like this idea to have hda in render scenes with all redundant information and individual shaders (when a lot of them could be shared across different assets) but my mind is opened.

So I will examine the geometry caches option (bgeo.sc) for now. My current question is: if I will load animated asset with File node into a rendering scene, how can I distinguish different parts of the geometry and apply different materials?

Share this post


Link to post
Share on other sites

So yet again not a an extremely simple answer, so this will spiral out as you read through it more.

To keep it simple with the materials. You can just use groups/attributes to define the different parts of your character and then with the material sop you can define your materials per a region. Plus what I think you are after is the material overrides. You can define the overrides to the shader on the mesh. So you could define the diffuse map per each primitive. This can get a bit expensive with the file size on disk, especially for an animated sequence, but you could theoretically have one uber shader for the whole production, and everything is defined via the mesh. You can do this at the object level, too depending on how you split up your object. Finding the happy medium is key. For a one person project, and for standardized shading models this might work out really well.

An alternative that is similar and will not over use the material overrides, but still have all presets defined on your uber-shader, is by having packets of shaders within a material subnet HDA. So you could save all the presets shader for your character, for instance, all the clothing types in one material HDA subnet, that contains all possibilities. i.e. Ralph_Clothing.hda with the material subnet hda containing clothes/dirty clothes/clean clothes/pants

A more advanced setup would be on import of your object with a file wrapper on your HDA, to parse the geometry or an external saved file for subsequent required materials. You can do it similar to the above, or even by creating the uber shaders dynamically in python and applying the presets directly in the scene. By applying the presets in the scene, say if you have a lookdev department authoring the materials, you may have issues maintaining their updates. However, with even more pipeline framework you can dynamically refresh those once they are updated. Another alternative, in the simple case is that the lookdev department authors their materials as HDAs too. Then you get the benefit of version control built in. But this requires you to build a lot more complex naming convention system, for storing HDAs, etc.

There are also material stylesheets you can use. Jeff Wagner just did a few video's on those, but they may be more up your alley, a bit too much to explain in a forum post however.

 

  • Like 1

Share this post


Link to post
Share on other sites

How to store materials if I wish to have a material library (ies) and use it (them) in render scenes?

First I was thinking about storing materials in HDA but I have some concerns. According to my method of structuring materials, there could be one library for all environments and props and each character will require its own library (because of a complexity and uniqueness of character assets its easier to manage unique materials on each character). If there are many characters in a project the HDA list in Houdini will become massive, and also materials would be mixed with other asset types (characters, props, etc). Imagine Digital Assets menu will contain the same amount of assets as "All"...

Maybe there is a way to structure HDA other than by using suffixes in HDA names (folders)? Or it's ok to have a huge list cos nobody will ever browse this list in the usual way and all assets creation and update will be scripted?

Share this post


Link to post
Share on other sites

These are certainly some good reservations about storing the materials as HDAs. No matter what you will have a massive collection of files to stores these materials. These materials could be substance materials, or as jason/python file as other examples to apply the same logic thoughts.

As far as the shit loads of HDAs, you can store these appropriately in your HOUDINI_PATH or HOUDINI_OTLSCAN_PATH. This way you only load the HDAs that you need. These would be the separate load directorys you append on load. You can also import via python files from disk not already in those directories, which may be the best method. Houdini does not really care about how many thousands of HDAs you load, assuming you didn't build really bad HDAs that cook the world on load. Generally speaking you don't actually need that many HDAs for even a feature film. A couple hundred might be enough for all FXs and studio functions. A few dozen really matter in the grand scheme. As far as materials the whole concept is to have as common as pool as possible. You don't want a dozen ways to do car paint.

You can also manage hiding the HDAs via OPCustomize file. So you could load all the HDAs and ophide them all by default. Look through that file and you'll see a whole pile of tricks.

On creation of these HDAs, as you do not want to do them by hand, you can sort them by the tab-submenu paths, and update the OPcustomize, or any other corresponding HDA options, via python. This way they are organized better than by hand.

Honestly, in the case of materials required for objects you do not want the Lighter to ever have to look up the correct materials for the objects. So seeing them all like in "All" shouldn't be a real concern. Only OCD like me and you notice ;) or do anything about it. I've worked for many studios where people just tab and go. So there will be a level of automation you will need to develop for your project to load them either way. Cycle back to the shotgun conversation that can help manage that. 

  • Like 1

Share this post


Link to post
Share on other sites
9 minutes ago, LaidlawFX said:

You can also import via python files from disk not already in those directories, which may be the best method

You mean store material libraries as hip files and merge to a render scene? This is the way I am thinking to deal with materials now.
Or you mean store material libraries as HDA and install them (I have no idea how HDA importing works)?

12 minutes ago, LaidlawFX said:

Honestly, in the case of materials required for objects you do not want the Lighter to ever have to look up the correct materials for the objects

Definitely, materials would be assigned automatically in render scene via groups and @material attribute (which should be set during modeling or lookdev stage) after cache file is loaded:

matAssign_01.thumb.PNG.4b54ab8abd77224378b36e92b5dbfcf7.PNG

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

×