So was thinking since in essence DP and FTE support skeletal meshes (dpm in example) if there is a way to read the bone hierarchy and make certain bones above or below this point perform an animation or rotation seperate from that of the rest of the model.
e.g. player's lower body playing run animation while upper body is reloading.
I feel tagging multiple models to make up players has really shown it's age and basic skeletal control would add so much more flexibility. Is there any reason this hasn't been addressed over the years I'm sure it has been brought up? Is there some technical limitation inherent in these newer Quake based engines that just make it impossible?
Skeletal animation stuff (Darkplaces / FTE type specific)
I tried it sevaral months/year ago, but it didn't go anywhere. It either crashed, didn't do anything or was constantly glitching between the two animations it was meant to play on different parts.
Here was the discussion about the dpm models: http://forums.inside3d.com/viewtopic.php?t=764
I tried doing what Preach suggested, but like I said.. I didn't get it work.
Here was the discussion about the dpm models: http://forums.inside3d.com/viewtopic.php?t=764
I tried doing what Preach suggested, but like I said.. I didn't get it work.
zbang!
So I was having a look at halflife models recently...
My god.
In order to animate a halflife model properly there are multiple things to change.
Firstly there are the bone controllers. These are programmable bone configuration values that move or rotate given bones as defined by the model. In the player model case, all four affect the spine. They also only twist about 90 degrees from forwards.
The mouth controller is not used on players. I don't know why they made it a separate feature. Personally I consider it just a fifth controller.
Secondly there are actually two animations for each shooting animation. One looking up, one looking down. The pitch of the player is chosen by blending between these two subsequences.
I guess it works better for gradual curvature of the spine...
Thirdly there is the movement animation. That is, a separate animation which is applied to the lower body (anything below a specific named bone as far as I can tell). Which basically replaces the animation. Which is what Chris refers to.
What also needs mentioning is that each animation is indeed an animation, rather than descrete frames. Thus there is additional blending to go from one to the next.
And of course, if a model changes animations it needs to blend from one sequence to annother.
Its also worth noting that there is no 'run backwards' animation.
Instead the run forwards animation is meant to be played backwards.
This means you need about 17 different values in order to animate a single halflife player model. That's going to need csqc.
So while we could have a base animation affecting the skeleton up to the pelvis, and a normal animation applying to anything above this, you still lack pitch/yaw control with the zym/dpm model formats.
Conclusion:
Adding in a base/lower animation adds in 6 more fields to csqc, and could be interpolated based on 2 fields from a server (frame number and ending bone and let the engine interpolate).
It still doesn't give the full range of control expected in modern games however.
My god.
In order to animate a halflife model properly there are multiple things to change.
Firstly there are the bone controllers. These are programmable bone configuration values that move or rotate given bones as defined by the model. In the player model case, all four affect the spine. They also only twist about 90 degrees from forwards.
The mouth controller is not used on players. I don't know why they made it a separate feature. Personally I consider it just a fifth controller.
Secondly there are actually two animations for each shooting animation. One looking up, one looking down. The pitch of the player is chosen by blending between these two subsequences.
I guess it works better for gradual curvature of the spine...
Thirdly there is the movement animation. That is, a separate animation which is applied to the lower body (anything below a specific named bone as far as I can tell). Which basically replaces the animation. Which is what Chris refers to.
What also needs mentioning is that each animation is indeed an animation, rather than descrete frames. Thus there is additional blending to go from one to the next.
And of course, if a model changes animations it needs to blend from one sequence to annother.
Its also worth noting that there is no 'run backwards' animation.
Instead the run forwards animation is meant to be played backwards.
This means you need about 17 different values in order to animate a single halflife player model. That's going to need csqc.
So while we could have a base animation affecting the skeleton up to the pelvis, and a normal animation applying to anything above this, you still lack pitch/yaw control with the zym/dpm model formats.
Conclusion:
Adding in a base/lower animation adds in 6 more fields to csqc, and could be interpolated based on 2 fields from a server (frame number and ending bone and let the engine interpolate).
It still doesn't give the full range of control expected in modern games however.
I think Spike you're going overboard into wishlist territory and not even considering implementing a bare bones "play 2 independent animations on one model" kind of thing. Not asking for lerping between looking up and down to determine blending there, simply top body doing one animation bottom doing another. Proper implementation sure would entail a lot of that. But there is literally no support for multiple animations on one model which by even 2000's was quickly becoming an adopted standard for any kind of quality looking game like the ones these engines would be used for.
Wish lists includes ragdoll.
A game that does not support variable leg directions or torso twisting will take flak from it. I don't see this as unreasonable, but I don't see a nice clean way to implement it into gamecode. A legs animation could be implemented in DP/FTE with relative ease without changing the zym/dpm formats.
It would of course require engine, gamecode, and model changes, and only a team of people can really see that through, which tbh is the main reason we don't have anything like it yet.
Incidentily I did already plan on implementing baseframe/baseframe2/baselerpfrac/baseframe1time/baseframe2time/basebone into fte and controlable via csqc.
I could add support for baseframe/basebone in server-side qc but I'm not sure if that would be as practical. And networking/interpolation are a pain. And I'm lazy.
I just fear that its not enough as this mechanism alone can't match such 'classic' games as halflife.
A game that does not support variable leg directions or torso twisting will take flak from it. I don't see this as unreasonable, but I don't see a nice clean way to implement it into gamecode. A legs animation could be implemented in DP/FTE with relative ease without changing the zym/dpm formats.
It would of course require engine, gamecode, and model changes, and only a team of people can really see that through, which tbh is the main reason we don't have anything like it yet.
Incidentily I did already plan on implementing baseframe/baseframe2/baselerpfrac/baseframe1time/baseframe2time/basebone into fte and controlable via csqc.
I could add support for baseframe/basebone in server-side qc but I'm not sure if that would be as practical. And networking/interpolation are a pain. And I'm lazy.
I just fear that its not enough as this mechanism alone can't match such 'classic' games as halflife.
I agree it couldn't match HL1's entire feature set for animations but it would be a great addition and really add a powerful useful tool for developers using these engines.
You mentioned that you could be able to pull off a bare bones implementation using the current formats, but require a team for testing I suppose? I'd be willing to do this for you if you like.
You mentioned that you could be able to pull off a bare bones implementation using the current formats, but require a team for testing I suppose? I'd be willing to do this for you if you like.
EXT_CSQC_BASEFRAME is now supported in FTE.
This extension replaces the earlier bones of skeletal model formats (zym/dpm) with an alternate animation.
Bones before the 'basebone' field's value (use gettagindex) will use the 'base' frames, while bones after will use the regular frames. A value of 0 in basebone uses purely the regular frames.
This means that if your model starts with the hips and legs then has the chest, you can set the base bone to the chest bone, use the base frames to animate the run/standing sequences, and the regular frames to animate the shooting sequences.
This extension currently _requires_ csqc.
I also only just committed it. I may also have gotten the base bone index off by one.
This extension replaces the earlier bones of skeletal model formats (zym/dpm) with an alternate animation.
Bones before the 'basebone' field's value (use gettagindex) will use the 'base' frames, while bones after will use the regular frames. A value of 0 in basebone uses purely the regular frames.
This means that if your model starts with the hips and legs then has the chest, you can set the base bone to the chest bone, use the base frames to animate the run/standing sequences, and the regular frames to animate the shooting sequences.
This extension currently _requires_ csqc.
I also only just committed it. I may also have gotten the base bone index off by one.
about time the skeletal animation stuff got some love!
Have been needing animation blending, bone control in qc and some other seeming simple things to do nice looking animations. It's not like there isn't already far more complex features in FTE and DP already! I can't wait to do some animations in them if the animation systems are brought up to scratch with something at least of HL1 quality.
Have been needing animation blending, bone control in qc and some other seeming simple things to do nice looking animations. It's not like there isn't already far more complex features in FTE and DP already! I can't wait to do some animations in them if the animation systems are brought up to scratch with something at least of HL1 quality.
Benjamin Darling
http://www.bendarling.net/
Reflex - In development competitive arena fps combining modern tech with the speed, precision and freedom of 90's shooters.
http://www.reflexfps.net/
http://www.bendarling.net/
Reflex - In development competitive arena fps combining modern tech with the speed, precision and freedom of 90's shooters.
http://www.reflexfps.net/
