Look animation/weapon model alignment

#1 Is that a custom model?

Also, have you modified how the animations are setup and/or blended?

The arm animation thread and the head animation thread are normally tied together via blended animations, and coordinated via Player::UpdateAnimationTree(), which accesses the spine nodes directly in source.

#2 The character model (the hands that you see) is the Tridinaut soldier pack.

All I did was to turn off the Eyeoffset of the weapon, so that it was not displaced anymore and in the hands of the playermodel. Then I raised the arms so that they would align with the camera and give the typical FPS view with hands/model that we see alot in todays games.

What's so much of a clue to me is that it looks perfect from an outside view. The head does look up, so does the weapon and the arms are correct too. But from the camera it looks like above.

#3 May I ask, what values are you using either side of 'Root' pose as lookUP/lookDOWN?? I recently did a new pistol holding pose utilizing the default SDK player rig. Figuring it to be a full 90 degree up/down; I used a ~45 degrees up value for the neck/clavicles value and only around ~25 degree down value for the lower view[full 45 would put the arms inside the torso, ala the landing sequence, ;)]. Once inside the engine, using the default look* mouse input [up/down : pitch/yaw] the .dsq sequence I created put my hands and weapon nearly the entire 'sweep' of the motion in the players' HUD. When 'lowering' my gaze the animation/arms stopped where I ended the sequence in the modeling program; while the Node in question[which?!? is doing the animating] eye/cam, continues the 'sweep' until code default kicks in and the 'view' stops. It 'seems' all I need to do to keep the hands/weapons in the player's HUD view the entire time, is to figure out what the engine is using for values either side of 'Root', and go back and 'refine' my keyframes....but the point is that, I get the hands/weapons within the viewport nearly the entire animation sequence...so perhaps reworking the sequence? Or determining what the engine is using as it Head movements....that I do not know. I bet it's in a weird non-artsy unit of measurement [radians?] or some other such math construct. Somewhere, in some script, the values must be stored for the cam/eye??

It seems odd that the hands/weapon isn't in the UP look....here's my 'Root' look:

#4 Thanks for the lenghty post Rex, but I'm not sure I understand what you're saying.
Are you too, like Stephen, hinting that this might be needing a code change?

I was under the impression that I could do this solely in the animations, but maybe I was wrong.

#5 Actually I was trying to isolate the issue by determining if you had a custom model that might have changed some of the base nodes that the blending normally relies upon.

From what you've mentioned, it sounds as if you simply need to make some translations/stretches of the animations to do what you want. It -may- require some code changes as well, since this obviously isn't a standard functionality.

#6 Ah yeah the nodes are all intact, from the soldiermodel. I just touched the Eyeoffset.

I'll see if I can find a solution.

#7 Please post your findings Stephen, I have to tackle the same issue. Unfortunately I don't have Max or maya to tweak the animations of the Soldier pack, so I was going to try a code solution.

#8 I've been testing a little this morning and found that perhaps it may be a bit of both[script/sequence].

What I observed is this:

1. The player's minLookAngle & maxLookAngle are set to 1.4[-/+] by default. I would assume these values to be in radians...

2. My look sequence I produced has an up rotation of about 45 degrees and it[weapon&hands] just slips out of view when looking in the extreme up position[with default code].

3. My look sequence I produced has a down rotation of about 25 degrees[to exclude the body clipping by arms] and the Head & Eye Nodes continue to rotate past the end of the sequence.

4. When I edited the min/maxLook values to less than 1.0[-/+], the engine seems to hang with lighting...??no big deal. NOTE: checking log indicates the less than 1.0 value to take the PlayerBody datablock out of recognition...log has error about not being in 'GameBaseData'......missions light, but no player with it's CAM node to view the rendered Scene??

5. When I edited the min/maxLook values to just 1.0[-/+] and made no correction to the sequence; the engine ran and I was deposited in a mission. When I looked UP, I now see the weapon/hands just a bit, and when I lower my gaze with the playerClass avatar; the view and sequence now stop at the same time....

...leading me to believe that a combination of sequence refinement and script changing may be needed to put the objects in question, where intended, within the player's FOV.

David

...and it wouldn't surprise me to learn that if you match the sequence values to the script values...you might always get the weapon/hands in the FOV....my next test is to refine the look* sequence I produced to match the Head.dsq values...

#9 Wow Rex, nice writeup. I'll go the same route and see if I can come up with anything. Will post.

#10

Quote:
...and it wouldn't surprise me to learn that if you match the sequence values to the script values...you might always get the weapon/hands in the FOV....my next test is to refine the look* sequence I produced to match the Head.dsq values...

It can't be that easy. I changed scripts to accomondate for the lookdown/lookup animation and it still plays just like before. Also, why is the eye node animated (rotated) in the head sequence? Isn't the camera/eye controlled by code?

#11 Stefan have you tried with the orc or greenguy , it must be something strange with the model animation.

#12 Yup it's the same with all of them. Billy, the weapon is not default Torque.. it won't work with them. EyeOffset is not set.

#13 Not sure about the Cam/Eye being controlled by code and what that entails; I 'thought' the code forced the animation to play with the mouse input and the constraints would be at 80.25 degrees??!! Anyone....! It would be great to see some sort of whitepaper on how this default system of 3/1st person & Eye/Cam Nodes interact. I understand Threads a bit now and am able to blend, but I have tons of questions about the general state of the Threads and NLA interaction and how many sequences you can 'stack' per thread[isn't that what blends do? lay a new animation ontop of one running dequence in a single Thread[actionThread and armThread sequences all on Thread0, say for example or is each on a separate Thread??]

I'm assigned, right now, to NOT jizzling the script values around...I want to see what happens with default settings of 1.4[-/+] and tweeking my sequence to see how they react to default code. I added 10 degrees rotation for each direction and now I see most of my pistol in the UP-extreme of "look" and now my DOWN-extreme view and the animation stop together. Things are getting closer. I'm wondering if I need to match my sequences to the script values of like 80 degrees each side of 'zero'.... I've got my handy Radians2Degrees and Degrees2Radians conversions figured and that's what 1.4 radians equals right? 80.25 degrees?

Yep. With no edit to script min/maxLook values and redoing my look animation sequence in my modeling program yields a weapon fully following the players' view UP & DOWN. Albeit, there is a little discrepency between each sequence end, but I'm sure with some back/forth, it will come out squarely in the view. Now, I'm noticing a little 'parallex' view happening with the up/down. My animation sequence is virtually straight up/down in front of the EYE node....when played back in the engine, there is a little diagnal right/left of the crosshair[default]. This also has me questioning again how the first/third views differ. For example; when in FirstPerson Perspective view and in the root sequence holding this pistol, my player's view is straight forward of the body. And then when I begin and continue to run, everything[arms/weapon/view] is still 'straight' forward and doesn't alter when toggling between run/root or root/run. Now, when I view the player from Third Person Perspective; I see the arms/weapon go from pointing 'straight' ahead to actually down and to the left of 'straight' ahead?!? That seems like a big 'sweep' between perspectives. I don't see this in First Person?? Not complaining mind you, just trying to understand the relationship between 1st/3rd and the sequences...seems when you enter the cam node for a camera view, the player shifts to a pose a little off, might be imaging that...but sure seems that way?

#14 That's what I've been doing too. Not touching the script for a while and just fiddling with the look animation.

#15 Try tweeking the pose to around an 80 degrees up/down from root and see how close that gets to the default min/maxLook....of 1.4[-/+]. And then take a look at the player_head.dsq that accompanies the pack...I think that's where you'll find what might be up with the eye. Seems to me matching the script comes closest to the intended look. eh, someone who knows, should whack me with a mackeral about the head and tell me I'm wrong...;), with corrections!

Here's UP image:I'm fortunate: I only had to animate the Clavicle bones after I established my pistol grip to accomplish my player_lookpk.dsq[my pistol weapon] to get up/down...and as a pistol, it was posed to the eye node for realism...

End note of the day: I spent the afternoon goofing with this and I finished with a player_look*.dsq that kept the weapon in the view the entire UP/DOWN action. My sequence did indeed need to be near the radian values inside the script and then I refined the animation[only a few degrees off 80 each way~7-10 tops] on each end and got very much what I intended inside the engine. At each end of the look, my weapon muzzle lines up with the crosshair in the Z vector, it's still offset in X at either end and that could probably be fixed with more tweeking....but I conclude it's within the animation of the look sequence and the head sequence and your codeBase[whatever min/maxLook values you're using]...good luck. Let us know how you're doing with this...I'm always curious about TGE's Animation schema...;).

#16 So it IS the head animation too? Geez, I hate touching that one, makes no sense to me.

Thanks, I'll post correction screenshots if your procedure helps (:

#17 I'm not saying to change the player_head.dsq; just look at that sequence to see what the eye Node is doing, if anything; as you seem to be using a Pack with custom animations. I didn't have to redo that sequence at all, it was left untouched, I merely refined my look sequence back/forth. And come to think of it, my starting root values put the weapon a bit low to the Z of the crosshair and might explain why my accurate 80 degrees was a tiny bit off...my orignal proofing was for either end, not my start. The player_head.dsq is where I got the idea of examining what Nodes were rotating and what values they were. I looked thru all the sequences with the Sequence dialog, noting which ones had the Eye node rotating... The Eye node seemed to move up ~50 degrees and down ~30, those left me way shy of being centered on the crosshair, but when I looked for another rotation source of data; I started looking at the min/maxLook values of the script and attempted to match those with my sequence.

It's my understanding that, when you move the mouse input up/down; it is running the player_look.dsq and the player_head.dsq concurrently and the reason for splitting the action is to perhaps allow the head to move independently of arms.... I'm not sure if the code uses the rotation or just the eye's position for viewing. My unsuccessful 50/30 values may prove that...the only pertinent data is position, not transform of the Eye.