Maya Mesh color-per-vertex?

[JP]

Hi all,

Are there any plans to support mesh vertex color I/O in the Maya
plugin?

We're evaluating the fStretch plugin for use in rigging and lighting;
however, the data used
by lighting for driving displacement maps is stored as color-per-
vertex information. Our goal is to
get a clean import into lighting from hdf data exported from anim, but
in this case it seems necessary
to supplement the hdf data with an image sequence or some other data
which we would need to then
re-inject into the mesh. The 'cleanest' solution in our case would be
for the plugin to read and write
this data as part of the archive.

I've written similar data to a custom attribute in the case of
material assignments, but the fact that this color-per-vertex
data is not static makes it a bit more difficult.

Just wondering if this is on the map or if I'm on my own on it!

Thanks,
JP

[Steve LaVietes]

AbcGeom supports animated per-vertex color data via the
ArbitraryGeomParam mechanism.

We'll need to check to see if and how the current maya reader and
writer plug-ins interpret this information.

-stevel

> --
> You received this message because you are subscribed to the Google
> Groups "alembic-discussion" group.
> To post to this group, send email to alembic-d...@googlegroups.com
> To unsubscribe from this group, send email to
> alembic-discuss...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/alembic-discussion?hl=en
>
> For RSS or Atom feeds related to Alembic, see:
>
> http://groups.google.com/group/alembic-dev/feeds
>
> http://groups.google.com/group/alembic-discussion/feeds
>

[Francois Chardavoine]

That's what we have been doing here: in maya we simply have a node that takes the per-vertex color information from the mesh, and (continuously) drives a custom float-array dynamic attribute on the mesh shape (in maya) with the RGBA values. This dynamic attribute is then one of the ones that gets written out into the Alembic file as an arbitrary geomParam, which is then used on the lighting side.

Scoped (per-vertex/face/shape/etc) arbitrary data is really what the geomParams where made for. If after wider adoption of Alembic it turns out certain things (like color) really should be understood natively (the way we treat UVs or normals), then those are definitely things that can be added in after an initial 1.0 release.

Francois.

[John Patrick]

Great, make sense.  Thanks for the help!

-JP

To post to this group, send email to alembic-discussion@googlegroups.com

To unsubscribe from this group, send email to

alembic-discussion+unsub...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/alembic-discussion?hl=en

For RSS or Atom feeds related to Alembic, see:

http://groups.google.com/group/alembic-dev/feeds

http://groups.google.com/group/alembic-discussion/feeds

--
You received this message because you are subscribed to the Google
Groups "alembic-discussion" group.

To post to this group, send email to alembic-discussion@googlegroups.com

To unsubscribe from this group, send email to

alembic-discussion+unsub...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/alembic-discussion?hl=en

For RSS or Atom feeds related to Alembic, see:

http://groups.google.com/group/alembic-dev/feeds

http://groups.google.com/group/alembic-discussion/feeds

--
John Patrick
404-242-2675
jspa...@gmail.com
http://www.canyourigit.com

[JP]

Mistakenly replied to Francois, instead of the thread. Here was my
reply:


Okay...back to this subject :)

We want to modify the maya importer/exporter to be able to read and
write color-per-vertex data inside of Maya (for reasons I'll explain
below). I see how something like arbGeomParams could be a good place
to do this, but I'm not sure how to distinguish custom data that I
want to actually write back to the mesh itself, as opposed to data
that an importer creates/drives an attribute with. In a nutshell, I
want to add something like

'CPV' (Compound Property)
'cpvSet1' (OC4hArrayProperty)
'cpvSet2' ...

Is the idea here that I add another compound property as a child of
the arbGeomParams property? And is there any sort of naming/metadata
convention for flagging arbitrary properties as being application or
studio specific? My concern is creating data that would trip up
another application's importer.

As an aside, the reason for this is that we have shading nodes that
use the color per vertex on the mesh that can't currently use
something like a float array - they must read this data from the
mesh. The cleanest solution seems to be to just read and write the
data directly, as opposed to shuffling it around through other
plugins.

Thanks!
JP

On Jul 7, 9:35 am, Francois Chardavoine <chard...@imageworks.com>
wrote:
> That's what we have been doing here: in maya we simply have a node that takes theper-vertexcolorinformation from the mesh, and (continuously) drives a custom float-array dynamic attribute on the mesh shape (in maya) with the RGBA values. This dynamic attribute is then one of the ones that gets written out into the Alembic file as an arbitrary geomParam, which is then used on the lighting side.
>
> Scoped (per-vertex/face/shape/etc) arbitrary data is really what the geomParams where made for. If after wider adoption of Alembic it turns out certain things (likecolor) really should be understood natively (the way we treat UVs or normals), then those are definitely things that can be added in after an initial 1.0 release.

>
> Francois.
>
> Steve LaVietes wrote, On 07/06/2011 05:46 PM:
>
>
>
>
>
>
>

> > AbcGeom supports animatedper-vertexcolordata via the

> > ArbitraryGeomParam mechanism.
>
> > We'll need to check to see if and how the current maya reader and
> > writer plug-ins interpret this information.
>
> > -stevel
>

> > On Wed, Jul 6, 2011 at 5:22 PM, JP<jspatr...@gmail.com>  wrote:
> >> Hi all,
>

> >> Are there any plans to support meshvertexcolorI/O in the Maya

> >> plugin?
>
> >> We're evaluating the fStretch plugin for use in rigging and lighting;
> >> however, the data used
> >> by lighting for driving displacement maps is stored ascolor-per-

> >>vertexinformation.  Our goal is to

[Joe Ardent]

Hi JP, we actually have a solution in mind for the workflow you're
describing:

http://code.google.com/p/alembic/issues/detail?id=197

The idea is that each Schema in AbcGeom will have a method to return a
CompoundProperty called ".userData", and that's the sanctioned place for
"studio-dependent data"/random data. Inside there, you can put any kind
of Property you want (Compound or Simple), and the stock clients will
ignore it.

[Steve LaVietes]

It sounds like the data you want to write fits the form of a
GeomParam. If you make it within arbGeomParams, any tool would know
that it's a color-per-vertex -- just not what you specifically want to
do with it in maya.

The customization you'd do on the maya plugin side is to recognize
your name/type convention and act further upon it. You could also
place it in the forthcoming getUserProperties as a GeomParam or any
custom form you'd like.

[JP]

Apologies again if any of this is remedial, but there are a couple
things I'm struggling to understand, so here we go!

> If you make it within arbGeomParams, any tool would know
> that it's a color-per-vertex -- just not what you specifically want to
> do with it in maya.

I'm assuming that this is identified as being color-per-vertex, as
opposed to just some arbitrary list of colors, via the use of a
GeomParam instead of an TypedProperty? Or is there something else
that identifies that a parameter/property is related to verts, faces,
edges, etc?

As for GeomParams, I don't quite understand the some of the arguments
(especially scope) to GeomParam constructor. Is this intended to
classify the components/primitive the parameter is parameterizing? I
read through the GeometryScope header a couple times, but I don't
really understand the impact of specifying one scope or another when
I'm constructing a parameter.

In other words, what is the implication of setting up a color property
under arbGeomParams like this:

AbcGeom::OC4fGeomParam(theArbGeomCompoundProp,
"colorsetname",
false(or True?),
kFacevaryingScope (not sure about this either?),
mesh.numFaceVertices(),
timeIndex)

vs:

Abc::OC4fArrayProperty(theArbGeomCompoundProp, "colorsetname")


Along these lines, what is the relationship (if any) between a
GeomParam (in AbcGeom) vs. a TypedProperty (in Abc), and a
TypedGeomParam::Sample(AbcGeom) vs a TypedArraySample(Abc)?

Thanks again for any clarification!

Best,
JP

[Steve LaVietes]

A GeomParam represents data attached to a geometric primitive. It has a "scope" which describes the "per-whatness" (i.e. per-face, per-vertex, etc) of the data. The GeomParam class itself is an interface which wraps either a single TypedArrayProperty or a compound property containing a TypedArrayProperty of values along with an UInt32ArrayProperty of "per-what" indices into those values. Whether stored in indexed or expanded array form, the class allows you to query the data in either form depending on the needs of your client application. (For example, RenderMan always expects the expanded array form [non-indexed] while other systems require knowledge of what values are explicitly shared as opposed to just equivalent.)

GeometryScope uses RenderMan-derived vocabulary for its enumerated constants. For a polymesh or subd, those translate to:

kConstantScope = 1 element for the entire primitive

kUniformScope = 1 element per face

kVaryingScope = 1 element per vertex

kVertexScope = (for a mesh, this is a synonym of kVaryingScope. For other primitives, it can mean something distinct)

kFacevaryingScope = 1 element per vertex per face (meaning that a vertex shared by multiple faces can have a unique value per face)

A single element (i.e one vertex) may also contain a fixed-length array of values of the TypedGeomParam's type. In your case, you want a single C4f so the corresponding iArrayExtent argument to OTypedGeomParam's constructor would be 1.

I hope this helps. We can set up example code for a simple mesh tomorrow.

-stevel

 

Apologies again if any of this is remedial, but there are a couple
things I'm struggling to understand, so here we go!

If you make it within arbGeomParams, any tool would know
that it's a color-per-vertex -- just not what you specifically want to
do with it in maya.

I'm assuming that this is identified as being color-per-vertex, as
opposed to just some arbitrary list of colors, via the use of a
GeomParam instead of an TypedProperty? Or is there something else
that identifies that a parameter/property is related to verts, faces,
edges, etc?

As for GeomParams, I don't quite understand the some of the arguments
(especially scope) to GeomParam constructor. Is this intended to
classify the components/primitive the parameter is parameterizing? I
read through the GeometryScope header a couple times, but I don't
really understand the impact of specifying one scope or another when
I'm constructing a parameter.

In other words, what is the implication of setting up a color property
under arbGeomParams like this:

AbcGeom::OC4fGeomParam(theArbGeomCompoundProp,
"colorsetname",
false(or True?),
kFacevaryingScope (not sure about this either?),

mesh.numFFaceVertices(),

[John Patrick]

Thanks Steve!  That definitely clears up a lot up for me.

So it seems to make sense that I should add a C4fGeomParam with an extent of 1 to the arbGeomParams property.  In theory, any application would be able to see that there is a color parameter and understand how it is related to the geometry, based on the scope and extent.

Now my question is - are there any examples/best practices for actually determining this information on import?  How do I know what type of data and scope that properties were created with?  It looks like a lot of the examples export some sort of information and then read it back by already 'knowing' the type.

For example, in this case I already know the type of property I've exported, because it's part of the poly mesh schema:

IPolyMeshSchema &mesh = meshyObj.getSchema();


8      IV3fArrayProperty N( mesh, "N" );

Is there a way to determine the specific property type without knowing in advance?

Thanks again!

-JP

[Joe Ardent]

John Patrick wrote:
>
> Now my question is - are there any examples/best practices for actually
> determining this information on import? How do I know what type of data
> and scope that properties were created with? It looks like a lot of the
> examples export some sort of information and then read it back by
> already 'knowing' the type.
>
> For example, in this case I already know the type of property I've
> exported, because it's part of the poly mesh schema:
>
> IPolyMeshSchema &mesh = meshyObj.getSchema();
>
>

> IV3fArrayProperty N( mesh, "N" );
>
> Is there a way to determine the specific property type without knowing
> in advance?
>

Hi JP, I'm glad Steve sorted you out. If you look at
AbcGeom/IGeomParam.h, there are a few methods to help you out with this.
First and most bluntly, there's the static "matches()" method, which
takes a PropertyHeader or MetaData, and is called like:

// namespace AbcGeom is assumed

// fake example for getting your color data
IC4fGeomParam myColorData = getColorData();

// static function in Foundation.h
IsGeomParam( myColorData.getHeader() ); // returns true

IC4fGeomParam::matches( myColorData.getHeader() ); // returns true

N3fGeomParam::matches( myColorData.getHeader() ); // returns false

Then, moving down in the file, you have the following methods:

AbcA::DataType getDataType()

size_t getArrayExtent()

GeometryScope getScope()

which allow you to figure out what's going on with the datatype
(float32_t, uint64_t, etc.), the extent, and the scope.

-Joe

[Steve LaVietes]

An example of this in action can be found in:

prman/Procedural/ArbAttrUtil.cpp

The AddArbitraryGeomParams function loops over and handles GeomParams of types directly supported by prman. (c4f isn't in there but c3f is)

-stevel

[John Patrick]

Great, thanks to you both.  The pieces are starting to come together for me!

Going to keep working away at this; hoping to have some progress to report by the end of the day.

Best,

JP

[John Patrick]

Hey all,

I'm happy to report I've (finally) been able to wrap my head around some of this and incorporate reading/writing multiple color sets using the suggestions offered.

I still have plenty of testing and code cleanup to do, but the changed I've made are here:  http://code.google.com/r/jspatrick-lumapipe

Thanks to all for your help!

Best,

JP