Help: CSQC VWEP Options?

[Spike]

not too long ago, onemanclan was asking just what the difference between a bone and a tag was, and why two names were being used (and not interchangably) for what he was told was exactly the same thing.
basically the difference is in how you use it.
a bone is some point inside the model with verticies attached to it.
a tag is some point inside the model where you expect to attach other entities (and optionally verticies too).

but really, the difference is that someone took the time and effort inside their modeling program to ensure that the tag's orientation made sense. you see, a bone's orientation is typically defined purely by its position relative to its parent. the renderer doesn't care about the actual orientation of a bone, so long as its verticies are expressed in the correct positions relative to that bone, and attached bone positions are expressed relatively too. but tags DO care. Tags generally cannot trivially invert the orientation of the parent in order to provide its own orientation because they assume the orientation is fully controlled by the parent, with the child entity being positioned using angles '0 0 0' relative to that parent.

you can rotate a tag post-rigging, but if it has any verticies attached to it, these will naturally break. thus you should ensure that your tags have the correct orientation at the rigging stage in order to avoid having to reanimate it all over again.

there are additional complications in the form of coordinate systems.
supposedly you can display the bone orientations in blender somehow if you can find a 'draw axis' option. the good news is that its also possible to specify a specific rotation in blender somehow. remember that a tag is the 'thin' tip of the bone as displayed in blender, where the 'fat' tip of the bone is actually the parent bone's location.
apparently in blender, the Y axis is the child-from-parent direction while most qc modders wold expect x to match v_forward.
in actuality, this means that blender's y axis is actually quake's v_up direction, and its z axis is quake's v_right direction, if I understand correctly.
or to put it another way, using blender's default orientations, if you have a particle spawner using gettaginfo, in order to aim outwards along the direction the bone appears to point in blender, you should use the v_up value given to you by the gettaginfo builtin, which is not what you would normally expect (yay! thanks blender!..)

long story short, gettaginfo returns the origin and the axis of the bone in world space as the engine understands them. an axis is just 3 perpendicular vectors, and so you can switch them around to pretend to be blender or something.
thus:
setorigin(wep,gettaginfo(self, gettagindex(self,"hand.r")));
wep.angles = vectoangles(v_up, v_forward);
should position your weapon on the hand, and orientate it in the direction of the hand from the elbow.
if its upside down, negate v_forward. if its on its side, use v_right instead of v_forward, or just change the rotation inside blender.
which is very similar to what we started with.

skel_getboneabs returns an origin, NOT an angle. in NO WAY does it return an angle that can be used without doing lots of matrix maths first. it is also in model space and doesn't consider the orientation of the player. you might as well just use '0 0 90' or something.

[toneddu2000]

[Spike]

everything is relative.
imagine you have a model with a vertex in blender. lets say the vertex is at '16 8 24' in blender's coordinate system. lets also say blender's coordinate system is friendly and matches quake.
moving that coord into quake requires two transformations, but lets start with what happens if neither happen. the engine loads your model, throws it at the screen, and... well, okay, it can't move, its always at '16 8 24'. well that's a pain.
well, okay, if we add the entity's origin to that coord, then it can move around, right? so we do some maths and now we translate that coord to self.origin + '16 8 24'. hurrah, now it can move around!... well, okay, the entity can't rotate and that's a bit of a bummer... we'll need to do something about that...
okay, what happens if we generate 3 directions from our entity, namely forwards, right, and up. we'll assume that the v_forward direction points along the x axis - '1 0 0', the v_right direction points along the y axis - '0 1 0', and finally the v_up direction points along the z axis - '0 0 1', and this then gives us this formula to determine where the vertex is: (self.origin + v_forward*16 + v_right*8 + v_up*24).
doing this, our vertex is now positioned exactly as in the previous origin+'16 8 24' point, but remember that these vectors are strictly perpendicular to each other.
remember how right-angle triangles work? you have a horizontal and vertical axis, and they're perpendicular to each other - exactly like our 3 axial direction vectors.

this is where it gets mathsy.
x*x+y*y=h*h (note: in 3d, you can just add +z*z to the left side there)
HEY! THAT'S PYTHAGORUS!
yeah, well, when you have a direction, h, the hypotenuse, must be 1.

with a 45-degree angle on the hypotenuse, we end up with x and y equal. sqrts says that with a hypotenuse of 1, the result says that both lengths must be something close to 0.707.
so what happens if we determine the position of our point(s) with these vectors: '0.707 0.707 0' '0.707 -0.707 0' '0 0 1' ? our point(s) will have been rotated by 45 degrees around the vertical!, one way or the other.
you're probably asking why one of them has a -0.7 there. well, that's because they need to remain perpendicular. if our forwards vector is now pointing down+right (when viewed from above, instead of just right), then our right vector must be pointing down+left (instead of just down).

note that cos(45) == 0.707. yup, cos(theta) = x/h, while sin(theta) = y/h. note that more interestingly sin(theta) = cos(theta+90). oh look. perpendicular.
right, so, we can do v_forward = [cos(angle), sin(angle), 0]; v_right = [sin(angle), -cos(angle), 0]; v_up = [0, 0, 1]; (yes, I switched to using fteqcc's vector construction stuff, because why not).
and this now allows us to rotate our axis freely around the vertical. This is basically what the makevectors builtin does, where the angle used above is the yaw angle (_y).
makevectors generates 3 axis, rotates them around the vertical by the _y angle, rotates them around the right vector by the _x angle, and then rotates around the forward vector by the _z angle, effectively.

right, now, remember how I said that everything is relative earlier, yeah?
well, lets say that instead of a vertex, its actually a bone. the origins all work out the same at least, but directions are more data, but each individual direction is actually a little easier than the origin - the .origin doesn't matter for determining the bone's directions/axis and thus you can transform the bone's forward/right/up vectors exactly like you transformed the origin, relative to its parent position (ie: parent.origin=='0 0 0'). its basically the same thing - rotating a direction around its parent, whether its a unit vector or a displacement from that origin its basically the same thing.

so by determining the entity's directions/axis, we can determine the directions+origin of the root bone of that entity, and from the root bone, we can determine the next bone, etc, until we end up doing the same with the mesh verticies.


so ... wasn't this about angles?
well, yes, but also no. the whole point of this is to show you that skeletal stuff CRAVES directions (read: matricies). the only reason angles come into the whole thing is because angles is what the engine needs for determining the directions of your entities (besides, its smaller for networking, and qc moders tend to prefer just messing with monster.angles_y instead of 3 entire vectors, plus, angles '0 0 0' is not going to result in singularities while its an infinitely small point if that's meant to be a unit vector - good luck with THAT). If you want to avoid using angles, you can use the renderflags|=RF_USEAXIS thing to directly use the v_forward etc vectors instead of the ent's angles (this naturally means you have to manually regenerate those vectors each frame somehow, but hey, it can be done).

randomly switching around the v_forward etc vectors in the call to vectoangles is just a cheap way to rotate the axis to different coordinate systems.
note that vectoangles only uses a forwards and optionally an up direction. it assumes that the resulting angles will point along the 'forwards' vector (this gives the pitch+yaw values on its own), and uses the 'up' vector purely to rotate the effective right+up vectors around the forwards vector.
for added confusion, vectoangles follows the .angles convention, while makevectors follows the v_angle convention. the difference is whether pitch is positive or negative. this is some silly unfixable id bug which has been mentioned multiple times... fteextensions+fteqcc is meant to include remarks on whether a pitch angle is positive or negative.
oh yes, the thing I didn't mention earlier... the engine uses v_left, not v_right. if z is vertically upwards and x is right-wards/east, and y is northwards - then your y axis is to the left of your forwards axis.

the last thing: matrix transpose.
combing a parent with a relative child is nice and easy and yields a result in the same coordinate system as the parent, but how do you determine those positions relative to the parent?
child = self.origin - self.parent.origin;
makevectors(self.parent.angles);
childrel_x = child * v_forward;
childrel_y = child * v_left;
childrel_z = child * v_up;
repeat for each axis too (but ignore the parent's origin for those...)
this ONLY works when your matrix is built from unit vectors. you'll get inverse scaling as soon as it isn't, and you don't want that. in other cases, you'll need to invert the parent's matrix and use that instead, which is non-trivial.
note that dotproducts like those are useful in other situations - determining how far something is to your right is really quite useful.
note that if you DO scale the v_forward vectors etc, the verticies attached to those bones will be scaled accordingly. such scaling can come from blender too, so have fun with that.

[OneManClan]

Spike: Thanks for all the detailed info. I'll be studying what you wrote really carefully.. it might take a while to sink in. I'm hoping links such as these will get my basic understanding up to scratch:
1. A great basic inrtoduction/definition of .
2. Unfortunately I don't have a "general knowledge of vectors math and matrices math", so I found it difficult to follow .

toneddu2000: I'm not sure why you are (IIUC) moving the VWEP with the mouse... Either what you are doing is going over my head, or you have a different idea as to what a VWEP is.. I'm REALLY intrigued by your use of skel_get_boneabs - could this be used to get the hand bones angles? (and then type them in Blender for the VWEP?

Meanwhile:

STATUS REPORT
I've been using the following method:
1. Noesis: Export foo.mdl as .obj file (I'm 'porting' existing VWEPS, which are currently .mdl's)
2. Blender: Open the Rocket_vwep (which I basically manually positioned)
3. Importing the foo.obj into Blender
4. Set the VWEPS origin to the Grip.
5. Manually place the VWEP on top of the ('acceptably' aligned) rocket, and scale it, and position it manually

STATUS: It 'works', but it's 'fiddly', and .... seems 'hacky' and 'unprecise'. There's gotta be a better way.



Q: Re: gettaginfo, skel_get_boneabs, and skel_get_bonerel ... can any of them be used to find the angle of the handbone, so I can then just 'type in the settings' somewhere in Blender, when positioning the VWEP?

Btw, you can see the axes by clicking in Properties->armature tab-> Display->click on 'axes' (and 'Names' too). Here's a closeup of the players hand:

[toneddu2000]

[toneddu2000]

See if these screenshots can help you
I use in Blender Numpad 3 as front view and Numpad 1 as side view (inverted) so it's oriented correctly in game

[OneManClan]

Hi guys,

I've been reading your posts (over and over) and at this point, I'm not sure if we're still talking about

A: How to position the model in Blender so that it appears in the qc correctly without needing adjustments, or:
B: How to modify the self.angles code to incorporate/compensate for/translate the different angles settings in Blender, or:
C: How to rotate the (hand) bone in the original model .. to (somehow) make it 'consistent' with how the VWEP gets exported (?)

toneddu2000: It looks like you gave your model a specific bone for the vwep. I'm not sure how you chose what angle it should point, whether you animated it separately from the rest of the hand, or how you position a VWEP (at the time of Blender export) to ensure it aligns correctly in-game.

[toneddu2000]

[OneManClan]

[toneddu2000]

[OneManClan]

[toneddu2000]

[OneManClan]

[JasonX]

That's awesome! It works perfectly, OneManClan.

[toneddu2000]

I'm pretty sure the code you posted deals only with origin but won't orientate a knife with a rotating hand in a idle animation, for example.
in this case, the wrist will rotate, the knife will be stick to the hand bone, but not orienting as hand bone axis