JasonX wrote:Even though the way Q3 handles animation blending is elegant, it requires a much more complex art pipeline, forcing artists to think in separate body parts. I'm thinking about starting a simple test in QuakeSpasm and implement animation blending in multiplayer: running and shooting, for example, without sliding. More complex stuff would follow, but this is a good way to start and learn more about animations. Has anyone tried this before in Quake? Is it possible only with CSQC? Who handles the animations, the engine or QuakeC?
there was a q1md3 mod a while back which supports 3-model md3 players via ssqc tag extensions.
my old csqctest mod has support for csqc-driven ppm md3 player models (it parses animiation info and everything), but is now pretty much uninteresting otherwise.
regarding who handles the animations... 'yes' is as good an answer as any.
csqc has frame, frame2, lerpfrac, frame1time, frame2time, and can thus select animations+time into animations+lerping, for 4-way lerps.
ssqc has only frame, and the client decides the frame2+lerpfrac+frame1time+frame2time as it feels is most appropriate.
In fte's csqc, there is also some basebone+baseframe+baseframe2+baselerpfrac etc fields to control the 'base' bones of the model. thus set basebone to the hips and then baseframe controls bone indexes below while regular frame controls above.
I never did make an ssqc extension to network basebone+baseframe from ssqc (yay network protocol changes!), but if you're an engine coder, doing so is the easiest way to separate torso+legs with an iqm model without depending upon csqc and its skeletal objects extension.
the problem with this is that it merely separate torso+legs. only being able to select a single animation will not give you anything close to foot-sync, and will look weird when changing directions, which is kinda why I never bothered.
iqm has a much smaller memory footprint/file size than the equivelent mdl model, at least with high frame counts. it is still useful even without weird animation stuff, if only because of its higher vertex precision.