boning my models
Moderator: InsideQC Admins
16 posts
• Page 1 of 2 • 1, 2
boning my models
im in the process of remaking my md2 into bone models since md2 jiggle uncontrollably for some reason. md3 causes me problems because of it's limits, so i checked out ways to implement boned models
this is a topic that really yearns a decent tutorial. dpextensions.qc doesn't explain well, it just leaves me confused.
ok, from what i can comprehend from dpextensions.qc, i think u have to 'recreate' your model's skeletal arrangement in qc code:
ie:
neck bone
||
||
\/
chest bone ==> arms
||
||
\/
legs
is this correct? then i presume you have to make a framegroups file for every model you want to animate.
ie:
1 10 10 0//idle (firstframe,numberofframes,framepersec,loop)
how would you make the model do this animation at any given point? do u have to use framegroup files? is there any other way of animating skeletal models besides the motion1 = [$motion1, motion2]{}: technique?
i can't get any bones to move, let alone blend them (which requires csqc, if i'm not mistaken). so how do you cause your player model to show up with csqc?
any help will be appreciated!
this is a topic that really yearns a decent tutorial. dpextensions.qc doesn't explain well, it just leaves me confused.
ok, from what i can comprehend from dpextensions.qc, i think u have to 'recreate' your model's skeletal arrangement in qc code:
ie:
neck bone
||
||
\/
chest bone ==> arms
||
||
\/
legs
is this correct? then i presume you have to make a framegroups file for every model you want to animate.
ie:
1 10 10 0//idle (firstframe,numberofframes,framepersec,loop)
how would you make the model do this animation at any given point? do u have to use framegroup files? is there any other way of animating skeletal models besides the motion1 = [$motion1, motion2]{}: technique?
i can't get any bones to move, let alone blend them (which requires csqc, if i'm not mistaken). so how do you cause your player model to show up with csqc?
any help will be appreciated!
-

behind_you - Posts: 237
- Joined: Sat Feb 05, 2011 6:57 am
- Location: Tripoli, Libya
to animate something in csqc, you have a few different fields.
.frame
.frame2
.lerpfrac
.frame1time
.frame2time
What these fields provide you is 4-way interpolation.
if .frame refers to a framegroup, then that framegroup will be animated using the frame1time field, specifically this field says the time offset of the animation. You can change the speed of the animation by adding different amounts relative to the current frame time. Adding distance moved may be a good value for walking animations, for instance.
When your model is meant to start shooting, its time to blend. You can blend by setting the .frame to the new frame, the .frame2 field to the old frame, and the .lerpfrac field to the amount of frame2 to use (0 to 1). Over time, reduce the influence of frame2 by reducing lerpfrac to 0. Make sure you keep the animation times running.
for ssqc code, the frame1time/frame2time is defined to be (curtime - frameXstarttime), for the most part. csqc has more control, but it generally has to update the field each frame.
if your model does not use framegroups, then you only have the 3 fields, frame, frame2, lerpfrac, that need to be considered. Creating viable animations is more awkward here, however.
The description above applies whether the model is skeletal or not.
There are additional extensions which provide direct skeletal control.
One of them is FTE's basebone stuff, which adds 6 additional fields:
.basebone
.baseframe
.baseframe2
.baselerpfrac
.baseframe2time
.baseframe1time
these fields can be used to animate a models legs or so sepearately from the torso. Specificially, they work just as the fields descibed earlier, except apply to bones 0 up to the bone specified by basebone, while the standard fields described earlier affect bones between basebone and the max. So you can split the model into two separate logical animations. DP does not support them however.
The other is the skeletal objects extension, which is fairly complicated.
There is a builtin which creates a new skeletal object, as well as a builtin that destroys one.
You can attach an individual skeletal object to one or multiple entities. All entities using that skeletal object will have their animations overridden by the object's bonestate. You can copy the bonestate from an entity into a skeletal object by using skel_build. This builtin takes a bone range, which permits you to copy only a subset of the bones. So you can set your animation for the legs, copy the legs, set the animation for the torso, then copy that part over too. There is again a 'frac' value to copy in, which means that you can apply various percentages if you wish to blend in multiple animations.
You can call skel_build using any source modelindex you want. This permits you to copy animations from other models if you're too lazy to create animations for every model, for instance, or if you have each framegroup stored seperately from the mesh itself (like doom3/md5 does). They need to be compatible or it makes no sense, of course. Its plausable that if you have a specific bone heirachy used for every single model player model, then you can have meshes that can be positioned over arbitary attachment points like hats or so, even if each player model has different actual animations (hats with rims that bob, rather than statically positioned hats that don't react to the animations of the player other than moving just their origin).
Additionally, there are a couple of extra builtins which allow you to specify the precise angles/offset of specific bones. This is useful for torsos or necks if you want to angle it separately from the rest of the model. Using some maths, you can get eyeballs on stalks to twist in weird ways to always watch the camera, or directly control segments of a robe to give a somewhat realisitic swinging animation.
Basically, you need your bone ordering to be somewhat logical, or the bone ranges that the builtins accept will not make sense. The builtins do not understand groups of bones in any way other than as a range of bones. The group of bones that are the lower body are logically everything up to the hip bone. All leg bones must be numerically lower than this terminating hip bone. As an example. Then you can use skel_build on 0-to-hip, and hip-to-max. The same would apply if you wanted to control only one arm, in which case you would want every bone from the shoulder to the finger tips to be in a single consecutive list so that you can control them all in one go.
Again, framegroups are also optional, but using them properly and where it makes sense is likely to result in simpler code.
.frame
.frame2
.lerpfrac
.frame1time
.frame2time
What these fields provide you is 4-way interpolation.
if .frame refers to a framegroup, then that framegroup will be animated using the frame1time field, specifically this field says the time offset of the animation. You can change the speed of the animation by adding different amounts relative to the current frame time. Adding distance moved may be a good value for walking animations, for instance.
When your model is meant to start shooting, its time to blend. You can blend by setting the .frame to the new frame, the .frame2 field to the old frame, and the .lerpfrac field to the amount of frame2 to use (0 to 1). Over time, reduce the influence of frame2 by reducing lerpfrac to 0. Make sure you keep the animation times running.
for ssqc code, the frame1time/frame2time is defined to be (curtime - frameXstarttime), for the most part. csqc has more control, but it generally has to update the field each frame.
if your model does not use framegroups, then you only have the 3 fields, frame, frame2, lerpfrac, that need to be considered. Creating viable animations is more awkward here, however.
The description above applies whether the model is skeletal or not.
There are additional extensions which provide direct skeletal control.
One of them is FTE's basebone stuff, which adds 6 additional fields:
.basebone
.baseframe
.baseframe2
.baselerpfrac
.baseframe2time
.baseframe1time
these fields can be used to animate a models legs or so sepearately from the torso. Specificially, they work just as the fields descibed earlier, except apply to bones 0 up to the bone specified by basebone, while the standard fields described earlier affect bones between basebone and the max. So you can split the model into two separate logical animations. DP does not support them however.
The other is the skeletal objects extension, which is fairly complicated.
There is a builtin which creates a new skeletal object, as well as a builtin that destroys one.
You can attach an individual skeletal object to one or multiple entities. All entities using that skeletal object will have their animations overridden by the object's bonestate. You can copy the bonestate from an entity into a skeletal object by using skel_build. This builtin takes a bone range, which permits you to copy only a subset of the bones. So you can set your animation for the legs, copy the legs, set the animation for the torso, then copy that part over too. There is again a 'frac' value to copy in, which means that you can apply various percentages if you wish to blend in multiple animations.
You can call skel_build using any source modelindex you want. This permits you to copy animations from other models if you're too lazy to create animations for every model, for instance, or if you have each framegroup stored seperately from the mesh itself (like doom3/md5 does). They need to be compatible or it makes no sense, of course. Its plausable that if you have a specific bone heirachy used for every single model player model, then you can have meshes that can be positioned over arbitary attachment points like hats or so, even if each player model has different actual animations (hats with rims that bob, rather than statically positioned hats that don't react to the animations of the player other than moving just their origin).
Additionally, there are a couple of extra builtins which allow you to specify the precise angles/offset of specific bones. This is useful for torsos or necks if you want to angle it separately from the rest of the model. Using some maths, you can get eyeballs on stalks to twist in weird ways to always watch the camera, or directly control segments of a robe to give a somewhat realisitic swinging animation.
Basically, you need your bone ordering to be somewhat logical, or the bone ranges that the builtins accept will not make sense. The builtins do not understand groups of bones in any way other than as a range of bones. The group of bones that are the lower body are logically everything up to the hip bone. All leg bones must be numerically lower than this terminating hip bone. As an example. Then you can use skel_build on 0-to-hip, and hip-to-max. The same would apply if you wanted to control only one arm, in which case you would want every bone from the shoulder to the finger tips to be in a single consecutive list so that you can control them all in one go.
Again, framegroups are also optional, but using them properly and where it makes sense is likely to result in simpler code.
- Spike
- Posts: 2892
- Joined: Fri Nov 05, 2004 3:12 am
- Location: UK
Alright.
Let's say I'm going to animate my player.dpm: (or .zym or .iqm)
I must do this:
Or is it this?
lerpfac is how strong the blending of two animations is. So what if I'm blending two animations that don't share any bones(ie two animations that use different bones, no bone is animated 'twice')? Lerpfac is not necessary then, right? Or must I set it to '1'?
Framegroups, according to your explanation, simplify the process of animating your models. I guess they aren't really necessary then. Am I right in this statement? Rereading what you said, it seems that without framegroups, I would have less options in terms of animating.
Controlling bones without any animations (ie turning your body in relation to who you are looking at) seems like something unfeasible according to posts here on inside 3d. You ever get it working?
How about making your player model appear in csqc, and not ssqc? I know this is a noob quesiton but it's really bugging me. How do you do it?
Thanks a lot!!!
Let's say I'm going to animate my player.dpm: (or .zym or .iqm)
I must do this:
- Code: Select all
self.frame = framegroup;
self.frame1time - framegroupstarttime;
self.lerpfac = 0; //I don't think this is necessary since I'm not blending right now
Or is it this?
- Code: Select all
example_skel_player_update_begin (framegroup, 1, 0);
lerpfac is how strong the blending of two animations is. So what if I'm blending two animations that don't share any bones(ie two animations that use different bones, no bone is animated 'twice')? Lerpfac is not necessary then, right? Or must I set it to '1'?
Spike wrote:if your model does not use framegroups, then you only have the 3 fields, frame, frame2, lerpfrac, that need to be considered. Creating viable animations is more awkward here, however.
Framegroups, according to your explanation, simplify the process of animating your models. I guess they aren't really necessary then. Am I right in this statement? Rereading what you said, it seems that without framegroups, I would have less options in terms of animating.
Controlling bones without any animations (ie turning your body in relation to who you are looking at) seems like something unfeasible according to posts here on inside 3d. You ever get it working?
How about making your player model appear in csqc, and not ssqc? I know this is a noob quesiton but it's really bugging me. How do you do it?
Thanks a lot!!!
-

behind_you - Posts: 237
- Joined: Sat Feb 05, 2011 6:57 am
- Location: Tripoli, Libya
bone control only works when specified in csqc. if you try using bone extensions in ssqc, it'll either get ignored completely or be invisible, affecting only mesh-on-mesh collisions.
hence why people seem to be having problems controlling individual bones. it needs csqc.
There are multiple examples of exposing entities to csqc.
There's a mod named csqctest somewhere on fte's svn, which demonstrates two separate ways.
The traditional/dp-compatible way is using SendEntity in ssqc to send the fields you want.
The slightly easier way is to use the DeltaListen builtin, but beware that this restricts you to specific fields. Much easier though. :)
Anyway, treat framegroups as sets of animations. Treat bonegroups as a consecutive group of bones like legs, or torso.
hence why people seem to be having problems controlling individual bones. it needs csqc.
There are multiple examples of exposing entities to csqc.
There's a mod named csqctest somewhere on fte's svn, which demonstrates two separate ways.
The traditional/dp-compatible way is using SendEntity in ssqc to send the fields you want.
The slightly easier way is to use the DeltaListen builtin, but beware that this restricts you to specific fields. Much easier though. :)
Anyway, treat framegroups as sets of animations. Treat bonegroups as a consecutive group of bones like legs, or torso.
- Spike
- Posts: 2892
- Joined: Fri Nov 05, 2004 3:12 am
- Location: UK
ok. here's what i did (for anyone wanting to learn)
1 - mad my model
2 - compiled it into .dpm
3 - compiler gave me the macros to use
4 - placed macros in qc
5 - made a .framegroups file for the macros
example
$frame v_gun_1
$frame draw_1 draw_2 draw_3
$frame holster_1 holster_2 holster_3
6 - made self.weaponframe = $draw_1;
7 - it worked!!!!!
thanks (again)
!!!
but:
1 - i can only animate the first set of frames, other frame sets only return the first frame set
2 - i cannot blend weapons using weaponframe. i think it was something forgotten about when frame blending was implemented
1 - mad my model
2 - compiled it into .dpm
3 - compiler gave me the macros to use
4 - placed macros in qc
5 - made a .framegroups file for the macros
example
$frame v_gun_1
$frame draw_1 draw_2 draw_3
$frame holster_1 holster_2 holster_3
6 - made self.weaponframe = $draw_1;
7 - it worked!!!!!
thanks (again)
but:
1 - i can only animate the first set of frames, other frame sets only return the first frame set
2 - i cannot blend weapons using weaponframe. i think it was something forgotten about when frame blending was implemented
-

behind_you - Posts: 237
- Joined: Sat Feb 05, 2011 6:57 am
- Location: Tripoli, Libya
Thanks for sharing this, behind_you! This is a topic that really should need a great attention from the community! I'd really like to write a tutorial for the community on how to make a skeletal model working on DP. Any chances you could help me to write it? I could create test models for it
- toneddu2000
- Posts: 1352
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
toneddu2000 wrote:Thanks for sharing this, behind_you! This is a topic that really should need a great attention from the community! I'd really like to write a tutorial for the community on how to make a skeletal model working on DP. Any chances you could help me to write it? I could create test models for it
I'll gladly help out. but i am still having the problem where only one frame set animates.
PM me later
-

behind_you - Posts: 237
- Joined: Sat Feb 05, 2011 6:57 am
- Location: Tripoli, Libya
Ok this is getting ridiculous. I still cant get things to animate properly!!!!! This is seriously pissing me off! Anyone please help!
I used the zym and dpm compilers and they are still fucking up.
I used these smd files:
ref.smd //reference mesh
idle.smd//idle animation
run.smd//running animation
the compiler spat this file out at me after compiling:
it had this:
frame $ref_1
frame $idle_1 idle_2 idle_3 idle_4 idle_5
frame $run_1 run_2 run_3
i do this in a code:
self.frame = $idle_1;
it works
then somewhere else i do this
self.frame = $run_1;
it doesn't do shit!!!! what am i doing wrong? i even did the skeletonindex thing. please im so close to giving up. anyone????
I used the zym and dpm compilers and they are still fucking up.
I used these smd files:
ref.smd //reference mesh
idle.smd//idle animation
run.smd//running animation
the compiler spat this file out at me after compiling:
it had this:
frame $ref_1
frame $idle_1 idle_2 idle_3 idle_4 idle_5
frame $run_1 run_2 run_3
i do this in a code:
self.frame = $idle_1;
it works
then somewhere else i do this
self.frame = $run_1;
it doesn't do shit!!!! what am i doing wrong? i even did the skeletonindex thing. please im so close to giving up. anyone????
-

behind_you - Posts: 237
- Joined: Sat Feb 05, 2011 6:57 am
- Location: Tripoli, Libya
can you post config file for dpmodel?Maybe you did some mistake on its configuration.
and, regarding zym, don't use it!
It's old and outdated and doesn't support multiple smooth skinning (dpm does it instead). Or you can use iqm
It sound curious to me that "frame $ref_1 ": it's not a frame! It's (if I understood correctly)the classic "T rest model pose" and it shouldn't be included in the frame initialisation, imo
What kind of model are you using? Do you want some help in configuring it?
and, regarding zym, don't use it!
It sound curious to me that "frame $ref_1 ": it's not a frame! It's (if I understood correctly)the classic "T rest model pose" and it shouldn't be included in the frame initialisation, imo
What kind of model are you using? Do you want some help in configuring it?
- toneddu2000
- Posts: 1352
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
- Code: Select all
# save the model as player.dpm
model player
# move the model this much before saving
origin 0 0 0
# rotate the model 0 degrees around vertical
rotate 0
# scale the model by this amount, 0.5 would be half size and 2.0 would be double size
scale 1
# load the mesh file, this is stored into the dpm as frame 0
scene ref.smd
# load the animation file, this is stored into the dpm as frame 1
scene pidle.smd
# load the animation file, this is stored into the dpm as frame 1
scene pwalk.smd
This is exactly what i do. Afterwards the compiler creates a file called player.qc with all the $frame macros. ref_1 is one of the frames it gives me.
I make my smds with milkshape. I don't see what that has to do with much, since milkshape was designed to make smds and the sort.
ok Ill not use zym. I can't use iqm since i don't use blender.
do you see anything wrong with what I am doing? Ill try removing the reference macro tonight
-

behind_you - Posts: 237
- Joined: Sat Feb 05, 2011 6:57 am
- Location: Tripoli, Libya
Alright, I think I figured it out. for the self.frame i realized that in order to do a certain animation specified by the framegroups file, you must do this:
"FRAMEGROUPS file has this:"
//first frame num of frames framerate loopflag
1 10 10 0 //idle animation AKA 0
11 30 10 0//running animation AKA 1
so to do the run animation, set your self.frame = 1 and to do the idle animation, set it to 0. i was thinking that to run you have to set your frame to 11 since that's the frame when the running animation starts.
so I finally got it working! oh and thanks toneddu2000 for pointing out that the ref animation macro was not needed. now I will try to send my entity through to csqc. i will post any progress i make
"FRAMEGROUPS file has this:"
//first frame num of frames framerate loopflag
1 10 10 0 //idle animation AKA 0
11 30 10 0//running animation AKA 1
so to do the run animation, set your self.frame = 1 and to do the idle animation, set it to 0. i was thinking that to run you have to set your frame to 11 since that's the frame when the running animation starts.
so I finally got it working! oh and thanks toneddu2000 for pointing out that the ref animation macro was not needed. now I will try to send my entity through to csqc. i will post any progress i make
-

behind_you - Posts: 237
- Joined: Sat Feb 05, 2011 6:57 am
- Location: Tripoli, Libya
I'm glad you make it work! What you're making is a big step forward for the inside3d and quakec community
- toneddu2000
- Posts: 1352
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
16 posts
• Page 1 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 1 guest