Friday, April 22, 2011
Autopilot and Stardust.
Now the autopilot works well: you select your destination with the mouse, then the autopilot aligns your ship with the target, thrust the engine until you've made an half of the voyage, and finally brake near the destination... there's something to refine but it works!
I've also added "stardust" to give more depth to the starship speed.. the dust is white for now: i've choose this colour so you can see it into the low-resolution video :). Now it looks like the old Braben's game "Frontier"
I'm thinking how to brake the ship.. using the inertial behaviour is a bit annoying: you've to align the ship to the current speed direction and brake.. if you brake too much the ship moves backward (you can see it at the end of the video), and if you do not align well you create some side movement. In one phrase: it's very difficult to stop a ship manually using an inertial engine.
So it should be less realistic but more usable a brake that doesn't changes the speed direction but his lenght. If i divide the x,y,z component of speed by i.e. 1.01, i don't need to align the ship to brake and i can make some more complex maneuvers...
Happy easter to everybody.
Monday, April 18, 2011
Time to improve (and rewrite) the autopilot.. now i can select an object using the mouse, the next step is to move my ship to the selected destination.
The autopilot is a state-machine that has a lot of step, but you can summarize it into two big "macros":
- align the ship to a selected direction
- move the ship (or stop it).
I need a function that give me the thrust power of the engine from the angle between direction and final orientation: the more distant i am, more power the engine should provide. Otherwise, when the angle is small, the engine should provide less energy.
A good solution is to use the dot product between destination vector and right/up vector. The dot product between u and v is defined like |u||v|cos(angle) where angle is angle between u and v. If u and v are unitary, the cross product give me the angle.
For yaw, the cross product between destination and right is a function that is = 0 when right is normal to direction (and it's true when direction is equal to destination..), is > 0 when direction lies left to the destination, <0 when direction lies right. Perfect for my needs!
Finally, i've to normalize for angles > 90 degrees:
if (angle > 90) { if (dotproduct > 0) dotproduct=1; else dotproduct=-1; }
For pitch is the same, but i use the up vector instead right.
The result is shown in the video.
There's some "freeze": is an issue of my laptop (i've some problem with vista and the hard disk drivers..), not of the game :)
Monday, April 11, 2011
Camera roll and mouse gesture
At least the camera control is almost finished: now you can pitch, yaw and roll, so you can do almost all movement into space.
So i've started to work to the mouse gesture: i've a GUI, and now is time to create some interaction between the mouse and the 3d world.
In this video you can see the ineractions between pointer and mesh.. when you left click in any mesh, its bounding box is displayed. Notice: when two mesh are aligned (i.e. the station and the planet) when you click on both, the engine selects the nearest.
So i've started to work to the mouse gesture: i've a GUI, and now is time to create some interaction between the mouse and the 3d world.
In this video you can see the ineractions between pointer and mesh.. when you left click in any mesh, its bounding box is displayed. Notice: when two mesh are aligned (i.e. the station and the planet) when you click on both, the engine selects the nearest.
Wednesday, March 23, 2011
A message for Yombo (but also for all who can help me)
I write here because i've no way to put all into twitter :) and because i haven't your email address.
I'll talk about my issue with quaternions.
So, i've changed a lot the code, hoping that it solves my problem but nothing changes.
Now the "lookAt" function doesn't receive a vector, but two angles: pitch and yaw. First i compute the pitch rotation (Quaternion q), then the yaw rotation (Quaternion r), and last multiply the two quaternions and rotate the camera using the result.
void MyCamera::lookAt(Ogre::Real pitch, Ogre::Real yaw) {
Quaternion q(Degree(pitch), Vector3::NEGATIVE_UNIT_X);
Quaternion r(Degree(yaw), Vector3::NEGATIVE_UNIT_Y);
q=q*r;
mCamera->rotate(q);
}
This is what happens.
in the upper-left panel now i display the "right" vector of the camera. Ok?
My questions now are: WHY!?!? What's wrong? And what is the correct way?
Thank you for the patience. I'm a noob about rotation.
I'll talk about my issue with quaternions.
So, i've changed a lot the code, hoping that it solves my problem but nothing changes.
Now the "lookAt" function doesn't receive a vector, but two angles: pitch and yaw. First i compute the pitch rotation (Quaternion q), then the yaw rotation (Quaternion r), and last multiply the two quaternions and rotate the camera using the result.
void MyCamera::lookAt(Ogre::Real pitch, Ogre::Real yaw) {
Quaternion q(Degree(pitch), Vector3::NEGATIVE_UNIT_X);
Quaternion r(Degree(yaw), Vector3::NEGATIVE_UNIT_Y);
q=q*r;
mCamera->rotate(q);
}
This is what happens.
in the upper-left panel now i display the "right" vector of the camera. Ok?
- First i rotate around Y axis (yaw), keeping pitch==0 all the time: you can see that right vector has his y coords always = 0. It's correct: the y component of right vector defines the "roll" rotation. If it's always 0, camera does not rolls.
- Next i rotate around X (pitch), keeping yaw==0 al the time. Now the right vector is = (1,0,0), always. In the video you can see not properly (1,0,0) because of the Ogre::Real resolution, but it's something like (1,0.00000001,0.00000001). And it's correct; when i pitch changes the look at, changes the up vector, but the right vector remains normal to plane YZ. Again: the y component of right vector is always = 0, so no "roll" of the camera. Perfect.
- Finally i unlock both rotation and start to combine it: the camera starts to roll, and you can see tha the y component of right vector grows... if it's > 0 camera rolls left, if it's <>
My questions now are: WHY!?!? What's wrong? And what is the correct way?
Thank you for the patience. I'm a noob about rotation.
Tuesday, March 22, 2011
Solution not found :(
Hi guys.
I've follow your suggestion about use quaternions to rotate my camera into the space and the upside/down problem that i had using the lookAt method of the Camera class, seems to be fixed
(here the previous video to show you)
Before i've used the spherical coordinates.. when you move the mouse in x direction i change the yaw angle, and when you move in y direction i change the pitch angle.
After modified the angles, i compute the unitary vector that represent the orientation of the camera:
Finally i use the "lookAt" method to orientate the camera along the "direction" Vector3.
But the side effect is that, when pitch angle go outside the interval (0,PI), the camera flips upside down.
So, i've changed the approach.. no more lookAt but quaternions.
And this is the result:
i've changed the starship mesh with a more clear xyz axis mesh: x is in red, y in green and z in blue.
First i try to do a yaw rotation, around the Y axis... it works fine.
Then pitch rotation and.. well! it works! no more upside-down.
But.. when i combine both and give freedom to camera move something strange happens: moving it cause a side effect: some roll rotations starts to appears and the more i rotate clockwise my mouse, the more the roll appears... and rotating the mouse in other direction changes the roll direction too..
Why??
And how can i remove it?
I've follow your suggestion about use quaternions to rotate my camera into the space and the upside/down problem that i had using the lookAt method of the Camera class, seems to be fixed
(here the previous video to show you)
Before i've used the spherical coordinates.. when you move the mouse in x direction i change the yaw angle, and when you move in y direction i change the pitch angle.
After modified the angles, i compute the unitary vector that represent the orientation of the camera:
direction.x=sin(yaw)*sin(pitch);
direction.y=cos(pitch);
direction.z=sin(pitch)*cos(yaw);
Finally i use the "lookAt" method to orientate the camera along the "direction" Vector3.
But the side effect is that, when pitch angle go outside the interval (0,PI), the camera flips upside down.
So, i've changed the approach.. no more lookAt but quaternions.
void MyCamera::lookAt(Vector3* dir) {
//no more used
//mCamera->lookAt(dir->x,dir->y,dir->z);
Vector3 src = mCamera->getDerivedOrientation() * Vector3::NEGATIVE_UNIT_Z; // Orientation from initial direction. Camera points to (0,0,-1)
Quaternion quat = src.getRotationTo(*dir);
mCamera->rotate(quat);
}
And this is the result:
i've changed the starship mesh with a more clear xyz axis mesh: x is in red, y in green and z in blue.
First i try to do a yaw rotation, around the Y axis... it works fine.
Then pitch rotation and.. well! it works! no more upside-down.
But.. when i combine both and give freedom to camera move something strange happens: moving it cause a side effect: some roll rotations starts to appears and the more i rotate clockwise my mouse, the more the roll appears... and rotating the mouse in other direction changes the roll direction too..
Why??
And how can i remove it?
Monday, March 21, 2011
Saturday, March 19, 2011
I need a little help.
I'm just stucked inside a small but annoying issue and i'm tired and unable to find an elegant solution.
So i'll post here my problem to see if there's someone could help me..
I'm working on orientation of our spaceship.
The ship has two vector (Vector3): the position and the orientation. The first is the position of the ship in space, the second should be a unitary vector that represent the "lookAt" orientation (in local coordinates).
If you're sitted on the cockpit, this represent the direction you're looking to.
To implement this i've used the spherical coords, so, to obtain the vector:
orientation.x=sin(fi)*sin(theta);
orientation.y=cos(theta);
orientation.z=sin(theta)*cos(fi);
where fi is the yaw angle, and theta is the pitch angle.
It works fine for yaw, but.. for pitch, when the angles become less below zero or greather than PI, the screens flips! (look at 0:17)
I think that the issue should be that when theta is outside (0,PI), sin(theta) is <0, and both x and z become negative, and in some ways it invert the up-right vectors.
You can see it into the video: on the upper-left panel there's the ship position and ship orientation (you should use 720p resolution to see the numbers)
For now i've limited the rotation from 0 to PI but it's ugly.. i'd like to pitch and yaw without restricts, i'd like to make loops with my ship without this glitch.
Any idea?
Thank you.
So i'll post here my problem to see if there's someone could help me..
I'm working on orientation of our spaceship.
The ship has two vector (Vector3): the position and the orientation. The first is the position of the ship in space, the second should be a unitary vector that represent the "lookAt" orientation (in local coordinates).
If you're sitted on the cockpit, this represent the direction you're looking to.
To implement this i've used the spherical coords, so, to obtain the vector:
orientation.x=sin(fi)*sin(theta);
orientation.y=cos(theta);
orientation.z=sin(theta)*cos(fi);
where fi is the yaw angle, and theta is the pitch angle.
It works fine for yaw, but.. for pitch, when the angles become less below zero or greather than PI, the screens flips! (look at 0:17)
I think that the issue should be that when theta is outside (0,PI), sin(theta) is <0, and both x and z become negative, and in some ways it invert the up-right vectors.
You can see it into the video: on the upper-left panel there's the ship position and ship orientation (you should use 720p resolution to see the numbers)
For now i've limited the rotation from 0 to PI but it's ugly.. i'd like to pitch and yaw without restricts, i'd like to make loops with my ship without this glitch.
Any idea?
Thank you.
Subscribe to:
Posts (Atom)