koobas.hobune.stream
unity vertex order
In modo, I have a single unified mesh with NO uv's, and a single material. If I import that mesh into unity, I can loop through mesh.triangles and all of the vertices match up perfectly.
Here's where the trouble comes: If that same mesh has more than one 'island', that is to say, there are a group of triangles that are not welded to the rest, the vert numbers in modo and unity no longer match. I'm trying to figure out why this is happening so I can take steps to get them matching again.
Well, a picture is worth a thousand words, so hopefully somebody can help me figure out what's happening here:
I know this doesn't help you, but I really wouldn't rely on the vertex ordering in a 3d modeller and a 3d engine being preserved. I think I'd do some vertex matching as a tool in Unity (assu$$anonymous$$g the important thing is that you match vertex 2 and 16 and so on in your diagram.)
Hrm, see I thought vertex order preservation was one of the tennets of 3D.. that's how different applications are able to calculate normals without having them explicitly stated..
I can 'project' which vertex is which, but I run into problems when they occupy the same space- for example, 16 and 2 in this example would have the same coordinates, but they are not connected- i would need some bulletproof way to know that 16 and 21 are part of the same triangle, not 16 and 3, or 21 and 2..
any thoughts?
Thinking on this problem more, I suppose what's more important to me than vertex order is making sure I have some way of correlating triangle data between my custom data set and the mesh inside of unity.
So I could attack the problem in another way- At the time the mesh is imported, I could cache the centers of each triangle, and compare those against the centers of my custom data. There should never be a triangle that overlaps to such an extent that it would have the same center as another triangle, so it could be sufficiently bulletproof for my needs... it would, however, make importing one of these special meshes take a lot longer, because that's a lot of division :P
edit: actually, I could even avoid the division altogether since I don't need the accurate world positions of the centers, just the relationship, so I could just let x = ax + bx + cx and not average them.
Hi,
I addressed a similar problem to automate exportation of BlendShapes from Maya. My basic approach in Maya was to tag vertices with color values when they are exported (using a background Python process). You can effectively use this method to get a lookup into your point order in the modeling application if you need, or to generate a mapping system between your new and old point orders. I imagine you get the idea.
I have a video here showing how I use it: http://www.youtube.com/watch?v=JT39maunxLk And all of my source code is free via the asset store: http://u3d.as/content/adam-mechtley/maya-extensions/1Cy
Though it may not solve your problem directly, maybe there's an idea in there you can use.
Ah, that's a clever way to do it. I guess the ceiling with this method would be 16,581,375 verts, or 4,228,250,625 if you're using RGBA. very reasonable!
Right, but since Unity's importer only allows 65535 verts per model, you have plenty of wiggle room ;)
for sure. this method seems to be a clear winner to me since I won't be using vertex colors on these special meshes.
