i think maybe the solution is in 3dsmax and not the exporters... there might be some way to create a vertex animation out of multiple copies of a mesh as long as the vertex # are consistent.

the thing that jumps out immediately would be to use the morph modifier with 1 channel for each frame, and to incrementally toggle each one on and off on the appropriate frames, but that would be extremely annoying and there might be a limit to how many morph targets you can have. 

Morph would do it, but be very time consuming.

A nastier problem would be that each model would be its own object, and so have the verticies number individually - there's no way to manage this in max.

Normally with morph you use instances of the same object so that the verts have the same numbers - different objects would most likely get interpolated all over the place.

Bones is the way to go - but that means recreating all the monsters as such :P 

It wouldn't take much time really - what's needed is a decent morph plugin that allows more vert control - morphing via position as opposed to number.

Will be looking around. 

My usual route is to convert it to md2 format using QMe, and then importing that with an import script(this is gmax, but I'm pretty sure that the same script can be found for 3dsmax). I do worry that some animation quality is lost in the conversion. It is potentially avoidable, by choosing the scale to be the same in each frame of the md2 you can get a lossless conversion, however I suspect that QMe does not do that.

If the fidelity of the animation proves to be a problem, then I might be able to knock up a python script or something which does mdl->md2 lossless conversion(modulo the skin, which would just get mapped index for index). 

the gmax md2 importer script here: http://www.scriptspot.com/3ds-max/quake-ii-md2-importer works with 3ds max 9. i was able to import some stock q2 models in with full animations in.

next i'll try converting to q2 from q1 format. 

success! thanks for the help! ^_^ 

 

If it works with 9 and gmax then in theory it'll work with all versions since gmax was discontinued a few years ago (?) so it should be alongside the .3ds format - one of the few things they don't fuck about with on a version by version basis. 

I have come this far with my amphibian monster.

It stands on land and in water and starts its attack as soon as the player is in vieuw. The landmonster will start shooting and follows it into the water where it turns into swim behaviour.

The watermonster will go into swim position vieuwing the player, but only starts its attack when agitated. Also it hardly shoots as its position is somehow dull.

Point is I can't get it out of the water.
I'm trying to see with my hard-egged qc cramp what's going on but must admit I'm a dumbass.
Here's an example of the model:

http://members.home.nl/gimli/harpio.zip 

didn't look at the code, but for the (uncompleted) monster that was supposed to do what you are describing, i settled on making special monster jump triggers.

essentially, you would make your trigger in the area you wanted the monster to jump out of the water and you'd just set speed and height just like a normal jump trigger.
the only differences were that:
1. it didn't affect any other monsters
2. if it was a 'get out of water' trigger, it would do nothing if the monster was on land (and if it was in the water, 'get in the water' triggers would similarly do nothing).
it makes coding it a lot easier, but it kind of takes away from the monster by making it dependent on the mapper. (imagine if fiends only jumped where mappers put triggers, for example).

you could take a look at the code that makes the player jump out of the water. this could work but it could be troublesome.
the player code is run every frame, so it doesn't miss chances to jump out of the water.
but a monster not only is running it's code slower (0.1 seconds) because of movetogoal, it will never really be flush with walls unless it gets lucky.

otoh, if all you mean is you can't get the monster to walk out of the water on, say, a ramp, the trick is to take off the FL_SWIM flag early.

every frame of your swim function, run a test of the pointcontents over the monster's head (say 16 units over the monster's origin) and use that point to determine when to swim or walk. 

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