Forum

Help: CSQC VWEP Options?

Discuss CSQC related programming.

Moderator: InsideQC Admins

Re: Help: CSQC VWEP Options?

Postby Spike » Sun Mar 29, 2015 3:04 pm

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.
Spike
 
Posts: 2883
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: Help: CSQC VWEP Options?

Postby toneddu2000 » Sun Mar 29, 2015 7:13 pm

Great description Spike, very detailed, thanks a lot.

Code: Select all
setorigin(wep,gettaginfo(self, gettagindex(self,"hand.r")));
wep.angles = vectoangles(v_up, v_forward);

Yeah, that did the trick, huge thanks! Odd enough, if I use weapon bone instead of hand bone, weapon doesn't align to bone. I deleted weapon bone recreated and now it's ok(just a matter of tweaking)!

And yes, you're right: I stil don't grasp the concept of "angles" and how to obtain them from an entity. There's some tutorial about it?
toneddu2000
 
Posts: 1315
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: Help: CSQC VWEP Options?

Postby Spike » Sun Mar 29, 2015 11:29 pm

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.
Spike
 
Posts: 2883
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: Help: CSQC VWEP Options?

Postby OneManClan » Mon Mar 30, 2015 12:25 pm

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 World space and model space.
2. Unfortunately I don't have a "general knowledge of vectors math and matrices math", so I found it difficult to follow this one.

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:
Image
Image
Last edited by OneManClan on Mon Mar 30, 2015 1:01 pm, edited 5 times in total.
OneManClan
 
Posts: 243
Joined: Sat Feb 28, 2009 2:38 pm

Re: Help: CSQC VWEP Options?

Postby toneddu2000 » Mon Mar 30, 2015 12:27 pm

Thanks a lot Spike, huge piece of document, really appreciated.

Spike wrote: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).
Yeah, during my roaming on fteextension I saw it but I couldn't understand it, now I can!:)

EDIT: sorry onemanclan: when I was posting, your post came first and I didn't see it!
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?
No I just expressed myself in a imprecise way: I used mouse to move player's spine and, with my (wrong) code used, it coudln't find bone angles so weapon was positioned, for a strange reason, outside weapon bone coordinates, thus weapon was affected by mouse movements but it was NOT my intention. Forget about skel_get_boneabs - read what Spike said. That's the truth! :D

Regarding what you did: I simply modeled my weapon as separated model, exported and connected to rifle entity and then aligned rifle entity with Spike's code.

Code: Select all
setorigin(wep,gettaginfo(self, gettagindex(self,"hand.r")));
wep.angles = vectoangles(v_up, v_forward);


It worked flawlessy! The weapon rotates when arm bone rotates. Make sure to change the bone used if bone hand is not working. I don't know why, but first time I tried it didn't work. I deleted my weapon bone, I recreated using only orthogonal positioning and fixed rotations (45 degrees, etc) in Blender and then it worked. What happens to your weapon model? How is it orientating?
toneddu2000
 
Posts: 1315
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: Help: CSQC VWEP Options?

Postby toneddu2000 » Mon Mar 30, 2015 2:58 pm

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
Image

Image

Image
toneddu2000
 
Posts: 1315
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: Help: CSQC VWEP Options?

Postby OneManClan » Tue Mar 31, 2015 1:17 am

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.
OneManClan
 
Posts: 243
Joined: Sat Feb 28, 2009 2:38 pm

Re: Help: CSQC VWEP Options?

Postby toneddu2000 » Tue Mar 31, 2015 11:03 am

OneManClan wrote: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:

yeah me too. Infact I posted you an image of my weapon model, positioned in Blender space. I repeat myself again: no bone have been used for weapon. It uses mesh pivot as "grip". Of course this method is no good for a weapon like a heavi machinegun. In that case you should export the weapon model with bones and try to attach hand left and hand right to weapon grip bone 1 and weapon grip bone 2, respectively. But that's another story.
OneManClan wrote:B: How to modify the self.angles code to incorporate/compensate for/translate the different angles settings in Blender, or:

I didn't modify any self.angles to incorporate/compensate anything. I used Spike's code on weapon entity. End. And what different angles settings in Blender did you find? I mean, if I model my (weapon and character) model in Blender with inverted coordinate system(X for Y and Y for X), in FTE I've no problem of orientation/scale. 1 unit is 1 unit, X axis is X axis, Y axis is Y axis, Z remains Z
OneManClan wrote:C: How to rotate the (hand) bone in the original model .. to (somehow) make it 'consistent' with how the VWEP gets exported (?)

I used a new bone (like Xonotic does) called weapon, the strange orientation it has is a result of try and catch. First I made it aligned to hand bone. No. Weapon was completely misaligned, then I position it perpendicular to Z axis: even worse. Then I found that the correct angle was diagonal, pointing towards hand. The weapon now stands correctly in arm and rotates when arm rotates. Perfect.

The only help I can give you is that, if you share the skeleton you used, I can check it for you and see if I found your problem, but, at present moment, I'm not sure anymore what is your problem with vWEP! :D
If you have a little patience I'll post my skeleton model(matter of days).

#EDIT: I forgot to mention that weapon bone is child of hand bone
toneddu2000
 
Posts: 1315
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: Help: CSQC VWEP Options?

Postby OneManClan » Thu Apr 02, 2015 12:58 am

toneddu2000 wrote: Then I found that the correct angle was diagonal, pointing towards hand.
Ok, what do you mean when you say you 'found' that the correct angle was diagonal? Maybe it's a language issue (mi scusi), but 'found' implies guesswork/accident - rather than a reliable method. Or have I misunderstood you?
toneddu2000 wrote: The weapon now stands correctly in arm and rotates when arm rotates. Perfect.
Not sure what you mean by 'when arm rotates'. You mean the VWEP moves correctly when the player shoots? :?

In any case, reading your post, I'm left wondering: how did you 'find' the correct angle'?
OneManClan
 
Posts: 243
Joined: Sat Feb 28, 2009 2:38 pm

Re: Help: CSQC VWEP Options?

Postby toneddu2000 » Thu Apr 02, 2015 8:32 am

Ok, what do you mean when you say you 'found' that the correct angle was diagonal?
No language issue, I repeat: it was a try and catch method(I said earlier). I tried every possible angle in Blender and I tried it then in game. After a lots of attempts I found that THAT angle was the only that aligned weapon correctly in the hand of player.

Not sure what you mean by 'when arm rotates'. You mean the VWEP moves correctly when the player shoots? :?
I mean, that, when player run, for example, or plays idle animation, right hand moves and rotates. Well, weapon moves and rotates accordingly (and THAT's it's what I wanted).

In any case, reading your post, I'm left wondering: how did you 'find' the correct angle'?
See me first statement

Maybe it's a language issue (mi scusi)
It's almost good but it would be better 'scusami', it's less formal! :lol:
toneddu2000
 
Posts: 1315
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: Help: CSQC VWEP Options?

Postby OneManClan » Fri Apr 03, 2015 7:16 am

toneddu2000 wrote:
it was a try and catch method(I said earlier). I tried every possible angle in Blender and I tried it then in game. After a lots of attempts I found that THAT angle was the only that aligned weapon correctly in the hand of player.


Ok, by 'try and catch', I'm assuming you mean 'trial and error'.

toneddu2000 wrote:
Not sure what you mean by 'when arm rotates'. You mean the VWEP moves correctly when the player shoots? :?
I mean, that, when player run, for example, or plays idle animation, right hand moves and rotates. Well, weapon moves and rotates accordingly (and THAT's it's what I wanted).


Ok, well it sounds like you got it working. As I've said, I also managed to find the 'perfect angle', but it was (like yourself) through trial and error.
OneManClan
 
Posts: 243
Joined: Sat Feb 28, 2009 2:38 pm

Re: Help: CSQC VWEP Options?

Postby toneddu2000 » Fri Apr 03, 2015 11:12 am

Ok, by 'try and catch', I'm assuming you mean 'trial and error'.
Yeah that one :D . I was seeing it from a programming side! :lol:

As I've said, I also managed to find the 'perfect angle', but it was (like yourself) through trial and error.
Cool! Glad to hear it. To be honest I don't know if there's a planned way to find the right weapon orientationon in 3d model app.

I'll try to investigate how Xonotic handled it
toneddu2000
 
Posts: 1315
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Previous

Return to CSQC Programming

Who is online

Users browsing this forum: No registered users and 1 guest