Quick explanation¶

• ulfbert_model:

  Name that explains what file we are dealing with. Could also be snorri_base_model or king_larry_the_third_model_from_hell, just make sure people know the item that is versioned here.

• a:

  Wide iteration letter that is for large changes and is a landmark for you. You usually know (at least when you open a file) why you upversioned the letter

• 0001:

  Version number. Always has four digits.

• mh:

  Modifier initials of the person that saved this file.

Chain them all together and you have a beautifully explanatory naming convention that helps everybody understand what he is dealing with.

Published files¶

Published files are a little bit different in that they just omit the versioning suffixes. This makes sense when you think about them as the current state of your work you made available to everybody.

Here is an example for the ulfbert rig :

ulfbert_rig_body_c_0023_ah.mb
ulfbert_rig_body_c_0024_ah.mb
ulfbert_rig_body_d_0025_ah.mb
ulfbert_rig_body_e_0026_ah.mb

ulfbert.mb

Separate work and publish locations¶

This is just the simple principle that you manage what you give to production. Fellow coworkers never see your messy workspaces and only grab the content that you have published for them to use.

In many locations you will find a work folder which might contain the same folderstructure where itself is in for example :

3d/maya/scenes/assets/ <-- This is where people USE your work
        chars
        props
        cameras
        ...
        **work**

3d/maya/scenes/assets/work <-- This is where people work
        chars
        props
        cameras
        ...

Here is an example for concept artists, to show that this principle is not limited to 3d :

2d/concept_art <-- This is where people watch work
        chars/
                ulfbert/
                        ulfbert_concept_hair <-- People go here to WATCH the latest ulfbert hair concept
        props
        ...
        **work**

2d/concept_art/work <-- This is where people work
        chars
                ulfbert/
                        ulfbert_concept_hair_a_0001_mh.psd <-- People go here to CREATE the latest ulfbert hair concept
                        ulfbert_concept_hair_b_0002_mh.psd
                        ...
        props
        ...

Assets and shots pipeline¶

Photoscan pipeline¶

Caching¶

1. Load Alembic from animation or simulation (both are identical) and use the character_fur HDA to create, simulate and tweak the fur.
2. Cache the complete fur to a seperate file. This is the distilled and only output for fur. (All of the creative part of the fur process happens in a separate fur hip file, analog to the cloth or other effects files).

Rendering¶

1. Load the character_fur_render HDA and point it to the cache. (Or to the cache directory if several caches are needed for several hair systems). If not all needed caches exist, the fur rendering will fail. In render files will be NO tweaking on the fur or artistry on simulation/animation, only shaders will be tweakied there.
2. Load character_fur_shading HDA and plug it in material slot of character_fur_render HDA.

Required Digital Assets¶

1. character_fur HDA

Provides all the functionality to create/simulate/tweak and cache the fur. This is the motor.

All of this happens in a seperate fur file for each shot done by the fur artist.

2. character_fur_shading HDA

Analog to usual shading assets. An HDA that just contains one or more materials to be plugged in the material slot(s) of the character_fur_render HDA.

3. character_fur_render HDA

HDA that wraps the character_fur HDA, hides all the complexity of the fur itself and exposes all the attributes needed for rendering.

The character_fur_render HDA wraps the character_fur HDA for DRY reasons and to provide a stripped interface that hides the complexity for shading artists. If there is no cache, the fur cannot be rendered.

Textures¶

Rendering¶

3d¶

Cache¶

How To?¶

Here’s how its used in Houdini. Its simple and comfortable.

Shots¶

This variable is added by the pipeline on startup if it doesnt exist. However it is NOT given a value. The correct value for the current shot has to be set by the user. Please see below for examples.

Applications¶

Pipeline¶

Houdini¶

Simulation Preroll¶

In order for the extensive cloth sim, that we want to put on top of the helga characters, there is some pre-roll time necessary. Trust me, it’s not rocket science, here’s how we wanna do it.

There are 2 steps that come before the character animation that are needed for the sim dudes.

1. Frame: 901 - 951

   Character is in T-Pose. The cloth settles on the T-Pose character.

2. Frame: 951 - 1001

   On frame 951 there is a keyframe of the T-Pose. From here the character morphs linearly into the start pose. Here the cloth gets ready for the real action.

3. Frame: 1001

   This is the first keyframe of the character animation.

We choose frame 1001 as the first keyframe of animation because it’s a round 1000 frames offset from the usual frame 1.

Solve settings (final)¶

Set the settings in the batch process dialog to the following. Before the aligning of chunks (second step) it makes sense to check the solved chunks and disable those that dont work before aligning and merging chunks.

Folders to chunks¶

How folders in the prop_x/photoscan/photos dir. map to chunks in photoscan.

Machine list¶

The following machines have a Photoscan license:

• Pegasus (Manuel)
• Gnocchi (Timm)
• Maccheroni (Timm)
• Adonis (Johannes)
• Fusilli (Silke)
• Gemelli (Nicole)

Foreword¶

First let me say that API is probably a little misleading since the helga package is mostly a collection of custom tools written in Python, which are independent of each other (like helga.nuke.reconstruction.renderReconstructVRay). But there might be modules in the future that are ment to be exclusively building blocks for programmers.

Organization¶

Our pipeline is split up into several kinds of packages that import from a logical hierarchy. We can add packages at any depth in the hierarchy at any time.

Work and Deploy¶

There are two Helga packages located under:

• production/scripts/work:

  Here is where we work and edit our scripts. You are expected to always work here and copy your stuff over to deploy when ready. If you work and edit in deploy to save the copy step, you will sooner or later loose work, since i will often delete and recopy the whole helga package.

• production/scripts/deploy:

  Here is where the DCCs use our scripts and their compilers do the byte compilation (create .pyc files)

This is basically source control for the poor man, but since the helga package was initially ment to be exclusively my own sandbox we have to deal with that inconvenience.

Important PEPs¶

There are a lot of PEPs. Some are more important than others. You are expected to read and use them. Often times in this document, i will just refer to the appropiate place in some PEP.

• Python Coding Style: PEP 8
• Docstring Conventions: PEP 257

Variables, Classes, Modules, Packages etc.¶

For naming of objects in Python we use the Google naming convention. (PEP 8 does not recommend any naming).

module_name, package_name, ClassName, method_name, ExceptionName, function_name,
GLOBAL_CONSTANT_NAME, global_var_name, instance_var_name, function_parameter_name,
local_var_name.

You can find the full documentation here.

Tabs or spaces¶

PEP 8

Tested on¶

• CentOS7

  • Houdini: Yes
  • Nuke: No
  • Maya: Untested

Step by step guide¶

Please note that this guide is geared towards TDs or people that are a little familiar with git or Python, since there is. a little effort involved in making it run outside of how it is ment to be run. 6 little steps to take on your own risk :D

1. Temporary clone the helga git repo

   Clone the helga repo to a temporary location. Just navigate to some temp folder and execute this snippet in your git enabled shell:

   git clone https://github.com/timmwagener/helga.git helga
   

   This should create a folder named helga at your current path and clone the helga repository in it.

2. Helga folder structure

   Now in your temporary helga repo navigate to helga/general/setup/direct_access/supplementary_material/folder_structure. There you will find a zip file called helga.zip, that contains the helga folder structure. Extract this zip to where you want the helga pipeline and project to be located. PS: The helga folder structure is based on the Maya project structure which might be unfamiliar to non Maya users.

3. The real clone - work repository

   Now its time to do the real clone of the helga repo and fit it into the new folder structure. Navigate to your_root/Production/scripts/work and execute

   git clone https://github.com/timmwagener/helga.git helga
   

   there again. This is the repo you will keep up-to-date and maintain and always copy into sandbox or deploy when you want to publish changes to production.

4. Start procedure for Houdini, Maya & Nuke

   Now its time to adjust the startup module for your dccs (Supported are Maya 2014, Nuke 8.x and Houdini 13.0.xxx). Please go to Production/scripts/sandbox/helga/helga/general/setup/direct_access/yaml where you will find a file called pipeline_base_data.yaml. Open it with a text editor, for example sublime text or notepad and adjust the following values:

   1. PIPELINE_BASE_PATH: “path/to/where/Production/and/Organization/folders/are/under”
   2. PIPELINE_FLAVOUR: “deploy” <– Pick either sandbox or deploy. This is the folder name where the script environment you want to use is under.
   3. MAYA_EXE: “path/to/maya.exe”
   4. NUKE_EXE: “path/to/Nuke8.0.exe”
   5. HOUDINI_EXE: “path/to/houdinifx.exe” (or houdini.exe)

   Save and you are good.

5. Pipeline repo production copies - sandbox and deploy

   Those two fellas could also be named experimental and stable, beta or gold......you get the idea. Just go and copy the whole helga folder, in which you just did modifications, and __init__.py file from work into sandbox and deploy.

6. Finally

   Test if the application runs correctly. Navigate to deploy|sandbox/helga/helga/general/setup/direct_access and type the following in a python enabled shell:

   #Houdini:
   python -c 'import direct_access;reload(direct_access);direct_access.run("houdini")'
   #Maya:
   python -c 'import direct_access;reload(direct_access);direct_access.run("maya")'
   #Nuke:
   python -c 'import direct_access;reload(direct_access);direct_access.run("nuke")'
   

   If everything went well, your DCC should start within the helga pipeline environment (either sandbox or deploy)

Hopefully that was not too confusing ;) Please remember that you now have the pathes and setup in place, the structure if you will, but you still need a lot of content like .otls for example. In your own production you would of course populate the pipeline with your own scripts, plugins, digital assets, gizmos etc.

Good luck :D