- Home /
What is difference between maya's and unity3d's mesh system?
Hello, I am trying to implementing blendshapes in unity3d in these days. At first to test mesh system in unity3d, because to ensure the same number of vertices of model between imported to unity's and exported from maya's. I make a cube (8 vertices, 6 faces - because it consists of rectangular), and export as obj file, and import to unity3d.
After importing, I checked how many vertices in cube, I am really surprised, because it consists of 24 vertices. (I know It consists of 12 triangles by tesselation), To implementing blendshapes, I need to same number of vertices in maya's one and imported in unity's one. How do I have to implement?
(P.S : If you says "How about using mega-fiers?", we have already that kind of solution, and we want to implement own my own.)
is this question about shared vertices ?
this often causes arguments on 3D-related sites!
eg,
http://answers.unity3d.com/questions/193695/in-unity-is-there-a-fast-way-to-find-nearby-triang.html
Note that even otherwise extremely knowledgeable people, surprisingly, have totally wrong ideas on this.
Here's an explanation......
"There appears to be a common misconception that it is "normal for" models to have shared verts where possible, or that verts "should be shared" or "are always" shared where possible.
This is quite wrong, the sharedness of verts in 3D models is random, and is just an artefact of how the model happened to be made. You definitely cannot rely on verts being shared-where-possible, in 3D.
I grabbed the basic Unity3D "sphere primitive" and looked at it. (Since a sphere is "smooth everywhere" it's a good example of a model where you could share vertices!)
It happens to have 339 verts not shared, that, could be shared. I then modified the model to have EVERY vert not-shared where possible, and then modified it again to have EVERY vert shared where possible.
Note that in all three cases, of course the model works exactly the same inside Unity3D or any other 3D graphics process. In 3D, whether or not verts that-could-be-shared, are shared or not, is totally irrelevant. "
@Silvester for anyone (like yourself) who works with and manipulates the mesh, it is absolutely normal, the first thing you do, that you run over the mesh and either sharre-where-possible or indeed never-shared-even-if-possible.
This is a completely normal and standard thing when you are working with mesh, it's like step 1.
(With some algorithms, you WANT shared-when-possible, with some you WANT never-shared-even-if-possible .. it just depends on what you're doing.)
(Often you have to convert to entirely never-shared-even-if-possible coz the algorithm is too hard otherwise, and at the end just (if you happen to want to) go back to shared-when-possible.) Note another sentence from that long discussion ...
"Note that it does not even make sense to say "Unity shares vertices where it can ..." because Unity simply uses whatever vertices you give it, made in a program like $$anonymous$$aya. It would be much like typing "Unity uses blue colours where it can..." - it makes no sense at all, Unity simply uses the colors the user gives it. Similarly Unity simply [generally speaking] uses the vertices the user gives it."
I hope that makes sense and helps in some way
Answer by CHPedersen · May 03, 2013 at 07:51 AM
As far as I know, there is no way to guarantee that, nor should there be, actually. The reason you're getting more vertices in Unity than in Maya is that normal vectors are associated with vertices, not with faces. So, on edges that must appear sharp, the vertices will have to be split in order to provide two different surface normals to the faces that meet at that edge.
Consider this: If you have a cube with only 8 vertices, then the normals at the vertices would have to point in a direction which is the average of the 3 faces that meet at that vertex. This direction is directly away from the cube's center. During lighting, you would get smoothly interpolated lights across all edges, actually making the cube look "round", even though it is most definitely not round. Without split vertices at corners, there is no way to render sharp edges.
Vertex duplication is (in part) controlled by the Smoothing Angle slider in Unity's mesh importer. I say "in part" because some vertex duplication must also take place in the modeling program in order to make UV coordinates wrap around the model correctly, but that is a different discussion. Here, it suffices to say that you can't think of the visual vertices in your modelling program as a representation of the final vertex count internally, neither in Maya nor in Unity.
+1
Well explained.
If you want to implement something like blendshapes you have to group vertices manually and modify them "as one", so all position changes have to be applied to all "members" of one logical vertex. If you "rotate" a vertex you have to rotate all normals by the same rotation-matrix except you actually want them handled seperately. In a lot cases you probably want them seperated when doing animations.
For example if you "rotate" one corner of a cube around the y-axis the frontface will "bend" outwards while the side face bend inwards.
Thanks for adding detail on blendshapes and animation, Bunny. I didn't know how to answer that part. :)
indeed as CHP explains, sometimes normals must, specifically, be different.
Since (in the current day 3D paradigm, and all engines I know of) the array / slab of memory / or whatever that holds normals matches the array / slab of memory / or whatever that holds verts, then in these cases the fact that you have to have separate normals means you have to have separate verts
So in a word some verts must "not be shared". However in relation to your question title, there is absolutely no reason whatsoever, regarding verts that could-be-shared, must be shared. It is totally random and just depends on how the engineers at autodesk happened to be thinking that day.
To repeat, regarding your question title which implies that Unity has a "way" to "deal with" verts, this is wrong, because: "Note that it does not even make sense to say "Unity shares vertices where it can ..." because Unity simply uses whatever vertices you give it, made in a program like $$anonymous$$aya. It would be much like typing "Unity uses blue colours where it can..." - it makes no sense at all, Unity simply uses the colors the user gives it. Similarly Unity simply [generally speaking] uses the vertices the user gives it."
Hope it helps
I don't think the one vertex per normal paradigm has to do with matching array lengths as much as it has to do with the way GPUs process the data. The programmable pipeline processes vertices and then, after rasterization, fragments. Normals are associated with vertices first and foremost because a vertex defines an atomic unit of computation performed by the vertex program on the GPU. Normals are auxiliary data to that. You can't associate them with faces let alone process them alone, because a GPU does not have a "normal shader" or a "face shader". This, and perhaps to a lesser extent array arrangements in main memory, gives rise to the "one normal per vertex"-restriction.
That you store them in arrays of matching lengths is actually an added bonus in terms of memory management, because it allows you to access a vertex's associated normal (and tangent, color, uv, etc) through the vertex's own array index, rather than having to associate them in a class, which would introduce overhead.
Sure, the reason that in our universe there's a "one vertex per normal paradigm" is that, as you say, something to do with GPU stuffs :-)
(Just in general, purely abstract terms, you could certainly have normals everywhere with no connection at all to vertices, or indeed mesh. Indeed scanned point cloud data is just that right? Normals "really exist" in the universe, ie my hand has normals everywhere, verts are just part of the currently common mesh paradigm we all use in game dev.)
Anyway - you excellently explained that in some cases, verts must indeed be not-shared.
So we take that as given. When you get some models from the art dept., some verts "must be not-shared."
However, again, any model you get, it's totally random - regarding the can-be-shared verts -- whether or not they are shared. there is no rule, zero, or guarantee either way.
I thought the question was more about that issue -- the age-old "should verts b shared" "are verts shared in 3d games" etc question.
Again yes, a few verts must be not-shared (as you explain), so forget about those. But regarding verts that COULD-BE-SHARED, there is utterly no ISO rule or specification or religious imperative or industry standard, or any fundamental need for them to be shared, or not.
It's just completely random, what you get from different packages / modelmakers.
As I mentioned, if you're a "mesh worker" it's utterly SOP that you run over a mesh, and, regarding the COULD-BE-SHARED verts, you either make them shared or not shared uniformly, for your purposes. (Yes, in some cases a handful of verts "must-be-shared." )