the whole process i followed was so convoluted, i lost track of why i did certain things.

i do remember having problems when i originally had all 3 mesh components exported into an md3 with md3tomdl crashing.

also, it would be more useful to be able to control frame naming.

like:
name_frame_0 "stand"
name_frame_8 "walk"
name_frame_20 "run"

just name the frames in incrementing order until it gets to a new label, then switch to the new one.


The first barrier is accounting for separate components possibly having different skin files. Since this is rubbing up against a technical limitation in quake, I think the solution I'd advocate is to just bung all components into the same space on the skinmap. So you'd need to prepare your md3 in advance to ensure those parts don't overlap. Still, anyone making a quake mdl has to do that at some point. You might as well do it in your md3 editor, since it's probably more capable than any tool for an mdl.

i knew going in that i'd only have 1 skin file, and so adjusted my uv mapping accordingly. this is something i'd say you can pretty much assume. unless you wanted to try something fancy like auto combining pcx files next to each other for each different skin and then offsetting the uv coordinate appropriately. i mean, that would be pretty awesome, but it's not like you can't do that in 3ds max.


The second barrier is that different components may have completely unrelated animations. This could be overcome with the same blas� approach as the first barrier: We assume that the md3 has already been edited so that for each frame on the torso, the corresponding animation desired for the legs has the same frame index. This certainly would be easiest to code!

in my case, at least, i didn't even think about it: i automatically aligned the proper head/torso animations with the leg animations. honestly, unless there's some reason i'm not thinking about, i'd say you can pretty much assume if a multi-object mesh is being converted that the frames have been properly aligned.


ps: madfox:
if your only purpose is to work on old games stuff, i'd actually recommend you try version 6, 7 or 8.
there were a lot of good plugins and scripts made that haven't been upgraded to run in version 9+.
if you use version 6-8, you can use pop_n_fresh's md3 exporter which is a lot easier than using the damn md3 compiler by npherno. :P 

I know necros is in agreement with me here, but thought I'd say this:

Autocombining skins can be done. Automatic combination which is nice - low skin wastage, power of 2 skin dimensions, scale preservation - is almost impossible except when it is trivial. If you have two 256x256 skins then putting them side by side is straightforward, but if you have a 128x128 head as well, you're in trouble. And I know that quake can take irregular skin dimensions, but the reasons no other games do that still apply to hardware quake rendering.

On naming frames: it is something I'll probably include in the end, since the hardest part of coding that is writing c++ which will parse the list out of the text file. The reason it's low priority is that the engine doesn't use frame names for anything. Possibly when I add support for framegroups, there will be more reason to have this. You would define the frame sequence names, then have a second list of which of those frames should be framegroups.

Wild though for the day: Since I'm the person so in love with the edicts command, I invented another feature for it. When you get edicts info for an entity with a model, the value listed in "frame" should be the name of the frame pulled from the model, with the actual frame number in brackets. 

I had a look at the code last night, and was a little surprised to see that the code already iterates over all of the components during the mdl export process, in the manner I suggested above (mapping everything to one skin and presuming the frames align). So far, so good.

The problem actually appears to be in the md3 loading code, which fails in the case of 3 or more components, although I believe it should work with 2. Hopefully I will be able to fix this very quickly and then release version 2 as a bug fix which enables many features... 

So I think I may have discovered one of the contributing factors to the bug. While reading the header for the MD3, I skip over the number of tags that the model has, since they aren't used in Q1. You can get away with ignoring some data when parsing an MD3, because it helpfully gives you offsets within the file to the various frame/tag/surface chunks. Unfortunately I forgot to do the corresponding code to skip the bytes representing the tags offset in the header, and so was reading that value into the surfaces_offset instead.

The only reason I ever got away with this is because usually I use the program on models with no tags, since there's no point adding them to models for Q1. Any time you try to import a model with tags, it chokes by trying to use tag data as vertex counts, which often end up being negative values. So hopefully with that fixed, I can close in on the bugs with multiple surfaces instead... 

http://www.btinternet.com/~chapterhonour/md3tomdl.zip

Version 0.2 with proper support for multiple surfaces. As it turned out, not one character was wrong with the mdl exporting code from v0.1 with regards to multiple surfaces. It was all errors in the md3 loader which I think are now squashed. Comments welcome! 

don't think it's unappreciated! :) i will see how it goes with klesk tonight. 

When I saw the serpent in the Qtest map I thought it looked like a bad imported dxf file. One that appears after bad im/exporting.

So I decided it could look better, but after my first attempts I realized how difficult it is to import a good dxf/3ds file into QMLE.

Always the skinfile looks damaged with triangles appearing mirrored. When I finnaly had a good one I thought to be right.

Obviously the skinfile tends to keep its mirrored habbit.
What to do about it?

http://members.home.nl/gimli/Base.jpg 

after replacing all distorted triangles I ended up with a meshed skinfile.
Then I loaded the model into q2mdlr9b and imported the skinfile in pcx.
It loaded well in qmle after redrawing the verts on the skinfile.

I had to know this before, after all the time I spend in QMLE correcting skinfiles. 

here's my result of the serpent.
I only construct the model, the skin is one of androidart.com I lately saw here on the board.
Sure is a fine skin texture piece.

http://members.home.nl/gimli/serp00.gif 

pretty nice... it'd be cool to see a flock of these swarming around a map. 

 

Madfox, that is very good stuff :) You should really use that as a new monster type. Would look awesome as a flock swirling around high above the player before attacking. 

just as ambient creatures that fly about.

Very nice, indeed! 

It's Quake - they should be trying to kill you. 

Thanks for your attend.

While I'm learning to understand what makes monster developement so hard I'm mostly surprised by the way I'm struggling with QMLE.

I've spent months on Bones trying to correkt verticemeshes. Thing is: QMLE imports from the baseframe. If this baseframe is allready in the model.mdl the program tends to import dxf/3ds files corrupted.

Me being glad to have the model in Qmle didn't mind to go frame by frame updating all corrupted vertices, with the habbit Qmle always picks up the wrong one.

Untill I found out when importing the fresh baseframe and then at one stroke all frames importing delivered a clean model.
My god... !

Then the skinproblem appeared.
When an imported basefram is in QMLE, and not all trianles are visible (which is always the cause) the imported skinfile will be partly mirrored on the unseen triangles.
It took me almost ten years to conclude this.

Now looking back it comes to me as if the serpent model in Qtest is a kind of distorted imported model. Although they (ID) had to take of as less verts as possible they made some good models with these limits.

The Qtest-serpent has 90 verts and 178 tris.
Mine ended up with 95 verts and 190 tris.
Can't help seeing the reminisence with the later dragon models. 

congrats dude, its very cool model :) 

Anyone know if this was ever released?

basically I want to remove the 'helpful' auto-UV map feature that breaks my UV's and makes them shitty Quake front/back projection when importing non .mdl stuff.

I realise having the source might not help me still so am going to try the model exporter from Spirit's bounty as well.

Doubt that'll work either though since Qme only imports frames in .dxf - importing udner two distinct formats will probably renumber the verticies and corrupt the mesh. 

two apps that would be nice to be open sourced. 

so he can go on a rant on how all of quakes stuff should be open sourced, at least form this point forward.

and then ill be back later to agree with what he said 

to be part of Baker's army on that front.

Non-open is death. Even the most dedicated are only human. A binary is a slow death. 

What's a decent way to convert to the Quake palette from full colour in Photoshop?

Metslime, what are the changes that you'd make to TexMex? It seems to do pretty much everything needed, for me. Just curious. 

there's at least one crash bug that i hit periodically, plus it doesn't remember folder names from previous export/open/save operations, also, maybe some better fullbright handling. 

Would be nice. 

ijed, are you asking what will yield the best conversion result?

the only thing i'd say is to check each of the different dithering options. some types of textures will look better with one type of dithering pattern, and others will look awful.

also, unless you want fullbrights, make sure the palette you're using to convert has the fullbright colours blacked out. 

Thanks for the info.