“Thanks. I was the one who cleaned up the cal3d exporter too.”
hey, cool 8)
“It would be good to check tags because I guessed at how to put the values”
I’m afraid I don’t know how to do tags, I know from a theory point of view, but never did an md3 that was other that one single piece model without all the q3 arena nitty gritty stuff…I used for other engines, as a “better than md3” format, interpolated full unbroken meshes, that’s it.
“As for UVs you are right. Anywhere there is a uv seam, there will be duplicated vertices. What is the effect of this on screen - I didnt quite understand what you were trying to say.”
I’ll explain it. Whenever you duplicate a vertice, you are breaking the mesh there. That is, visually is generated a crease. very similar to a shading seam. In Max, the stuff is known as smooth groups (In Maya, hard egdes, better way to deal it,edges) an smooth group border is a place where the shading has a crease, like a cut. Visually, you don’t distinguish a smooth group crease from a geometry broken edge (duplicated vertices along an edge) .Indeed, I only know from the artist point of view, and depending on the package, I think some even actually break the mesh to make the smooth groups.
One way or the other, is a bad artifact. As you end up seing probaly a clean cut all along the nose, mouth…for example when used the common thing of making right and left side of human face, be sharing vertices (mirroring one side and putting it on top of the other, matching relative uvs.Saves texture space.) but happens every where there’s a uv border. Ie, in the interior of legs.
The key with that problem is put the uv seams where they are seen as a natural thing.Ie, in the interior side of trousers, making in texture a painted sewed border. Or the border of a helmet, the borders of a shirt, etc.
As u see, md3 demands for an uv mappin careful planning. Is not blender or your exporter’s fault, is how is done md3.
So, doing it in a planned way (of course, it will make you loose some advantages) it can be dealed. Usually and already mapped generic 3d model wont do.
But imho, is simply great that now md2 and md3 do have these formats. For low end pcs , is simply the way to go, as no bones weights calculation needed, while still see smooth bending in shoulders and joints, as the can originally done with bones and weights, as they at last get baked as vertex animation, interpolated with linear or spline interpolation.
What I meant is thatnks to you and bobo, now it also have the two main vertex animation exports for games. Having those and the 3 main and more extended bones and weights ones : *.x , cal3d, md5, it practically can export to any engine. Which imho is great.
the list of the game engines that -in theory- could be now(thanks to these exporters) used with blender would make me fill a whole thread with them with just the list, so I’ll avoid that
“It is also possible that threre is a problem with normals - I havent checked them that well”
I don’t know…the export was simple…well…when exported on frame only, I’d say normals where perfect in the external viewer… when exported the animation, it took then the duplicating vertices thing with UVs, so as I had made a per face automatic mapping (all triangles matching in one !) it showed no normals ,all flat, so I can’t tell you…
I can only say that from what I saw, seemed to works as expected.
There’s a freeware tool, called npherno MD3 Compiler (or nMD3c , nPherno MD3c ) that allows to compile an md3 from exported lwos, 3ds, asc or ase, or loading just an md3 and do some editing…one is “rebuild normals”
It was used with first md3 export in Gmax, a Id Software exporter for gmax called tempest. later on, was made another -available for use in comercial projects, opposite to Id’s Tempest- gmax md3 exporter which had not the normals problem ( mojo.gmaxsupport.com )