Players using quaternions
by Daniel Buckmaster · in Torque Game Engine · 01/18/2009 (5:16 am) · 6 replies
I'm going to post this up here until resources are figured out. And to see if anybody has any good input before the final version is written up. ;)
Okay, resources seem to be semi-working again. Here it is.
www.garagegames.com/community/blogs/view/16149
Okay, resources seem to be semi-working again. Here it is.
www.garagegames.com/community/blogs/view/16149
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
01/18/2009 (5:21 am)
I said never.
#3
01/18/2009 (5:25 am)
This is the last time...
#4
And stepping may be an issue however. It works off the height (along the z axis) of the object you are running into.
I just finished implementing it, it compiles fine, and the findContact's clearly work great, as when I rotate myself to an angle I can run on walls as if they were the floor, and the opposite with the floor. But 1 problem, have you tried jumping with this, because I can't.
01/18/2009 (10:19 am)
Wow, great work Daniel, I'll work on implementing this right away and seeing if I can network test it.And stepping may be an issue however. It works off the height (along the z axis) of the object you are running into.
Quote:polyList.setInterestNormal(Point3F(0.0f, 0.0f, -1.0f));What setInterestNormal does is allow another way too "early-out" of collision detection for certain faces. When we call the setInterestNormal function, it sets the interest normal to the provided Point3F vector provided. It also sets a boolean mInterestNormalRegistered to 'true'. When the AbstractPolyList calls isInterestedInPlane(const PlaneF &plane) it returns true if the plane is facing the interest normal, or if mInterestNormalRegistered is false, all planes will return true. However, as to when this is used, I have no idea... I searched the project and can't find calls to it anywhere...
I don't know exactly what that means, but it looks like hardcoding. Change it to use our own up vector:
I just finished implementing it, it compiles fine, and the findContact's clearly work great, as when I rotate myself to an angle I can run on walls as if they were the floor, and the opposite with the floor. But 1 problem, have you tried jumping with this, because I can't.
#5
Thanks for that explanation. Seems like I was right to change it.
In my current project, jumping is working (see the video I added to the resource, in the last clip). I'll go back and check to make sure I haven't omitted something. Have you stepped through findContact to see what's going on with the normals and such?
EDIT. I've just made some changes to get the Player to rotate back to vertical. They seem to work, but I'm having odd problems. First, here's the code. I stuck it in updateMove.
Second, it's incredibly jerky, and I can't tell why. Interpolation seems to be working for normal z-axis rotation, just not here. I'd appreciate it if someone who actually knows what they're doing would critique my interpolation code :P
EDIT. And, just to dump some more of my woes into the internet, getAIMove is driving me up the wall. When I step through the code, everything seems rosy, but it doesn't actually make Kork do anything useful. :P
01/25/2009 (3:49 am)
Sorry, I didn't notice all that. Did you edit after posting? :PThanks for that explanation. Seems like I was right to change it.
In my current project, jumping is working (see the video I added to the resource, in the last clip). I'll go back and check to make sure I haven't omitted something. Have you stepped through findContact to see what's going on with the normals and such?
EDIT. I've just made some changes to get the Player to rotate back to vertical. They seem to work, but I'm having odd problems. First, here's the code. I stuck it in updateMove.
//Update our non-vertical orientation, including conforming
Point3F wvert(0.0f,0.0f,1.0f);
Point3F vert;
mOrient.mulP(wvert,&vert);
Point3F diff = vert - wvert;
if(diff.lenSquared() > 0.00001)
{
F32 ang = mDot(vert,wvert);
Point3F axis;
if(mFabs(vert.z) < 1.0f)
axis = mCross(wvert,vert);
else
{
Point3F forw(0.0f,1.0f,0.0f);
mOrient.mulP(forw,&forw);
axis = mCross(wvert,forw);
}
QuatF rot(AngAxisF(axis,getMin(ang,TickSec)));
mOrient *= rot;
mOrient.normalize();
}First, it I don't normalize mOrient at the end, I get really, really wierd stuff going on when the player is facing opposite world-North. The entire world apart from Kork appears to be wobbling around (stretching and skewing). If I go to free camera, everything is fine, but Kork is doing the wobbling. This suggests that during my rotation maths, mOrient is getting un-normalised. How?Second, it's incredibly jerky, and I can't tell why. Interpolation seems to be working for normal z-axis rotation, just not here. I'd appreciate it if someone who actually knows what they're doing would critique my interpolation code :P
EDIT. And, just to dump some more of my woes into the internet, getAIMove is driving me up the wall. When I step through the code, everything seems rosy, but it doesn't actually make Kork do anything useful. :P
#6
01/28/2009 (11:44 am)
Fixed the second problem. The problem was that the client wasn't predicting its own orientation, or something like that - updateMove was a silly place to put that code, since it doesn't deal with the passed move. I stuck it in processTick and the jittering went away. Now I've gotta figure out why my quternions are getting denormalised... and fix that blasted AI movement!
Torque Owner Daniel Buckmaster
T3D Steering Committee