mdl, md2, md3, dpm, iqm, etc... Optimal model format.

[Spike]

md5 expects the engine to generate normals+sdir+tdir instead of the editor (probably faster than parsing more text anyway).
which sucks with high-res bumpmaps as the tool to generate said bumpmaps might not have used the same normals.

for player characters, skeletal formats without csqc are still pretty lame.

[toneddu2000]

[Spike]

http://fteqw.svn.sourceforge.net/viewvc ... 4player.qc

the predraw function of your player or whatever entity should run prediction then call Q4PM_Draw, and you'll get a q4 player model running around.
note that this code is incomplete and doesn't deal with weapon animations or anything. I got bored. Sue me.
Been about 11 months since I even looked at that code, but it served its purpose which was to make sure that this stuff was actually possible.
Point is that the engine is capable (DP supposedly has the same skel_* builtins as FTE). It just needs (CS)QC to drive it.

Note that the engine does not provide ragdoll support. While it is possible for that to be written in QC (with ode physics or whatever), it would take a ton of work.
The 5th and 6th args of skel_build are the 'first' and 'last' bones to build/copy into the skeletal object. You can use those to provide upper/lower distinctions so that shooting is separate from running (last==-1 means 'all following bones').

Of course, this is generally not relevent for weapon models as you can more easily get away with not needing to blend anything other than between the poses within a framegroup, which is all automagicly done by the engine anyway, but could be useful with something like a spinning barrel that you want to spin down smoothly or whatever, like the q3 machinegun.

The thing to remember is that the engine renders a mesh. And cares only about that mesh. It gets the positions of the bones from somewhere. It internally builds those bones on demand to match the interpolation + frames of each model. Skeletal objects gives you direct control over the exact bone poses, overriding the engine's normal building stuff.
You could use sagdoll, ode, or twig, and implement ragdoll without depending upon any canned animation files. If you do actually read the code I linked to, you'll notice that the animation data used isn't even in the same model file as the mesh.

I don't really make models. I'm not convinced they'd be anything but terrible if I did.
That said, if you want a running animation to really work, you should bear in mind that the csqc will want to blend the animations together, so all directions should have the same total duration (even if different framerates), and cover the same distance.
Missing the strafe animations and depending upon torso twisting will probably look bad.
Note that csqc has a frame1time field which says the absolute time into the current framegroup. You can increase that field not relative to actual time, but instead relative to actual distance traveled (moveddistance/distanceanimationisepectedtotravelpersecond. You can see an example of this in my code. Note the dotproduct between movement and v_right to figure out how much left/right they moved). This will keep the feet synced with the ground.
For shooting, you can either just directly use the frame(group) numbers from ssqc and simply interpolate based on those, or try to animate inteligently based on whenever a shot goes off and whether they're still holding the fire button. I dunno, animate it how you want, I'm not gonna write your mod for you.

[toneddu2000]

[Spike]

regarding first and last bones - a skeleton will generally (hopefully always...) be arranged with some bone ordering like: hips, left left, right leg, torso, left arm, right arm, head. ie: which each subsection of the skeleton extending outwards from the thing that its attached to. your running animation would be bones 1 to whatever bone the torso is (note that technically bone indexes start at bone 1 for compatibility with the predating tags extension or something). to animate the arms, you'd animate the torso up until the head, and the head would be head to -1 (ie: everything else including any potential hair etc).
You can always directly override specific bones, to rotate the neck or the spine or whatever so the guy always faces exactly where you're targetting, or possibly to rotate the first bone to match quake's coord system instead of some other game, or to remove any movement bias for d3 (d3 player running animations do not stay at the origin, part of its IK stuff) - this is not unlike tweeking the smd before compiling.

[Seven]

Hello toneddu2000,

I just read through the detailed explanations of Spike. Thank you Spike.

But one idea caught me while reading:
If you do not want to use csqc + skeletal models and search for another possibilty to use a "run+fire" like animations,
where your model uses different body-parts, then you must look at how Armagon is coded.
You know, the beast at the end of Hipnotic.
This monster is build/made of 2 models:
- foot
- body

The foot turns/behaves "independent" from body.
I just quickly played against him and it looks quite good.
He can:
- run+fire
- different angle of body and foot while shooting
- combine both parts, when he runs after you again.

I know, this is a very different way and maybe also offtopic.
It also cannot be really compared to skeletal animations.
But I thought I should at least mention it, as it maybe does not hurt anyone.

Look into hiparma.qc. Especially the arma_xxxthink functions.
It surely is much harder to do it via qc only, but Jim Dose showed/taught us to do so.
I am really impressed by the qc code he did for Hipnotic.

I am sorry, if this is offtopic.
Seven

PS: Of course the most famous QC "run+fire" mod is Nehahra. I wonder if the source is available.
PPS: Just in case you did not know: A quite good "ragdoll" mod is 'sagdoll' by MauvBib.

[toneddu2000]

@Spike: thanks again, now it's more clear
@Seven: I never played quake's expansion packs so I don't now how final boss looks like. Is hopefully ?
I'll try to find hypnotic's source and take look, thanks a lot!

[Seven]

Hello toneddu2000,

I think you definitely should play the mission packs.
And even more than that: Look at their source code !
Very very important new things have been brought into Quake in these "updates".
Just look at the new features like:
- rotating/pushable walls/ents
- breakable walls
- earthquake
- bulletholes
- motd´s
- ...

Please find the sources here:
http://quakeone.com/navigator/

Once you are there, click "QuakeC" and find the devkits there.
But be careful, the hipnotic devkit has one error/mistake.
The file "hipscrge.qc" has an issue (scourge animation is not working).
I found a correct file for it from somewhere else.
If you are interested, I will be happy to send it.

Best wishes,
Seven

PS: You will find the corrected "hipscrge.qc" file in the "small mod compilation".

[frag.machine]

Speaking of sagdoll... Anyone still have a copy of that ? I can't find it on quaketastic.com... :/

[Seven]

Hello frag.machine,

If it comes to mods, be sure to visit Chip´s quakewiki page:
www.quakewiki.net

The archive there is remarkable.
Here is the direct link to Chip´s sagdoll page:
http://www.quakewiki.net/quake-1/mods/sagdoll/

[toneddu2000]

Thanks a lot Seven,so kind! I'll definitely go check it out!

[frag.machine]

[jim]

Which format performs the fastest? Skeletal formats slower?

[leileilol]

Skeleton will always be slower due to the vector processing overhead which can be a big suck to CPUs not blessed with SSE (read: Pentium II, Athlon). It's kind of why i'm using MDR for OA3 because MDR ins intentionally stripped for performance, and since it's stripped, it's not really a 'standard' format. Darkplaces does not support MDR but that won't matter.

Also I believe Darkplaces converts all skeletal formats into its internal optimized format on load so the file format shouldn't make a difference to it.



i still think MD5 still sucks however. I facepalm every time MD5 is suggested. Anywhere. Any place. It's always misguided on the basis of "because doom 3 uses it and doom3 is pretty it must be the superior choice".

[Spike]

CPUs?...
you're doing it wrong.

the advantage of skeletal models is that when you have high vertex counts with lots of frames, you don't end up with each model requiring 100mb of ram each (smaller file sizes too, but noone really gives a damn about that). Although if you do have high vertex counts, you really do not want to leave it up to the cpu.
skeletal formats are slower, yes (though if you really cared, you could pre-animate it, yay for load times). The real advantage is that you can do proper animation blending instead of the somewhat goofy animations quake3 had - whether your gamecode utilises that or not is a different matter of course, skeletal formats just have more possibilities.

md5 was interesting in that the animations being stored in their own files kept the various ai scripting stuff separate from each other, which was a nice touch. Other than that they do indeed suck, but mappers being able (read: required) to provide their own animations is nice (read: unless you're a mapper).
still, could have been worse. they could have included 'mem required' values and skipped the various vertex etc counts instead, like they did with some of the other doom3 formats. that would have made things fun.