Polygon normals back into Maya

[Peter Shinners]

Importing a polygon mesh back into Maya gives the correct normals, but none of the Maya deformers update the normals. We've had this same problem with our own geometry importers in the past. I'm wondering if anyone has a solution.

I could imagine a way of approximating the normals by just setting hard and soft edges on the mesh but not providing any normals. That would allow Maya's auto-normals to work correctly, but also would not directly match whatever normals had been written to disk.

Am I correct in assuming Maya forces us choose like this? If so, I may be interested in adding this option to AbcImport.

[Hans Baldzuhn]

From all the test I made on the various way to set the normal back in maya, It looks like there is no way to set the normals without locking them.

The only methods available on MFnMesh so set polygon normales are setFaceVertexNormals() and setVertexNormals().

Both functions are considered by Maya as specifying "user" normals. e.i. normals that are by definition locked. In a maya scene, those user normals exists only if one normal is locked (manually), if a normal is set (witht the set vertex normal tool) or if you use the "average normal" function or any normal operation (including transfer attribute and others).

Those normal are set in object space and doesn't change when the mesh is deformed.

When displaying the vertex normal of the mesh, you can see that the normal turns yellow when locked (it's green when not locked).

If no such normals exists on the mesh, maya doesn't even write normal informations when saving the file. It only specify the hardness for every edge (soft or hard).

The correct way to rebuild the normals would be to interpret the alembic normal data to know if an edge is hard or soft, and then to use the setEdgeSmoothing() method.

I made a test with this feature, simply checking if both vertex of each edge have different normal for each adjacent faces. I was ignoring all possible user normals for the test.

It worked pretty well, creating only "green" normals while respecting the original mesh edge hardness. But it's a bit heavy and it takes twice the time to set the normals. There should be place for optimisation though.

I also simply tried to unlock the normal after setting them, but it's very very very slow, on a production scene, the whole normal operation on the file went from 10 sec to 70 sec. And it breaks all data, as unlocking a user normal simply reset it to default (respecting the edge hardness value).

I will probably be creating a new property on my mesh while exporting that would contain a simple boolean array to store the edge hardness of the mesh and another property to store possible information on user normals (alongside the default alembic normal property to allow other software to read the normals correctly).

I assume there should be a more efficient way because opening a mayaAscii file is way faster than opening the same alembic data when reading all normals. 

On my test file with only user normals (forcing maya to write them all to the file), the ascii takes 4 seconds to load and the alembic around 12 seconds, but it spends 10 seconds on the normal. And it's precisely 10 seconds spent on MfnMesh::setFaceVertexNormals(). 

So I guess maya is not using this function or the speed should match (alembic should even be faster than ascii as it is the case when normals are ingored) but there seems to be no other way to set them from the API. I even looked in the MFnMesh.h file to see if there were some hidden functions  but without success (I already found a hidden function for uvSet, so ...).

I will continue to try and improve the current normal handling in the alembic file using edge hardness but I would love more information on builtin maya normal handling.

Hans

[Tom Price]

I have been writing my own "modelling" format to take out only basic poly and nurbs info, and was stuck for ages on poly normals exporting. I ended up using the     dag.setFaceVertexNormals(normalsIn,
                            faceList,
                            vertexList,
                            om.MSpace.kObject )
method and also found it incredibly slow, whilst we re on the subject though how do people retrieve the mesh vertex number from the face local (I stored the face local from MFnMesh.getFaceVertexNormals(i,array,om.MSpace.kObject)

) but you need to set the normals as mesh relative and not face relative vtx id.

My method is hilariously slow but I think that might be python causing the slowness (anyone have any advice pickling swig?)

Sorry for the thread hijack

TomP

--
You received this message because you are subscribed to the Google Groups "alembic-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

BAFTA Independent Production Company of the Year - 2012 Children's BAFTAs

twitter.com/blue_zoo | facebook.com/bluezooanimation | vimeo.com/bluezoo

blue-zoo, Chesterfield House, 385 Euston Road, London NW1 3AU
t. 020 7434 4111