Boost python Adventures: exploring alembic container for rigging purposes

Following up on my recent experience in 3dsmax and motionbuilder i wanted to share some of my latest personal project.

All 3 major application are now under Autodesk umbrella and expose their inner part to python to some extent.

Each have their strength  and shortcomings . I start to look seriously at boost python when I found out that some of motionbuilder python binding  were defective:

• It was at least possible to recombine elements the way I needed it.

Fom Skin weights container:

As I previously talk about it (https://circecharacterworks.wordpress.com/2016/10/06/chronicles-of-cedrick-escape-from-pymel-bay/) i never was satisfied with the way most people collect and store skin weights.

Using xml text file and saving each point individually felt terribly inefficient and slow.

I was more interested to save the data part as binary chunk and redirect the settings into a dedicated json dictionary

At some point i start to write my skin weights into a doubleArray attribute in order to save them using the default alembic exporter maya expose to its user.

The logical next step was to write directly this data into a binary stream.

To Skin weights shared library:

As i found out at some point the common ground between 3dsmax, maya and motionbuilder skin wise was that the data was organized around each influences:

• Every joint keeps track of the vertex index it will deform
• with an associated weight as well.

This was enough to plan for a simple data structure i will save and read from from a binary alembic file

It was an interesting project, where i was able to learn more into static/shared library and function export.

Speed wise and for portability reason i used out of the box std::vector

 
#define ABCSKIN_IO_EXPORTS

#ifdef ABCSKIN_IO_EXPORTS  
#define ABCSKIN_IO_API __declspec(dllexport)   
#else  
#define ABCSKIN_IO_API __declspec(dllimport)   
#endif  

// Alembic Includes here
using namespace std;
using namespace Alembic;

#include <string>
#include <vector>

namespace AbcWeights 
{  
	class jointPackage
	{
		public:
			ABCSKIN_IO_API jointPackage();  
			ABCSKIN_IO_API ~jointPackage(); 

		public:
			void clear();
			void ABCSKIN_IO_API setName(const char* name);

			void ABCSKIN_IO_API setAnchorName(const char* name);

			const char* getName();

			const char*  getAnchorName();

		public:
			std::vector<float> boneWeights;
			std::vector<int> boneVertexIdsArray;

		private:
			std::string boneName;

			std::string anchorName;
	};

	template class ABCSKIN_IO_API std::vector<jointPackage>;

	class skinPackage { .... }

	class AbcWeightsJob { .... }

One interesting benefit of a shared library is that i was able to compartmentalized code dependencies and simplify each project

Using maya core components ( compiled libs and source files) from its devKit  was more than enough as a starting point ( no cmake setup, dependencies tracking and compiled error to fix)

Exposing a skin manager through a compiled python library:

The next step in this project was to prepare some code to extract from a dcc application the interesting skinning parts. Here exposing a custom command in python was the most logical.

3dsmax function publishing and maya mpxCommand are interesting and relevant in a lot of cases but as a personal project i try to favor the solution which can helps me master new area or learn new skills.

In the same function loop the same procedures and validation can be done in all applications:

• Access the deformer object
• store the data into to correct bucket

in 3dsmax this will look roughly like:

 
//Get access to the skin modifier data through ISkinContextData
ISkinContextData* mModifierData =(ISkinContextData*)mModifierInterface->GetContextInterface(meshNode);

ShapeSettings shapeData;
shapeData.pointCount = mModifierData->GetNumPoints();

//A skinPackage will contain several jointPackage
AbcWeights::skinPackage skinValues;

//For each vertex get the list of weight and joint deforming it
for ( unsigned int vertexindex = 0; vertexindex < shapeData.pointCount; ++vertexindex)
{
	unsigned int influenceCount =  mModifierData->GetNumAssignedBones(vertexindex);

	for (unsigned int influenceIndex = 0; influenceIndex < influenceCount; ++influenceIndex)
	{
		float currentWeight = mModifierData->GetBoneWeight(vertexindex, influenceIndex);

		int jointIndex = mModifierData->GetAssignedBone(vertexindex, influenceIndex);

		//Store accordingly
		skinValues.jointArray[jointIndex].boneWeights.push_back(currentWeight);
		skinValues.jointArray[jointIndex].boneVertexIdsArray.push_back(vertexindex);
	}
}

The maya part was straightforward as well

 
//Get access to the skin deformer  
MFnSkinCluster skinClusterUtils;
skinClusterUtils.setObject(currentMeshMObject);

//get all the data at once for every points + every joints
skinClusterUtils.getWeights(currentMeshshapePath, 
							currentMeshFullComponentPointSet,
							weights,
							influenceCount);

for (unsigned int index = 0; index < pointCount; ++index)
{
	//Store accordingly but only the relevant index
	for ( unsigned int jointIndex = 0; jointIndex < influenceCount; ++jointIndex)
	{
		sampleIndex = influenceCount*index + jointIndex;
		if (weights[sampleIndex] < 0.00001f)
		{
			continue;
		}
		skinValues.jointArray[jointIndex].boneWeights.push_back(weights[sampleIndex]);
		skinValues.jointArray[jointIndex].boneVertexIdsArray.push_back(sampleIndex/influenceCount);
	}
}

Motionbuilder sdk sample was even easier  as all code needed was exposed from OpenRealitySDK\samples\tools\toolcluster .

There is a logical mistake in the source code though :

 
int numLinks, numVerts, vertIndex, vertWeight;

// Using the current cluster index
vertWeight = cluster->VertexGetWeight(v);	

proving more than ever one has to stay vigilant in copy/paste mode… ( notice vertWeight variable declared as an int which will truncate the actual vertex weight)

I learn a lot from motionbuilder documentation about boost and python itself

I was able to get a deeper understanding of arguments docstring and the inner mechanism of conversion between c++ a python object.

The final product:

 
import pyMayaAbcSkin

utils = pyMayaAbcSkin.mayaWeightsUtils()
utils.exportMeshWeightArray(["Head","Eyes","Corneas","Suit", 'Helmet_Seal', 'Elbow_Pads', 'Hair', 'Eyebrows', 'Eyelashes'], 'd:/mayaskinExample001.abc', True)
# <@AlembicSkinIO: Batch Processing report :>

		<Skin Weights Saving report:>
			Geometry Head
				Number of points 6772
		----------------------------------------------------------------------
		#{ Skipping intermdiate data}
		<Skin Weights Saving report:>
			Geometry Eyelashes
				Number of points 2592
		----------------------------------------------------------------------

	Export to d:/mayaskinExample001.abc was successful
----------------------------------------------------------------------
Processings took 0.37 seconds # 

Across all 3 application i was getting roughly the same results, the binary files are compact and the speed was more than correct.

Data set used was https://github.com/cedricB/skinIO/blob/master/skinIO/files/sven.skin001.zip

( from autodesk as usual)

Thats it for today, next time we will look at unbind python components in mobu,  and MObjectHandle concept from the maya API.

 

Advertisements

PathFromPolySoup – II: methods and apparatus for follicle-less hair rigs.

Continuing from the previous post i will today expand some of the core concept needed to rig hair efficiently.

Managing clumps other individual guides:

In order to achieve fast rig i always tried to tackle a problem from an original standpoint.

For me it usually ends up by a combination of custom nodes:

• It was a bit like inventing new grammar rules and words to describe complex ideas and phenomenons.

Studying actionLines:

1 – PathFromMatrices:

As replacement from deforming existing curves with cluster deformer I start writing a node which will accept directly an array of world matrix

It proved useful for bendy limbs or as cloth rigging components but the next logical step was to question to the need for actual transform nodes when the actual purpose of this graph relates to attaching a curve to a mesh.

2 – CurveFromVertexIds:

This time instead of using a wrap deformer which will duplicate a shape as base data I was skipping the intermediate steps of extracting the position from a matrix 4rth row and using a mesh data directly:

import maya.cmds

maya.cmds.setAttr('collarCurveFromVertexIds1.vertexIDList',
[553, 600, 609, 854],
type='Int32Array')

This list of point index was using an MIntArray form for compactness reasons

The last evolution of this process was to compute a list of curves from a list of vertexIdList attribute.

Journey to the third dimension:

1 – RibbonFromMatrices (aka the caramel node):

At some point I start to look at ribbons optimization:

• this time i wanted to challenge skinclusters evaluation with a fully parametric node network

it was giving me good results  for spine components and hair braid/clump deformation.

2 – SurfaceFromMatrices :

Following the same though process for  curve optimization, it was natural to build nurbsSurface from a matrix array and later on from polygon strips.

 

Our core hair components so far:

Now that we layout the  3 main elements which will help us defines fur/hair on a character we will have a look at their application.

a – Lace and parametric rails:

e

b – Collar and side burns:

e

Specialized deformer:

a – MeatStrap: building a hair focused wrap deformer

Usually at some point Programming student can study default maya  nodes implementation.

As rigger one of the really powerfull tool at our disposal is the wire deformer and its counterpart the wrap deformer.

The resulting graph action will in the end be:

• collect the uvParameters from the closest points between hairClumpSource mesh and bindSurface Ribbon
• get the offset between bindRibbon and an offset ribbon using their pointAtUvParameter function.
• Apply this offset to the mesh pointArray.

(Above: blue resulting nurbsWrap hair clump, white source hairMesh)

b – Lasagne: Hands on nurbs based freeform lattice

e

c – Saucisson : Better tangent space and collision management.

e

 

Thats it for this time, in the next post we will look at rigging the following ogre facial hairs.

( model is from autodesk youtube learning channel )

link: https://www.youtube.com/watch?v=c538zkwxgTQ

 

PathFromPolySoup: rigging non typical components with custom nodes

In today’s post i will about parts of my work  on feature film animation Mune and Ballerina.

During those projects my position was related to character rigging and TD.
It was really a rich experience being able to interact with talented peoples from other department like character Fx and simulation.

On Mune the unique nature and artistic style of the characters was raising problem across the production. To achieve the look above on Sohone ( the bulky yellow sun guardian) Look Dev department needed 20000 hair guides ( keep in mind we where in 2013 on linux with maya and the guerilla renderer).

The simulation time and rig complexity was simply above was we were able to afford.

Especially with the moon temple where 50 moon spiders, sohone and Mune will met and interact. This challenge is what inspired me and enable me to present a prototype which was deployed in production: the pathFromPolysoup node.

Hair from an artitistic point of view:

Like any art subject we tend to identify pattern and structuration on the element we study .

No matter the style on the Mohawk above we can see triangular clumps larger at the base and gradually getting closer at the tip.

Same with this cartoon female concept: broad mass  describe the the flow of follicles and imprint rhythm to the overall composition.

Maya nHair implementation:

In maya and canonical hairsystem an array of hair guides are attached to scalp object

The final dynamic hair strands are interpolated between them.

With the image above we can see that a curve shape can be attached either to a nurbs surface or a polygonal mesh and each guide will create 6 dependency nodes.

Maintenance and evaluation of dozen of thousand of guide will seriously impact scene size and performance.

Enter the gungeon:

My idea in this case was really simple and came from one observation:

Why do we need to manage so many elements?

How about merging them?

If you use Yeti you can preview your hair and think all of them are merged together. Unfortunately they are simply sharing the same parent.

My achievement was to step further a way from the problem and get an original angle from it.

Above we can see how by extracting the curve points we can build and structure the same information into an hairSlice: a simple mesh face replicating the curve Hull.

The first part of the scene optimization problem was solved:

• HairSlices could now be merged into logical unit and deformed efficiently.
• It was time to think of a way to uncompile mesh faces into haircurves.

PathFromPolySoup implementation:

My prototype was first build in python in a couple hour

A mesh where several hairSlices were merged was labelled a polySoup.

It will be the only input of the pathFromPolySOup node which output curve data ( you can visualize them with a nurbsCurve shape but the output attribute can be directly connected to your HairSystem shape).

 

Thats it for today, in the coming week i will speak more about the utility nodes and deformers that bind this system together in a production environment. I hope it was informative and spawn new ideas with other people.