Posts Tagged ‘MDLEd’

MDLEd And The Infinite Sadness

Sunday, April 12th, 2009

My journeys with the MDL file format have been fraught with annoyance and frustration. I understand why it was done the way it was – back then 3D was new and every path being blazed was a new one and you sometimes take a lot of wrong turns before ending up at the place you need to be but MDL, honestly, is cruel and unusual in its torments.

It took me a good long while to figure out how to read the file to begin with. There are articles on the web that detail this but suffice to say that the compression and the levels of abstraction make for one headache inducing ride. Throw frame/skin groups in on top of that and you’re down to a few shreds of sanity left. Luckily, I had the base work for this done for the original ToeTag level editor because I needed to draw the models in the level for monsters and weapons and things.

However, nothing prepared me for the horrors of writing the damned files back out again. The compression and abstraction leads to extra pain because if you read and write the same MDL file a few times, you lose precision. Suddenly the UV coordinates are beginning to slide around the model and the vertices are drifting. The drifting vertices are the worst of all because eventually MDLEd considers two verts that used to be separate from each other to now be the same – which leads to incorrect vertex counts and an inability to save a viable MDL file.

The solution, i think, is to create my own MED file format that will hold all the floating point verts and UVs within it and it will have the option to export to MDL format when you need it to. This means you’ll have highly precise source files for your models and you can write out the Quake MDL files whenever you need to see the models in the game itself. I can’t think of a better solution at the moment so this will have to do!

But in positive news, MDLEd is coming along. I’ll prove this to you with a screen shot:

snapz-pro-xscreensnapz001

And here’s a shot of the flame model loaded up. As you can see, MDLEd gracefully handles and understands frame groups. It does the same thing for skin groups:

mdledscreensnapz001

Here you see the basic interface. On the left are lists of frames and skins for this model (in this case, the familiar soldier grunt). You can do all the stuff you’d expect to be able to do here – import/export frames, rename frames, drag/drop frames to re-order them, delete frames, etc. All of this applies to the skins list as well.

On the right side is a preview where you can actually see the currently selected frame wearing the currently selected skin. This is more obvious in something like the armor model where there are more than 1 skin. Here’s a quick video that shows me loading up the armor model and playing with the model and skin tabs:

MDLEd Preview Movie

Eventually this is going to have really nice features like being able to paint directly on the skins and to create new skins from scratch!

MDLEd -> Cheetah3D

Sunday, January 25th, 2009

I worked on getting the exporter/importer paths working for MDLEd today. The only thing not currently working is importing of OBJ files as frames. I’ll get to that next time I sit down to code. I decided to use OBJ as my format for importing/exporting frames because it’s widely supported and, since it’s text based, it’s easily debugged and verified. Here’s a look at the Shambler after having his first frame and his skin exported and then imported into Cheetah3D:

picture-1

This is the beginning of what I hope will be a very productive workflow for Quake modelers working on a Mac. Next up : importing frames back into MDLEd and a bunch of glue code (renaming/deleting frames and skins and other details). After that though, it’s on to saving out to the actual MDL file format (once that’s working, I’m only a little QuakeC away from making new models for real!).

MDLEd Preview

Saturday, January 24th, 2009

Here’s a quick look at the model editor that I’m writing as part of the upcoming ToeTag editing suite. This program is for working with MDL files – deleting, inserting, and renaming of frames/skins primarily, but it will also be useful for setting model flags. I’m probably not going to add vertex manipulation into this program but then again – I might! It’ll probably have to wait for version 2.0 however as there is still tons of work to do on this and the other programs. As you can see in the shots below, MDLEd properly handles frame and skin groups!

mdled_01242009_a

mdled_01242009_b

mdled_01242009_c

This program will also be able to do neat stuff like auto generation of QuakeC code so you won’t have to hand type in all the junk necessary to get QuakeC to play the animations in game.

The Things You Learn While Coding

Friday, January 23rd, 2009

I’m consistently amazed at the things I pick up while writing this editing suite. I learned, for example, that MDL files can contain animated skins! At least according to the spec – as usual engine implementations of this may vary. It looks to be set up in the same way as frame groups are for animation. I’m suspicious of them not working simply because I can’t remember a single id model that had an animating texture and you’d think they would have used it if they could have. Hmm… Once MDLEd is up and running (and, most importantly, saving correctly) I’ll give it a try.

This coding job is large but I’m learning a ton about Mac programming as well as stuff about Quake itself. It’s a hell of a fun ride!

PAKEd, MDLEd, LevelEd, Argh!

Monday, January 19th, 2009

Man, writing this editing suite stuff isn’t easy is it? Who knew?

Everything is moving along and I spent the weekend learning a great deal about MDL files and specifically what in the hell a ‘frame group’ was. With that knowledge, I’m now successfully reading all parts of MDL files into proper data structures.

However, that code is currently living inside of the PAKReader class which is wrong. I need to extract it out to an MDLReader class (with an accompanying MDLWriter class). To get those working and debugged it would make sense to get the MDLEd application at least somewhat started for easy testing. To test that application, I will need raw MDL files which means I should add an ‘Export’ function to PAKEd first. Eek!

It’s all doable but it takes time. Gonna put my head down and grind on this stuff for a bit. It’ll be good in the end, I promise!