Inside3D!
     

DPM models?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> QuakeC Programming
View previous topic :: View next topic  
Author Message
jim



Joined: 05 Aug 2005
Posts: 400
Location: In The Sun

PostPosted: Sat Aug 11, 2007 10:29 pm    Post subject: DPM models? Reply with quote

So what do they do? What can I do with them? So far I've only found out that I can export&convert models into them... I guess they're better than MD3.
_________________
zbang!
Back to top
View user's profile Send private message Visit poster's website
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Sat Aug 11, 2007 11:12 pm    Post subject: Reply with quote

It's a bit of a matter of taste rather than "betterness". It's one of the skeletal model formats supported by DarkPlaces, DPM stands for DarkPlacesModel format.
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
leileilol



Joined: 15 Oct 2004
Posts: 1321

PostPosted: Sun Aug 12, 2007 4:02 am    Post subject: Reply with quote

skeletal formats is memory efficient, if you plan on using a lot of frames or a high poly model
Back to top
View user's profile Send private message
jim



Joined: 05 Aug 2005
Posts: 400
Location: In The Sun

PostPosted: Sun Aug 12, 2007 12:06 pm    Post subject: Reply with quote

Are there some tutorials on how to use them? Take advantage of the bones? Otherwise I'll probably end up using them like MDL models... if they work that way..

I suppose I can combine movement and attacking frames with the DPM? So I don't have sliding and attacking characters? Or need to do some movement attack animation to the model?
_________________
zbang!
Back to top
View user's profile Send private message Visit poster's website
leileilol



Joined: 15 Oct 2004
Posts: 1321

PostPosted: Sun Aug 12, 2007 4:10 pm    Post subject: Reply with quote

jim wrote:
Are there some tutorials on how to use them? Take advantage of the bones? Otherwise I'll probably end up using them like MDL models... if they work that way..


the only thing you can take advantage of is the fact every bone on the model can become a tag to stick stuff on
Back to top
View user's profile Send private message
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Mon Aug 13, 2007 9:34 am    Post subject: Reply with quote

jim wrote:
I suppose I can combine movement and attacking frames with the DPM? So I don't have sliding and attacking characters? Or need to do some movement attack animation to the model?


That's exactly what you can't do, which is what DP always has got a lot of criticism about, the lack of animation blending. Seeing as it's a generally common feature in modern(ish) engines ("ish" considering HL had this in 98 or whenever it was released). It's actually supported in the engine, in the model format, but just not by the QC, which is required for mods to be able to actually use it. There are a couple of easy ways to hack it in with minimal QC changes (like having separate .frame fields for different parts of the model, and a file which defines what parts the different fields point to or whatever), but as LordHavoc is known to wanting to do everything "properly", it seems we're either never getting this feature, or it'll be a good while longer before it becomes reality. As I understand it he wants to add support for proper access of all bones in the model, treating them as entities, so you can manipulate them as you'd like (for example for making ragdoll, IK or something like that), which is what most people who use modern engines would expect to be able to do, but that's really hard considering the lack of memory access in QC. So yeah, the benefit of using skeletal model formats in DP is the fact that you can use bones as tags, and the memory efficiency. You still need to chop it up to multiple entities if you want both running and shooting at the same time, and such.
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
Preach



Joined: 25 Nov 2004
Posts: 122

PostPosted: Mon Aug 13, 2007 10:55 am    Post subject: Reply with quote

Possible way of treating it:

Have three(or five) new builtin functions for communicating between the qc and the model memory.

void(entity ent, float bone) GetBone works a little like traceline, it returns the important info about this bone by setting the values of several globals:

float getbone_frame returns the frame this bone is in, or -1 if it's been set manually(see later)

vector getbone_position, vector getbone_rotation,float getbone_scale return the current position, scale and rotation of the bone.

void(entity ent, float bone) SetBone goes the other way, automatically setting the frame of this bone to -1, and then applying the values of getbone_position, getbone_rotation, getbone_scale to that bone. So you'd use the commands as a pair:
Code:
GetBone(self,$root);
getbone_scale = 2.5 //enlarge the player to 250%
SetBone(self,$root);

It might be an idea to have a slightly different naming convention for these globals, since they are used by both GetBone and SetBone, but the idea is there.

The final global is
SetFrameFromBone(entity ent, float bone, float frame). This function updates all the bones from the specified bone downwards in the hierarchy of the skeleton to the values in the specified frames. So if for instance you had a model with the root bone $root connected to the upper torso $utorso and the pelvis $pelvis, you could set a run and an attack in this way:
Code:
SetFrameFromBone(self, $root, $run2);
SetFrameFromBone(self, $utorso, $attack3);

The run frame is applied to the whole model, then the attack frame is applied to everything from the upper torso onwards(so the model is assumed to have the shoulders, arms, head all be after the upper torso in the model hierarchy). If the position of the root bone isn't important, you could do this as:
Code:
SetFrameFromBone(self, $pelvis, $run2);
SetFrameFromBone(self, $utorso, $attack3);

which avoids setting the values of the upper torso redunantly to the values in $run2 before you overwrite them.

ent.frame = 23 is equivalent to SetFrameFromBone(ent, $root, 23), and the current frame of the root bone is stored in the entity's frame field. Presumably if you start calling these functions on something that's not a dpm model then the only effect they'd have would be to read/set the frame if you're looking at the $root bone.



Does this seem like a reasonable implementation? I think it would do most of what people want to do, like animation blending, in a straightforward way with as few commands as possible. Storing things in globals for a return isn't ideal, but as evidenced by traceline it's probably the best way to get round qc limitations. There's probably a case for splitting up SetBone into SetBoneOrigin, SetBoneRotation and SetBoneScale though, I was going for fewest added builtins. It depends how often you'd want to set all three compared to just changing one...actually splitting it into three function makes much more sense in those terms, plus it rids you of globals. It might also matter how many times you'd need to read the original values before you change them - whether the pairing of GetBone and SetBone is a natural thing almost always, or a largely unnecessary hassle.

The applying frames by hierarchy thing may sound like a compromise, but I think most of the time that's the way people would want to do it. It's very hard to think of examples where you'd want one frame for half your bones, another frame for the other half, but where the bones would be mixed up throughout the hierarchy in a complicated way. At least if you built your model with this in mind...
Back to top
View user's profile Send private message
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Mon Aug 13, 2007 11:06 am    Post subject: Reply with quote

Preach: that sounds as good as pretty much anything, actually better than most ideas I've heard of doing it, since it's simple and straightforward. If manually moving bones around can blend with animations, it'd be just what most people would want (well, to be honest most people just want to be able to mix animations, not do crazy IK stuff like i'd like to do). Now LH just needs to be convinced, or someone else could add it.

*looks at Preach and coughs*
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
Quake Matt



Joined: 05 Jun 2005
Posts: 129

PostPosted: Mon Aug 13, 2007 12:19 pm    Post subject: Reply with quote

The SetFrameFromBone function sounds perfect to me - very easy to use in the QC, and definitely intuitive from a modelling perspective.
Back to top
View user's profile Send private message
jim



Joined: 05 Aug 2005
Posts: 400
Location: In The Sun

PostPosted: Mon Aug 13, 2007 2:11 pm    Post subject: Reply with quote

Allright, that sounds like something useful for animations.

What about the attachments.. could I attach pants or shirt to a model and they would animate properly? I'd be animating them together with the body model. Or is this attachment stuff more useful for more static models.. like attach a weapon to hand and then it moves around with the hand?

I did some test to insert my model in the game. I noticed it's missing the textures, since the all the references to the textures in the smd file are:"noid_naked.png". Then I replace all lines with that to:"models/noid/noid_naked.png". Any way to set the model/texture path elsewhere than the smd file?
_________________
zbang!
Back to top
View user's profile Send private message Visit poster's website
FrikaC
Site Admin


Joined: 08 Oct 2004
Posts: 947

PostPosted: Mon Aug 13, 2007 9:53 pm    Post subject: Reply with quote



I personally don't want to see him naked.
Back to top
View user's profile Send private message Send e-mail
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Tue Aug 14, 2007 6:29 am    Post subject: Reply with quote

QuakeMatt! Apply some msn to that internet of yours
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
jim



Joined: 05 Aug 2005
Posts: 400
Location: In The Sun

PostPosted: Tue Aug 14, 2007 9:00 am    Post subject: Reply with quote

FrikaC wrote:

I personally don't want to see him naked.


Lucky you, it appears to be a she Razz

And it's also going to be the player model on a mission to find some clothes... Yea, instead of finding weapons to kill monsters, you find clothes to bling bling other females and then they collapse from shock about seeing you in better clothes!

ppff.... right... Rolling Eyes
_________________
zbang!
Back to top
View user's profile Send private message Visit poster's website
leileilol



Joined: 15 Oct 2004
Posts: 1321

PostPosted: Tue Aug 14, 2007 6:28 pm    Post subject: Reply with quote

jim wrote:
Any way to set the model/texture path elsewhere than the smd file?


a .skin file, composed merely of:

Code:

body,models/noid_body.jpg
clothes,null
nipples,models/shiny_nipples.png
wetstuff,textures/detail/wetsurface.tga
Back to top
View user's profile Send private message
Preach



Joined: 25 Nov 2004
Posts: 122

PostPosted: Tue Aug 14, 2007 10:46 pm    Post subject: Reply with quote

Inspecting the darkplaces source for feasibility of writing this stuff myself (outlook not good, I'm afraid), I think it turns out bones only have keys for translation and rotation. In more mathematical terms, the bones have a 4 by 3 matrix, the first 3x3 matrix is applied to a vertex in the normal way, and constitutes a rotation matrix, and the 4th component is a constant vector added on as an offset. Of course, you could easily make the rotation matrix a rotation and scaling matrix, by simply multiplying all the values in that matrix by the scale factor. I don't know whether normalisation is expected or constrained somewhere else in the code, all I can say is that the comments only describe it as a rotation.

For those of you unfamiliar with a rotation matrix, I'll explain it in terms you should be familiar with - QC . Think of it as three column vectors side by side, those three column vectors being v_forward, v_right and v_up for a given direction(corresponding to the rotation you are trying to achieve). So they are unit vectors at right angles to one another. When a vector a is multiplied by this matrix, using the normal rules, you end up with
a_x * v_forward +
a_y * v_right +
a_z * v_up

So for a stupidly simple example, a = '1 0 0' will get rotated to v_forward, which is what you'd expect, I guess.

Enough of the maths talk, back to the theoretical coding side of things. Having just introduced the QuakeC notions of v_forward, v_right and v_up into the discussion, you might expect I'm about to suggest a GetBoneRotation function that puts the three rotation values straight into the v_forward, v_right and v_up vector, like makevectors does. Well, I'm not!

What? Well, my reasoning is, while that might sound like useful information, and very easy for the engine to do, it's actually not gonna be great if you want to change the bone's rotation. The problem is that you'd want to pair this with a SetBoneRotation function that takes the same input, and it'd be a hard task to make correct v_forward, v_right and v_up values in qc.

The obvious route would be convert v_forward with vectoangles, rotate the angle you get back, and then convert it back to vectors with makevectors(). However, if you do that, you'll lose information! The problem is that vectoangles will supply you with an angle of 'pitch yaw 0'. From this you'll only reconstruct v_forward correctly, v_right/v_up will be set to something arbitrary. Even if SetBoneRotation took a 'pitch yaw roll' vector as input, you'd still run afoul of this problem.

So you need the GetBoneRotation function to return a full rotation vector of the form 'pitch yaw roll' to stand a chance of setting this properly in my opinion. It could possibly return the values in v_forward, v_right and v_up as well, as a kind of bonus piece of information that might be useful.


One final detail that should be mentioned. I said above that by multiplying the whole matrix by a scale factor you can get the scaling effect. You can also scale the individual vectors v_forward, v_right and v_up within the matrix, and it does what you'd expect, scales in those directions. So if scaling is supported, it should return and be set by a vector quantity, not a scalar!
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> QuakeC Programming All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2004 phpBB Group