Adverti horiz upsell
Arnold for kids
Arnold for kids
kiryha, updated 2017-10-11 21:14:30 UTC 27,360 views  Rating:
(4 ratings)
Page 1 of 1

This is set of triks how to organase workflow with complex scenes using MtoA.



Multitexture material - one shader, different textures.

You can reduce amount of shaders in scene and speed up look development with one material and individual textures on each object. With this setup, shapes share same shader but has their own textures.



Method:
- create string attribute on object shapes, name it  mtoa_constant_(attributeName). 
enter attribute token  < attr:(attributeName) > in Image Name field of file node with full absolute path to texture (D:\projects\arnoldTemplates\3D\sourceimages\< attr:(attributeName) > ).
It become relative immediatley (sourceimages\< attr:(attributeName) >) but if you enter relative path from start it would not work.
- enter desirable texture names in each object attribute (c_R.tif, c_G.tif, c_B.tif for obj_A, obj_B, obj_C).

Also you can set place2dTexture.repeatUV attribute on every shape individualy with aiUserDataFloat nonde and float attribute  mtoa_constant_(attributeName). Look into example scene see how to setup this.

Object and shader IDs.



Method:
OBJECT ID:
- add shape attribute on object. Name it: mtoa_constant_(maskName). set attribute color to R, G or B. Assign aiShader.
- create AOV, name it AOV_(maskName)
- create aiUserDataColor, set colorAttrName: (maskName)
- plug aiUserDataColor to  AOV_(maskName) in shading group of object shader or in default shader slot in AOV_(maskName).

SHADER ID:
- create AOV, name it AOV_(maskName)
- create 3 aiUtility with flat corols R, G, B. Name them ID_R, ID_G, ID_B
- plug ID_R to AOV_(maskName) slot in shading group for 1 object
- plug ID_G to AOV_(maskName) slot in shading group for 2 object
- plug ID_B to AOV_(maskName) slot in shading group for 3 object and repeat for next objects
 
Managing shaders.
For each asset you can create string attribute(mMat, for example) and store material name in it.
Than you can keep assets files without shading networks which is good way when deal with nested references.
When gathering assets in final render scene you can apply materials by reading this attribute.

Preview shape textures.
When using multitexture material as described above, you can`t see textures in viewport. One way of solving this for each object:
- read texture name from desirable attribute,
- create lambert(or any other) shader with this texture as color for preview,
- assign shader to appropriate object. 

Read texture from shader and assign to shape attribute.
When object has shader with color texture assigned, you can transfer name of texture from imageFile node to desired color attribute on objects to link object and texture.



Doing this manualy with many objects will take ages, but with Arnold DNA Render KIT this tasks will became just button push.

Arnold DNA Render KIT
consist from:
- aiCreateAttr - add attributes "mtoa_constant_<name>" of different data types to an jbject shapes
- aiSetAttr - set attributes "mtoa_constant_<name>"
- aiIDmanager - create OJECT or SHADER IDs
- aiSetSubdiv - set sobdivition attributes and turn maya smooth off
- aiShaderManager - read and set custom attributes to operate with materials and asign materials to assets
- aiSsaveVersion - save next version of current scene


Global materials with local controls.
With one shader assigned to several objects easy to setup independent tweaks of different parameters for each object. Even with the same texture bunch of variations can be achieved from custom geometry shape attributes.


Example scene and sourcemiages 

Arnold rendering pipeline draft.



To perform complex project successfully the best way to do is to break whole process on logical parts and deal with small tasks solving problems one by one. Division occurs several times- bigger tasks splits again and again until we get to basic manipulations. This is structuring.

Structure of film: 
FILM > EPISODE > SHOT > FRAME
Structure of film production process: 
SEGMENT > BRANCH > PHASE PROCEDURE > ACTION

This is very generalized view on the subject but it gives overlook of whole process and let to understand CG role in it. During movie (or any other project with CG) creation there are a lot of segments exist. VFX artist usually stay away from script writing, HR, sound design, management, promotion and all other aspects of final result. So we are inside  computer graphic segment — creation of image sequences.

Set of rules how exactly split apart CG segment and how to make this parts work together effective is calledproduction pipeline. The main goals of pipeline are: perfect project organisation, automatisation of actions and making structure flexible to many changes.

CG segment General notes.
Physically CG branch is set of files on a hard drive.
To manage huge amount files of different formats in a logical and descriptive way special folder structure have to be created. Folder structure rely on: used software, requirements to folder structure for particular software, pithiness, logic and usability for data exchange. Each file should have proper name, version and be in proper folder. This will give possibility to develop scripts and automate a lot of process, such as gathering scenes for render, import cashes, apply materials etc.

Branches of CG segment.
We can approximate branges as: 1) Concept Art brunch, 2) 2D compositing brunch, 3) 3D brunch.

Phases of 3D:
- Asset creation
- Animation
- Layout
- FX
- Data transfer and baking
- Rendering

Each phase splits on procedures. For example, well known procedures of asset creation phase are: modeling,  texturing, sculpting,  rigging. This is also specific and generalized segmentation of CG production but it quite suitable for our goal- discovering rendering phase in conjunction with all other process.

Than you make unique tweaks for each object and improve scene in details (by changing shaders on object base).

3D phase in a rough way:


File names and versions
All files should be named properly strictly according to the pipeline rules.
Generally full file name always consist from fileName_version.extension 
If file name is complex than each part should goes one after one by the rule: FROM GENERAL TO SPECIFIC. For example NY_manhatten_peachtree_equitableBuilding -is file name and full name would be NY_manhatten_peachtree_equitableBuilding_001.mb
All files should has versions. Version padding should be chosen according to quantity of possible versions.

Naming objects and nodes
Naming of objects in scenes extremely important if you want to operate any amount of data efficient.
Basic and simple operation — selection of objects become a trick when you need to do this with many-many assets or nodes in many scenes. Easy selection different assets or logical parts of assets (characters, environment elements, leaves, metals, fluids etc) speed up work dramatically and good naming system can make selection much more easy and fast. Details may depend on concrete project but in overall name should be descriptive, readable, without useless information and ordered from general to specific. You can implement in name any characteristic which you may need to have access later for many objects. For example, if you render background separate from characters you will need select all background elements and all characters huge amount of time, so "_BRGD_" and "_CHAR_" codes  in names will allow to do this with command cmds.select( "*_BRGD_*") and cmds.select( "*_CHAR_*"). Except selection by names there are other ways of automatic selection of many objects such as display layers, sets, reading custom attributes etc. Combining them together allow to create very handy selection system.

Codes
There are a lot of names which may repeat from scene to scene and even from project to project and a lot of long words which may reduce readability. Thats why it has sense to define code system to avoid this issues. In all my projects imageFile nodes has name "IF_(material or object name/code)", for example.

Data transfer: references, import, cashes
By using references we get  flexible file connection system which allow to make changes in all stages of production without loosing to much work. What type of data transfer between each phase to choose (importing, referencing, cashes, alembic cashes etc) depends on many factors, i usually use referencing for big chunks of data (like reference location scene with many assets), import for smaller tasks(like importing many assets to scene with location) and animation cashes or alembic for simulation and animation. Reference could be nested when you reference file which already contain another referenced files. Better to keep reasonable balance between flexibility and complexity of reference brunching.

Assets
Prepare models so, that finalised assets has only geometry and custom shapes attributes, defined all shading parameters you need to adjust (in examples above this is mColor, mDisp, mTileUV etc). One of attributes (mMat) define material name or material type (wood, metal. glass etc) if you using just few types for all object in scenes.
Assign materials at the latest level of nesting references (in render scene) has a lot of benefits: asset files are clean, no mess with same from different imports and no scene break when using render layers and references(this is well known issue with references and render layers, and one more good habit to be safe - don't use per face shader assignment).
Shader manager is working whorse for preparing assets and assigning materials at render scene.
Dont forget to delete history, freese transforms and name all asset parts properly.
Animated asset should be rigged and if you wish to keep render scene clean, you may use only models without rigging elements and transfer animation with a help of cashes. Render geometry of asset should be in separate group without any rigging nodes and no render objects should be outside asset group. Parenting eyes geometry to joints is an example of very-very bed setup.

Materials
Usually we has a custom material for each object in scene. Sometimes different objects can share same shader but never the less, the more object we has, the more shaders we need and more headache to tweak shaders them. One way of reducing shaders quantity is organizing materials by physical types (metals, woods, glass, stones etc) so amount of shaders become limited and not connected to amount of objects. Varying of individual characteristics for each object can be achieved with shape shading technique, described above.
At the beginning of project we can develop materials in one master lighting scene (aiPhotostudio). As result you have basic material library of all types required for project (arnold material library). First you make general approach of scene appearance with materials from library. Than you make unique tweaks for each object and improve scene in details (by changing shaders on object base).

Rendering shots
In final render scene gather all data for rendering- models, animation, cameras, materials etc.
Assign materials from material library to objects (automatically with Shader manager), setup lights (lights can be also predefined in master lighting scene) and you have scene which is ready for individual look development tweaks.



Base tools for automatisation this techniques your can download as Arnold DNA Render KIT

Also you can download other presets and somple scenes from Arnold page in my blog.