Help: CSQC VWEP Options?
Re: Help: CSQC VWEP Options?
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.
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.
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: Help: CSQC VWEP Options?
Great description Spike, very detailed, thanks a lot.
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?
Code: Select all
setorigin(wep,gettaginfo(self, gettagindex(self,"hand.r")));
wep.angles = vectoangles(v_up, v_forward);
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?
Meadow Fun!! - my first commercial game, made with FTEQW game engine
Re: Help: CSQC VWEP Options?
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.
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.
-
- Posts: 247
- Joined: Sat Feb 28, 2009 2:38 pm
- Contact:
Re: Help: CSQC VWEP Options?
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](https://farm8.staticflickr.com/7284/16941226972_9d0f148c07.jpg)
![Image](https://farm9.staticflickr.com/8689/16735201447_55b5b482cf.jpg)
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](https://farm8.staticflickr.com/7284/16941226972_9d0f148c07.jpg)
![Image](https://farm9.staticflickr.com/8689/16735201447_55b5b482cf.jpg)
Last edited by OneManClan on Mon Mar 30, 2015 1:01 pm, edited 5 times in total.
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: Help: CSQC VWEP Options?
Thanks a lot Spike, huge piece of document, really appreciated.
EDIT: sorry onemanclan: when I was posting, your post came first and I didn't see it!
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.
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?
Yeah, during my roaming on fteextension I saw it but I couldn't understand it, now I can!:)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).
EDIT: sorry onemanclan: when I was posting, your post came first and I didn't see it!
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!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?
![Big Grin :D](./images/smilies/icon_biggrin.gif)
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);
Meadow Fun!! - my first commercial game, made with FTEQW game engine
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: Help: CSQC VWEP Options?
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](http://s21.postimg.org/p7e1apakj/weapon_bone.jpg)
![Image](http://s1.postimg.org/5n7n0ffnf/correct_orientation.jpg)
![Image](http://s1.postimg.org/zdurm70mz/weapon.jpg)
I use in Blender Numpad 3 as front view and Numpad 1 as side view (inverted) so it's oriented correctly in game
![Image](http://s21.postimg.org/p7e1apakj/weapon_bone.jpg)
![Image](http://s1.postimg.org/5n7n0ffnf/correct_orientation.jpg)
![Image](http://s1.postimg.org/zdurm70mz/weapon.jpg)
Meadow Fun!! - my first commercial game, made with FTEQW game engine
-
- Posts: 247
- Joined: Sat Feb 28, 2009 2:38 pm
- Contact:
Re: Help: CSQC VWEP Options?
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.
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.
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: Help: CSQC VWEP Options?
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: 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:
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 ZOneManClan wrote: B: How to modify the self.angles code to incorporate/compensate for/translate the different angles settings in Blender, or:
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.OneManClan wrote: C: How to rotate the (hand) bone in the original model .. to (somehow) make it 'consistent' with how the VWEP gets exported (?)
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!
![Big Grin :D](./images/smilies/icon_biggrin.gif)
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
Meadow Fun!! - my first commercial game, made with FTEQW game engine
-
- Posts: 247
- Joined: Sat Feb 28, 2009 2:38 pm
- Contact:
Re: Help: CSQC VWEP Options?
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: Then I found that the correct angle was diagonal, pointing towards hand.
Not sure what you mean by 'when arm rotates'. You mean the VWEP moves correctly when the player shoots? :?toneddu2000 wrote: The weapon now stands correctly in arm and rotates when arm rotates. Perfect.
In any case, reading your post, I'm left wondering: how did you 'find' the correct angle'?
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: Help: CSQC VWEP Options?
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.Ok, what do you mean when you say you 'found' that the correct angle was diagonal?
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).Not sure what you mean by 'when arm rotates'. You mean the VWEP moves correctly when the player shoots? :?
See me first statementIn any case, reading your post, I'm left wondering: how did you 'find' the correct angle'?
It's almost good but it would be better 'scusami', it's less formal!Maybe it's a language issue (mi scusi)
![Laughing :lol:](./images/smilies/icon_laughing.gif)
Meadow Fun!! - my first commercial game, made with FTEQW game engine
-
- Posts: 247
- Joined: Sat Feb 28, 2009 2:38 pm
- Contact:
Re: Help: CSQC VWEP Options?
Ok, by 'try and catch', I'm assuming you mean 'trial and error'.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, 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.toneddu2000 wrote: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).Not sure what you mean by 'when arm rotates'. You mean the VWEP moves correctly when the player shoots? :?
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: Help: CSQC VWEP Options?
Yeah that oneOk, by 'try and catch', I'm assuming you mean 'trial and error'.
![Big Grin :D](./images/smilies/icon_biggrin.gif)
![Laughing :lol:](./images/smilies/icon_laughing.gif)
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.As I've said, I also managed to find the 'perfect angle', but it was (like yourself) through trial and error.
I'll try to investigate how Xonotic handled it
Meadow Fun!! - my first commercial game, made with FTEQW game engine
-
- Posts: 247
- Joined: Sat Feb 28, 2009 2:38 pm
- Contact:
Re: Help: CSQC VWEP Options?
Hi all.
Ok, after 4 years(!), I thought I'd revisit this topic, and (thanks to Spike), finally have a step-by-step method for:
'VWEP (with bone) connects to Player's Hand-bone'
1. Make the vwep in Blender
2. Give it a bone, call it "grip"
3. If its a gun, orient the bone so that it goes along the vwep's barrel; if it's a knife, orient the bone so that it goes across the grip (ie the angle your index finger would be, while holding the knife)
4. Make sure the player model has a hand bone, preferably aligned with their index finger (roughly)
5.
your comments/feedback welcome!
FAQ/ Notes for a potential confused future me
Q1: "The VWEPs position/angles don't match the player"
A: If everything worked, but it doesn't "look right", you have 2 options:
A: Step through the code (above) to make sure the values are being extracted from the iqms. If they aren't:
Did you export the blender model w the right size? ie maybe the iqm is there, but *tiny* (yes this happened, and I wasted an hour on this). Either 'upsize' your model in Blender, or do it during export.
Ok, after 4 years(!), I thought I'd revisit this topic, and (thanks to Spike), finally have a step-by-step method for:
'VWEP (with bone) connects to Player's Hand-bone'
1. Make the vwep in Blender
2. Give it a bone, call it "grip"
3. If its a gun, orient the bone so that it goes along the vwep's barrel; if it's a knife, orient the bone so that it goes across the grip (ie the angle your index finger would be, while holding the knife)
4. Make sure the player model has a hand bone, preferably aligned with their index finger (roughly)
5.
Code: Select all
// Condensed/Guru version
skel_set_bone_world(the_vwep, gettagindex (the_vwep, "grip"), gettaginfo(the_player, gettagindex (the_player, "hand_R")));
Code: Select all
// Expanded/OMC version
string vwep_grip_bone_name = "grip";
string player_hand_bone_name = "hand_R"; // or the name of your specific bone for VWEPS
float vwep_gripbone_number = gettagindex (the_vwep, vwep_grip_bone_name);
float player_hand_bone_num = gettagindex (the_player, player_hand_bone_name);
vector player_hand_bone_origin = gettaginfo(the_player, player_hand_bone_num);
skel_set_bone_world(the_vwep, vwep_gripbone_number, player_hand_bone_origin);
FAQ/ Notes for a potential confused future me
Q1: "The VWEPs position/angles don't match the player"
A: If everything worked, but it doesn't "look right", you have 2 options:
- 1. Edit the players handbones position/angle (consider aditing player's animations while you're at it)
2. Make a new bone for the players hand, just for VWEPS.
A: Step through the code (above) to make sure the values are being extracted from the iqms. If they aren't:
- Is the skeleton being created?
Have you named the bones properly?
Are you accessing the right entity ( check 'self')
Did you export the blender model w the right size? ie maybe the iqm is there, but *tiny* (yes this happened, and I wasted an hour on this). Either 'upsize' your model in Blender, or do it during export.
Re: Help: CSQC VWEP Options?
That's awesome! It works perfectly, OneManClan. ![Twisted Evil :twisted:](./images/smilies/icon_twisted.gif)
![Twisted Evil :twisted:](./images/smilies/icon_twisted.gif)
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: Help: CSQC VWEP Options?
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
in this case, the wrist will rotate, the knife will be stick to the hand bone, but not orienting as hand bone axis
Meadow Fun!! - my first commercial game, made with FTEQW game engine