i wanted to ask you how you combined the legs, torso and head of the skeleton from quake3 when you converted it to quake1. i can't think of a way to do that in 3ds max while preserving the animation. :S 

I must admit I have only converted one frame of the deathscene,
where it stands straight with all limbs in line.

From there I made a 3ds file of it, which I used as baseframe.
Then in am2000 it is possible to make the model act with sepperated limbs and export the 3ds.

Then I bunched against the 1000 verts limits of Qmle, and had to substitute the torso with all the fine parts for a much simpeler one,
and then I could import the 3ds into QMLE.

It sounds simple, but I tried the knight in Max3d and must say the way it handles bones is much more specific I could give my patience.

Which programm do you use to convert the model?
I searched, as it was in answer of my question
how to convert q3 maps to Q1.
Something like Q3map2 :

http://shaderlab.com/q3map2 

mapping help #6458 

after 2 days of trial and error, i figured out a way to do it.

http://necros.quaddicted.com/temp/hunterq1.jpg
(hunter was always my favourite ^_^ )

the process is roundabout and exceedingly headache inducing. :P
also, if you want to do this, read my whole post first.

step 1: we need to get the 3 q3 md3 files (head, torso and legs) into 3ds max (in my case).
for this, i used this script: http://www.scriptspot.com/3ds-max/quake-iii-md3-importer-public-beta
surprisingly, it worked in 3ds max 9 (usually most scripts this old would never have worked).

if you follow the instructions on that web page, it will work properly: use the script to import upper.md3 first, then lower, then head. this will make sure the tags link up with the body parts.

(pre) step 2: involved transfering the animation key frames from the torso tag onto the torso mesh itself.
the torso doesn't actually move, it only has vertex animation; it uses the tag to make sure the torso is properly oriented with the legs but in order to export the animation, both the translation and rotation must be on the torso mesh object.

step 2: select your torso tag and go to file -> save animation.
save the file with a name of your choosing some place convenient.
now, select your torso mesh and unbind the mesh from the tag.
go to file -> load animation and select the file you saved earlier.
you will get a message box "No tracks are mapped. Create map file?" and click yes.
you'll see 3 list boxes, two on the sides with the middle one empty. Ctrl+Click on both the sides the item that says "Exposed World Transform" then click the button with the arrow "<-"
this tells max to use the world transform from the save file on the selected object. Click the "save mapping" button on the bottom and save it somewhere (not really important, it just doesn't let you load the animation without saving first) then click "load motion".
if everything was successful, your torso should now be moving on it's own, without being linked to the torso tag.

step 3: redo step2 except for the head.

step 4: now you need to rearrange the uv mapping. originally, head textures take up the same spot on uv maps as the body does, but when you are combining all of this into 1 model, you will have overlapping uvs for the head on the body area.
for a quake3 player model, the body is 256x256 and the head (in the case of hunter) comprised of 2 128x128 textures (the face + the feather hat).
i chose to make a 512x256 texture, with the body on the left, and the face+hat stacked on top of each other right next to the body. this leaves a 128x256 empty area we can use for the weapon.

step 5: before we can export, there is one final step to do. the thing that drove me crazy for the longest time was that the head would never export any frames, even though it had keyframes.
the problem is that the tool i had to use to convert the 3ds max models back to md3s (http://www.quakeunity.com/file=481) only looks at *vertex* animation when deciding if there's a key frame there or not. so what you need to do is go into the head at vertex sub-object level and add a key frame to any 1 vertex at the end of the animation. (i just move a vertex an incredibly small amount).

step 6: delete all the tags (they aren't needed) and export the whole model as an ase file. make sure you have it set to export keyframes every frame.

step 7: open up npherno's md3 compiler (http://www.quakeunity.com/file=481). import the ase file but only select 1 component. export the single component back into md3. close, reopen the program and do the same for the torso and head.

step 8: use preach's md3tomdl converter (http://www.btinternet.com/~chapterhonour/md3tomdl.zip) to convert the 3 pieces into mdls.

step 9: (these next steps are the 'dumb' parts) open qme and open up the legs. then, using import object, import the torso.
qme, annoyingly, has no options with what to do with incoming object's skin mapping, so although the nice uvw maps were preserved from the original md3 files, they will be placed next to each other. 

step 10: open quark 4.07 (yes, really). load your combined model. you'll notice your actual skin now is absolutely massive (i think it was 1536x256) because qme just kept adding stuff on the sides.
what you need to do in quark 4.07 is select the torso verts on the skin mapping editing window and slide them way over to the left (where the legs verts are).
for the head verts, i wasn't able to slide them over next to the body verts because they were considered 'on the other side' and so werent' allowed past the mid-point of the skinmap.
so i slide them just to the right of the mid-point.
finally, (still in quark) go into the edit -> model properties menu. change the width to 512 (make sure the 'right' radio button is selected so it will remove stuff from the right side, not the left).
this should place the head verts right next to the body verts and everything should be perfect. if not, the gods have not smiled uopn you and you are SOL, sorry.
Save.

step 11: now all that's left to do is to name your frames which you can do easily in qme.

yay, you have a q3 player model in quake with uvw and animations preserved. :P

note 1: i'm not sure if you could skip the 3dsmax process for the legs and torso, since the only real modification we had to do was with the head (regarding the uv mapping change).

note 2: there may be a way to collapse all 3 components into a single mesh object. the problem is that simply attaching the mesh objects together discards their vertex animation with no way of reclaiming them.
the other method involves using boolean with unify operations but you can't export frames that way because the key frames of the boolean operands don't count and the md3 compiler will only see 1 or 2 frames. (although this method does at least preserve the vertex animation)


so yeah, anyway, in most ways, it's probably better to do it the way you did madfox, import a single frame, combine it all into a single mesh, re-weight the vertices with new bones and animate it again yourself. this is the more logical way, i suppose, but i really wanted the original animations as well. :P 

npherno's md3 compiler: http://www.quakeunity.com/file=481

preach's md3tomdl: http://www.btinternet.com/~chapterhonour/md3tomdl.zip 

The handling of multi-component models in md3tomdl isn't very sophisticated, but could be improved fairly easily. Once you've parsed the md3, you can grab all the components, and there are only two barriers to just shoving them all into the mdl.

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.

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!

However, I would be open to maybe in the future allowing the controlling text file to define sequences of frames from each component. For example:
component_1: 1-36
component_2: 1-6,1-6,7-18,7-18
would use all the frames in component_1 in order, but repeat component_2 sequences. This might be to match the sequences in the torso with running/standing loops in the legs.

Although this would be more work to create, it would be useful outside just converting multi-component models, as you could grab subsets of the full animations on models with only one component. So it is of wide enough use to be worth attempting.

I might try doing the blas� approach in the next few days though, because it should be straight forward to add, and sounds like it would save a lot of pain... 

I.m convinced necros you're aproach leads to the most pure way to extract a Q3monster to Q1!
In my case I more felt out of choice because I didn't expect three animations for one model.
Then the fact Q3models contain much more verts than A Q1 model made my plan for converting a rather silly idea.
As I have only Max3d 4.3 I'm furious looking to get the 9th version to check your method.

Suburp model, hunter! 

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.