Quake (MD2, MD3 and MD5) to Ogre Mesh Converter (v2.1)

[Devil N]

Good thing I still have an e-mail subscription to this topic. I haven't looked at this topic (and the program) for ages.

Now, to answer your question, the thing about Quake 2's MD2 player models is that they all have the same animation frames. So there's no need for any animation.cfg files as with Quake 3. This actually makes the conversion simpler, but I guess I could have documented it a bit better.

First of all, make sure you're using an <md2mesh> tag for the conversion instead of the <md3mesh> tag that is used in the example configuration file.
Next, instead of using an <animationfile> block, add an <animations> block instead and fill that with the desired animation sequences. For example, this is what it would look like for the standard run animation:

Code: Select all

<animations>
	<animationsequence>
		<animationname>run</animationname>
		<startframe>40</startframe>
		<numframes>6</numframes>
		<fps>10</fps>
	</animationsequence>
</animations>

You can call up the full list of animation sequences from any MD2 model by using the 'QuakeToOgre -i' command line switch. All Quake 2 animations run at a framerate of 10 fps if I'm not mistaken.

btw: This tool is really cool

Thanks.

I should still take the time to have a good look at that problem with the normals though.

[AndiNo]

Thanks, that was really helpful! I'll try it out tomorrow. And yes, I recently noticed this bug too, was wondering where it came from Although currently I only see this in my shadows...
It would be cool if you updated your tool, as this helps some programmers (like me) with only programmer-art-like skills to have something to look at

[Devil N]

as this helps some programmers (like me) with only programmer-art-like skills to have something to look at

That's exactly the reason why I wrote it.

Maybe next week I can find some time to look into what goes wrong with the normals. At the same time, I can clean up the documentation a bit, add an example configuration for Quake 2 models, and release that as a version 1.1. I'm not going to promise anything, but at least you've re-sparked my interest.

[AndiNo]

Sounds cool! But honestly, I think more people use this tool as those who posted here... I think that's often the case. And second, maybe you could somehow advertise it a bit more? I only stumbled over this by accident, although it IS useful...
Oh and one last question: I wrote some config files but I always have to start the DOS shell and call up the program manually with a config, it doesn't work if I drag a config on the exe in Windows. Am I doing anything wrong?

[prchakal]

Hi,

How i convert a MD2 to ogre mesh? With the animations and texture?

Can you post a sample here? with the config xml ?

I need it please

[AndiNo]

As you could have read two posts earlier Devil N is (maybe) already working on this. Anyhow, seems as if there is yet another new user

[prchakal]

Hi, i have sucess on convert the model to mesh.xml and after to .mesh with ogre commando line tool, but i have a problem to load the material.

Here is my xml:

<?xml version="1.0"?>
<!DOCTYPE conversion SYSTEM "../config.dtd">

<conversion>
<convertcoordinates/>

<md2mesh>
<inputfile>
<filename>modelos/knight.md2</filename>
</inputfile>

<outputfile>
<filename>modelos/knight.mesh.xml</filename>
</outputfile>

<referenceframe>1</referenceframe>

<animationfile/>

<animations>
<animationsequence>
<animationname>stand</animationname>
<startframe>1</startframe>
<numframes>39</numframes>
<fps>10</fps>
</animationsequence>
<animationsequence>
<animationname>walk</animationname>
<startframe>39</startframe>
<numframes>45</numframes>
<fps>10</fps>
</animationsequence>
</animations>

<materials>
<material>
<materialname>modelos/knight.pcx</materialname>
</material>
</materials>
</md2mesh>
</conversion>

When i convert to .mesh and load with ogre appear this message on console:

Mesh: Loading knight.mesh.
Can't assign material ☺☻¶ to SubEntity of jogador_entidade_jogador1 because this
Material does not exist. Have you forgotten to define it in a .material script?

This is the code that i use to load:

entidade = sceneManager->createEntity("jogador_entidade_jogador1", "knight.mesh");
node = sceneManager->getRootSceneNode()->createChildSceneNode("jogador_node_jogador1", this->posicao);
node->attachObject(entidade);
node->setScale(this->tamanho);

What is wrong?

[prchakal]

I think that the problem is to load the .mesh file, because a do a test with Ninja.mesh of the ogre examples and i load the mesh and the material sucesfully.

What i can do wrong?

[Devil N]

Sounds cool! But honestly, I think more people use this tool as those who posted here... I think that's often the case. And second, maybe you could somehow advertise it a bit more? I only stumbled over this by accident, although it IS useful...

Well, you can find this topic by searching the forum for 'Quake' and it's the third hit on Google if you search for 'ogre md3'. That's good enough for me. People who really need this and know how to use it properly should also be able to find the topic. Besides, I'm not much of an advertiser...

Oh and one last question: I wrote some config files but I always have to start the DOS shell and call up the program manually with a config, it doesn't work if I drag a config on the exe in Windows. Am I doing anything wrong?

That seems correct. I wrote this program to be used from the command line, so I never tested it with Windows drag 'n' drop. If Visual Studio's compiler doesn't automatically include that functionality, then it's not going to be in there. I'll see if it's feasible to add that feature, because it does seem useful.

Hi, i have sucess on convert the model to mesh.xml and after to .mesh with ogre commando line tool, but i have a problem to load the material.

Here is my xml:

[...]

When i convert to .mesh and load with ogre appear this message on console:

Mesh: Loading knight.mesh.
Can't assign material ☺☻¶ to SubEntity of jogador_entidade_jogador1 because this
Material does not exist. Have you forgotten to define it in a .material script?

What is wrong?

To figure out what goes wrong here I had to get to grips with my own program again first, which took me a little while.

Turns out, you bumped into an interesting bug in my code. First of all, your XML config file is not actually compliant with the included DTD, but since TinyXML does not check for that, neither does my program. For MD2 models, you should only use a <materialname> tag without the <materials> and <material> blocks around it. If you do that wrong, then my program will output an uninitialized char pointer as the material name, and that causes the weird "☺☻¶" thingies in your Ogre log. That'll teach me for using char pointers in C++ code instead of std::string.

The fix on your side is easy. Replace the entire <materials> block in your config XML with just this:

Code: Select all

<materialname>modelos/knight.pcx</materialname>

As a sidenote: do remember that Ogre does not automatically load the texture 'modelos/knight.pcx' for you. You still need to create a material script that defines a material with that name, and then reference the actual texture file from there.

[mkultra333]

Hi Devil N, hope you happen to see this...

I'm working on a Quake 3 related Ogre project at the moment, and although I'm not up to it yet I was planning on adding my own code for loading md3 and maybe md5 models. I've downloaded your code, but there's no license information. My own code will probably be gpl2 and I'll intending to try commercial indy release. I'd like to use your code but as it is I can't touch it.

Any chance you could release it with a permisive license, say MIT? Not that you have to, of course, but it'd be neat and maybe save me a month's work.

[Devil N]

My code is so free it does not need a license. Seriously, even if you want to copy it and claim you wrote it yourself, go ahead, I don't care. I certainly won't sue you over it. The code in this program isn't that great anyway, so you might actually be better off using it as reference and writing a different implementation yourself.

On a different note, I've done some investigating into the normals problem this week and the results are... interesting. More on that later.

[Devil N]

Now, about those normals. I've done some testing and the normals generated by my app, both in Quake's and Ogre's coordinate systems, are absolutely fine. It turns out there is a limitation in Ogre that I noticed when I first wrote the app, but kinda forgot about afterward. And it's that limitation that's the cause of the problem. Let me explain.

As you know, morph animation is not recommended for use with Ogre, and Ogre only supports it for legacy purposes. One big disadvantage of morph animation is that it requires the mesh's normals to be interpolated and normalized every frame. This is a costly operation and because of this, Ogre assumes (yes, one of the few assumptions made by Ogre) that morph (and pose) animations are used only for small motions where the normals remain approximately the same. This means that with morph animated meshes, you can define only one set of normals, tangents, colors and texture coordinates, while only the vertex positions may change in the animation. That's not an oversight by the Ogre team, it's a conscious design decision that allowed Ogre to shed some excess baggage. This topic pretty much explains it.

As for my app, it conforms neatly to these rules, but that means it can extract the normals from only one frame, namely the one indicated by the <referenceframe> tag. Every other animation frame will use the same normals. Since the animations in most MD2/MD3 models are not limited to small motions (on the contrary), that single set of normals will not be correct for most frames, resulting in weird lighting behaviour.

So what can I do about this problem? Not a damned thing I'm afraid. I can only repeat that it is not recommended to use Quake models in Ogre for anything but testing purposes, unless it's a static object. You could nag to sinbad about adding support for normals in morph animations, but that will probably be in vain, or you could add it yourself in a custom Ogre build. As for my planned version 1.1, that will still happen, but it will be limited to the couple of small fixes that were requested here.

P.S. mkultra333: if it's really that important to you, I can paste an MIT license header in every source file for the next release. It doesn't really change anything as far as I'm concerned, but if it will ease your mind, then it is worth doing.

[mkultra333]

P.S. mkultra333: if it's really that important to you, I can paste an MIT license header in every source file for the next release. It doesn't really change anything as far as I'm concerned, but if it will ease your mind, then it is worth doing.

Sure, that'd be neat. May be handy to other programmers too, you never know why might need the code in the future. I think you can even just include the MIT in a text file and just put it in with the project. Although I notice one file is an original ID file, I think I remember that being GPL2.

Given the normal problem above, I may just end up using it as a starting point for loading md5 models (since they have skeletons).

[AndiNo]

I may just end up using it as a starting point for loading md5 models (since they have skeletons).

Will you be making an "MD5 to Ogre Mesh Converter" then? Maybe you two could join forces

[mkultra333]

I may just end up using it as a starting point for loading md5 models (since they have skeletons).

Will you be making an "MD5 to Ogre Mesh Converter" then? Maybe you two could join forces

If you're desperate, I notice Milkshape can import md5 format and export ogre format. How reliable that process is, I can't say.

http://chumbalum.swissquake.ch/ms3d/index.html

I have milkshape sitting around somewhere... haven't used it in a while since I've been programming. If that conversion worked I might use it myself.

[AndiNo]

No, currently I'm not desperate But I thought this would be a cool addition, would fit perfectly don't you think? Anyway, it would be too much work for you I guess...

[Devil N]

MD5 is a very different file format from MD2 and MD3 and I'm not very experienced with it, so I'm not sure how well it would fit in the current application. However, a little research turned up that MD5 is in fact a text-based file format, so it should be relatively easy to dissect, and there already open source libraries available for loading, parsing and accessing MD5 files. The biggest challenge then is to figure out how well the contents of an MD5 file maps onto Ogre's mesh structure, but a conversion doesn't seem to be impossible or even that difficult. Maybe an idea for version 1.5 then.

[AndiNo]

So that means you ARE working again on this? Although I'm already happy with the current version, I would of course appreciate version 1.1 or even higher!
Just stumbled over this: http://www.modwiki.net/wiki/MD5_%28file_format%29
Looks interesting... and as I already thought MD5 uses skeletons for animation, that would fit onto Ogre quite well wouldn't it?

[Devil N]

So that means you ARE working again on this? Although I'm already happy with the current version, I would of course appreciate version 1.1 or even higher!

Well, I already said in an earlier post that version 1.1 will happen, it will just consist of a few minor fixes. I'm almost done with it.

Just stumbled over this: http://www.modwiki.net/wiki/MD5_%28file_format%29

Yeah, I had already found that link, and better yet, this library: http://savannah.nongnu.org/projects/libmd5model/
That will save a lot of time trying to properly parse MD5 files. Just supply the library with a filename and it responds with a neatly organized data structure containing all of the file's data. The individual source files compile and link easily too, so it should be no problem to include it in my app's source code.

Looks interesting... and as I already thought MD5 uses skeletons for animation, that would fit onto Ogre quite well wouldn't it?

Yes, it's a well known fact that MD5 (and MD4 before it, though that never actually made it into Quake 3) uses skeletal animation and so theoretically it should translate well into Ogre's mesh format.

The big question is though, what does Doom 3 do that Ogre does not and vice versa? For instance, I already found out that MD5 meshes don't actually contain vertices, but instead a collection of joints and weights and that vertices have to be derived by properly combining those. I would have to figure out how all that works, and then map every other little piece of MD5 data onto its equivalent Ogre counterpart, performing translations where necessary. Even though it seems fairly straightforward, it's still a pretty big puzzle to solve, and then of course I would still have to implement it. It's an interesting challenge, but definitely one for the longer term.

[mkultra333]

There also appears to be some good info on the format here, http://tfc.duke.free.fr/coding/md5-specs-en.html, including source code.

[Devil N]

Version 1.1 is now available. See the opening post.

There also appears to be some good info on the format here, http://tfc.duke.free.fr/coding/md5-specs-en.html, including source code.

That is a really cool link! It gives a good explanation of how everything works, and the included source code makes for a very good reference. It also compiles easily on both Windows and Linux, unlike the other implementation I found, and because it uses the MIT license I should be able to just copy chunks of it into my own project.

But let's not get too excited about MD5 support just yet. If I could reserve a couple of days to focus only on this project, I would, but unfortunately other work has to take priority. I will be seriously looking into this though. In the meantime, try to enjoy version 1.1

[Devil N]

A little sneak peek of what's currently happening:



Meet Bernie, your friendly neighbourhood flaming zombie.

[mkultra333]

Looks like you're making some great progress.

I'm still trying to work out how I'm going to implement meshes into my project. The complicating issue is that the level editor is based on DarkRadiant, which works with md5 models. Changing it to use ogre .mesh would be very tricky so it would probably be easier to change my ogre project to load md5 models and convert them to .mesh on the fly. This would also make the project more interesting and usable to the typical Q3A/Doom3/Q4 user.

But there's the extra overhead on level load of doing the mesh conversion. And support for the .mesh format in editors is generally better than for md5. I may opt to make the project support both, depending on how fast the conversion runs.

If I do use the md5 format I think your code will be really handy.

[Devil N]

This forum doesn't allow embedding of Youtube movies, so yeah, I kinda cheated there.

[jacmoe]

Awesome, Devil N