Doom3world

So I've finally take the time to finish my MD5 exporter. I haven't had too much time to test it but I tried to import some Doom III models (imp and fatty) into MAX and then re-export them with my exporter and the results seem to be correct. BTW, I have only tested the exporter in MAX6.

The worst of this exporter is that takes up too much time for meshes with a medium/high poly count. That's because, to avoid duplicated vertices, I have to, for each face index, loop through the final list of vertices and compare vertex & texture coordinates for each vertex in the list.

Another thing that bugs me is that, when I animate a bone using a LookAt controller (the bone is linked to a node who indicates the bone the direction to look at), the exporter doesn't detect the transform for that bone so no animated components for this bone are exported.

Anyway, hope you find it useful. There is a help file (in spanish and "english" ) into the zip file explaining all about the exporter.

I want to thank bozo for the MD5 specs and der_ton for his MD5 viewer. That way I were able to test my exporter fast and easily.

Download MD5Export for MAX (outdated)
Download MD5Export for gmax (outdated)


UPDATE (08/16/05): new version of the MAX/GMAX MD5 exporters!. Now you can use any node as a bone in the skin modifier (MAX standard bones, CAT, biped, etc) among other improvements.

MD5.MAX.Exporter.For.Skin.Modifier
MD5.GMAX.Exporter.For.Skin.Modifier

Enjoy!.

Nice job!

From one single test I noticed there is something wrong with the model's orientation, but apart from that it worked.

I took a look at the code, and some of that looks familiar, but that's probably because some stuff has to be done the same way. But if you took some inspiration from my exporter, credits would be nice (no hard feelings if I'm wrong. Anyway, if my exporter wouldn't exist, I'm sure you would have been able to do yours just as well. Don't get me wrong here. )

Thanks!


I'll take a look at it.


I have to admit that I took a look at your exporter when I came to a point the bone orientations were not correctly. I found the solution in the:

if (q.w < 0) do ....switch the sign of the quat components

and that was before I read the post of bozo where he exposed this solution so I guess I should credit you. And well, if you see something more, similar to your code let me know, please. Besides that, I don't remember more things.

I have credited people in the help file, you included but only for the md5 viewer so I will credit you for your exporter. I'm not here to make enemies.

Said that. I want to comment something about your code. You have a function that converts a left handed matrix to a right handed one. I thought that MAX stored rotations in a right handed way. So is that for something special or to assure that the matrices are correct?. I say that because I don't convert the matrices to right handed and all seems to work. But who know, always exists a case that destroys all your theories.

One thing more. Your exporter takes less time to export the geometry than mine. As I said before, that's because, to avoid duplicated vertices, I have to, for each face index, loop through the final list of vertices and compare vertex and texture coordinates for each vertex in the list. Do you do something like that or do you export duplicated vertices?.

That's all for now. And sorry for any inconvenience.

Greetings.

@BeRSeRKeR



i think, when you create bones via mirror them, than this mirrored bones have this left-handed matrixes and the code fix this

some times ago i only made a quick test of this and it seems to do the work properly

Forgot to mention that to get the rotation and position of the bones, I was using the "rotation" and "pos" members of the node class but it didn't work in all cases. I always thought that the "transform" member was the result of doing:

mat = node.rotation as Matrix3
mat.row4 = node.pos

but ok, seems not to be the same. So this part is another thing I saw in your code.

Anyway I have updated the exporter and I have credited you for your exporter. Also, I have put a reference to you and bozo in the MD5AnimExporter.ms file.

Greets.

The truth is that I haven't rigged a mesh in my life so things like mirroring bones escapes from my understanding.

I will change that.

Thanks.

you are not alone

i am a coder and do only some really simple modeling stuff for testing-only

btw. nice work

Berserker, I'm totally ok with all of that.

The thing with the mirrored bones matrices resulting in lefthanded bones came up with a model that 7318 did once. If you scale a bone negatively, then the transform matrix becomes lefthanded.
That is also related to the fact that the "transform" property is not necessarily the same as the combined "pos * quat as matrix". That is also mentioned in the maxscript documentation:


About the duplicate vertices, I don't check for that, nope. But I'm not sure if that's necessary. Maybe that's related to another difference in our exporters. Yours collapses each mesh to use one material (even if it uses submaterials), while mine splits it into md5 submeshes according to the used submaterials. I think your way of creating submeshes is to export multiple mesh objects from 3dmax.

BTW, I encountered a real problem with exporting via maxscript, it affects both our exporters. The 6 digit precision of float output is not enough, my camera importer/exporter is done but the problem is really evident there, because the quaternions need better precision.
The problem can also be seen when you export a mesh (with your or my exporter) and import it with my importer again, then there are some slight deviations. I'll think about a custom print function for floats. I don't know of a way to tell Maxscript to use better precision for the built-in print float.

Nice.


Thanks for the explanation. I have implemented your right handed funcion and now, when using mirrored bones, the orientation is ok but the faces affected by these bones are reversed!. I'll have to take a look on it.



Exactly. With my exporter, only one material can be assigned to one mesh so if you want to export multiple meshes with different materials assigned, also, you have to have multiple meshes in MAX.


Yeah, that's a real problem. I have implemented a function that reduces the decimal count of a number down to 5 but as you said, seems not to be sufficient.

Greets.

I have updated the exporter so now takes into account left/right handed matrices. Seems to work ok but I have found a case where the faces affected by the "left-handed bones" are reversed so you can see the "inner" of the mesh. Thanks to der_ton a bozo for help me. That's a great forum where coexists great artists and great coders too!

Download (same URL as above)

So now I have some stuff in mind. I'm thinking of supports biped bones and give the option to export "physiqued" meshes. My first attempt to write a MD5 exporter (when the leaked alpha came up) was using physique to export skinned meshes so if I have time enough, I could try this.

Of course, I have to add support for md5camera too!

Greets.

I have a question regarding md5camera file format.

Here is a snip of data:



Seems to be clear that first triplet is the camera position, the second is the camera orientation and finally the camera fov (correct me if I'm wrong, please).

But now the cuts stuff. I think is a way to specify different "camera takes" so, in the example above, one take would be from 0 to 98, another from 99 to 148, and so on. Is this correct?.

Thanks.

Yep. Actually, the only reason why that's in there is because the engine has to know when NOT to interpolate between two keyframes.

Yes. Makes sense.

Thanks much.

The precision issue I was talking about was not the reason why I had these big deviations, that was a typo in a formula I had in there. The problem was not in the v.91 and is ofcourse not in v.92 of the script. I don't know if the 6 digit precision of maxscript's float printing is enough, so I wrote this:

Feel free to use if you think it is necessary.

BTW, in my new version of the scripts, I added the function for reading the animationRange interval to preset the input values in the GUI, I've seen that your script does that and it's ofcourse a useful detail.

Thanks for share. I will take a look on it.


Yes. It's a good thing. Now I'm trying to design a good way to expose the camera cuts to the user. I'm trying to do it the more easy as possible.

Thanks.

You know, you guys seem to put quite an amount of effort into your exporting tools, but from what I understand they basically do the same. Why not colaberate and work on a single, powerful, exporter? I'm sorry if this is a really bad suggestion and you guys rather work on your own thing, but I figured having two geniusses working on the same tool would make it even better

I think it's not a bad thing that there are two different exporters available. Berserker's exporter works a bit differently, requiring to have each object to use a standard material, but being able to export multiple objects, while my exporter exports only one object, but it can have several textures via multi/submaterials (but I might change that).
Working on the same stuff as a team introduces communication overhead and problems with keeping track of versions.

As long as we allow each other to use the code freely and help each other out by discussion on the forum, I think we have a pretty efficient way of handling it.

Please don't get rid of that!.. If that's what you mean by changing it.

No I won't get rid of that.
My importer imports in the same format, so that's gonna be left in forever. But I might add the option to select more than one object for export, like Berserker's exporter does (note that I had that in the todo list from the first release of my exporter, though).

Not a bad idea at all. Anyway we are sharing code so that's a form of collaboration and a way to speed up the development. And of course, I think we, coders, are a bit reticent to work in group. Each one has his/her code style, his/her obsessions, etc.

And comming back to the exporter, I have found a "bug" in MAX. Actually I don't know if it's a bug or a windows limitation. When you call the function getSaveFileName with a long extension (more than 8 chars), MAX throws an unhandled exception. You can try that executing this in "MAXScript Listener":



A save dialog will be shown where you have to specify the file location and name. So if you don't add the ".md5camera" extension manually to the name of the file, the exception will be thrown.

I have seen that der_ton add automatically a file name and the extension but does exist another way around this?

When I solve this problem I'll release the new version with md5camera support.

Greets.