Very interesting thread... unfortunately I've been away from work (moving
house) so I've come to this a little late. Hope no-one minds me putting
in my
two-penn'orth ...
[quick note on my background - I'm currently working as lead programmer
on a PC game called 'Halcyon Sun' which is due for release next month, so I've
tackled all of the problems mentioned here quite extensively].
> "Bell, Brian K" wrote:
> I considered this for a while.
These are known as the six degrees of freedom. They can be stored as a 4x3
matrix with the top three rows of the matrix representing the orientation
(rotations) and the bottom row is the (x y z) position vector. If the matrix
is normalised then it has several useful side effects that can speed up
calculations.
> Each ship would have a 360x,360y,Velocity course.
An alternative way of storing this is as an [x y z] velocity vector. Current
velocity is equal to the length of the vector (eg sqrt (x*x + y*y +
z*z)).
Changes in course are calculated by vector arithmetic - simply add the
new thrust vector to the existing velocity vector to derive the new overall
velocity vector.
My math skills must be lacking or I misunderstood your post
How does sqrt(x*x+y*y+z*z) give you a vector?
Unless you meant sqrt(x1*x2+y1*y2+z1*z2) where x1,y1,z1 represents the
starting point of your last move and x2,y2,z2 represents the end point of your
last move (x1 should be x sub 1, and x2 should be x sub 2, etc. but plain text
is limiting).
If sqrt(x1*x2+y1*y2+z1*z2) is what you meant, then you still have to
maintain 3 variables previous x, y, & z (instead of 360x,360y,Velocity).
Either way you can generate the current course. But you are correct about just
having to add the new vector to get the new course with
sqrt(x1*x2+y1*y2+z1*z2).
-----
Brian Bell bkb@beol.net
-----
> -----Original Message-----
[snip].
> "Bell, Brian K" wrote:
[snip]
> >
> "Bell, Brian K" wrote:
> My math skills must be lacking or I misunderstood your post
Don't worry, it's me, I've not been clear enough. The velocity vector of the
ship is stored as the vector [x y z] which represents the distance the ship
moves in one second. The length of this vector is then equal to the above
formula, which is also the velocity of this ship.
> Unless you meant sqrt(x1*x2+y1*y2+z1*z2) where x1,y1,z1 represents the
but
> plain text is limiting).
In fact you only need store [180x 360y Vely].
I agree about storage of the same number of variables, but the maths is much
simpler if the course is stored as a vector.
[Example]
The VKK Lenin is flying through space at a constant 100m/s and applies a
right push using its manouevering thrusters. Under your system we'd store the
course as (say) [0.0deg, 45.0deg, 100.0]. Under my system we'd store [70.71,
0.0,
70.71]. The push is equivalent to a 10m/s push to the right - under your
system
this would be [0.0deg, 135.0deg, 10.0], under mine [7.07, 0.0, -7.07].
To derive the final velocity under my system you simply add the vectors
together to get [77.78, 0.0, 63.64]. Under yours... errr, I'll let you work it
out (any solution I derive would involve converting your course format into a
vector, calculating the sum and converting it back again). The answer is
[0.0deg,
50.71deg, 100.49] (I think - it's Monday and I've just done this on a
scrap of paper).
[Quick list of assumptions for anyone who wants to try this for
themselves. I
work in a universe with left-hand rule axes, eg +ve X is right, +ve Y is
up, +ve
Z is forward. I've assumed instantaneous application of the push vector, eg no
acceleration / momentum problems. Under Brian's system I've taken X
rotation to be pitch and Y rotation to be azimuth which corresponds with the
left hand rule axes.]
[/Example]
An additional problem with your system that's just occurred to me is one of
ambiguity. A course of [90deg 0deg 100] actually gives the same result as one
of
[90deg 90deg 100], or in fact [90deg ANYdeg 100]. This may or may not be
a problem depending on what you want to do with the course.
It should not. I probably have not made myself clear.
My system would store 360 degrees of yaw, 360 degrees of ascent/descent
(OK,
180 is enough) and Velocity. This combination produces a three dimensional
"direction" and distance.
Course is determined from current location using yaw and ascent/descent
for a distance of Velocity. I don't understand the ambiguity. If a course is
90 by 0 (same plane) moving 100, you would end up a different place than a
course of 90 by 90 ascent moving 100 or course of 90 by 90 descent (-90)
moving 100. You are correct, however if you mean that 360,360,V could come up
with some nonsensical figures, so I amend it to 360yaw,
+90/-90ascent,
velocity
And you are correct, that you would need to convert my system into vector to
get the new position of the ship. Under your system, you would need to convert
the orders into vector, create the new vector, and then convert the vector
back in to course headings to provide the player the information. Both sides
require conversion, the question is just where. Unless you are going to
provide the player with the beginning and ending coordinates and let him
figure it out for himself.
The advantage of my system (I think) is that it will be easier for the player
to determine where the ship will end up if the orientation of the ship and the
course are presented in the same fashion.
In other words if the player is presented with a ship that has: Location: 30,
60, 100 (x, y, z)
Orientation: 220, -60, 30 (yaw, ascent, roll)
Course: 130, 5, 20 (yaw, ascent, velocity) Note: Yaw, Ascent, and roll are
defined from galactic norm, not from the view of the ship)
Rather than: Location: 30, 60, 100 (x, y, z) Previous Location: 40, 80, 90 (x,
y, z)
Orientation: 220, -60, 30 (yaw, ascent, roll)
Note: The two examples do not match. I did not do the math
I think that my version would make it easier to see that yaw is 95 degrees and
ascent is 48 degrees off from coups than from the other version.
Also, as a player, I would not want to have to calculate my orders into
3-D
vector before providing them. This should be done by the program. It makes my
head hurt to try to figure out how to order a ship to push port 1 (using
current orientation), roll to 30 degrees, yaw to120 degrees, change ascent to
60 degrees and burn 4 (MD 6 ship).
If you convert, again, then it is just a mater of when you convert.
If you are playing real-time and the graphics can present course,
location, and orientation, then providing the numbers is less a factor. If you
are playing a turn based game or the graphics cannot provide the information
visually (such as FTMAP), then you need to provide the information to the
player on location, orientation, course and velocity.
I will concede that your method may be superior for calculation of movement,
but not for providing information to the player or accepting orders from the
player. Either system will need to convert information from course and
velocity to vector and back. Which you store and when you convert is a mater
of preference.
Anyway thanks for pointing out the 360-360 problem.
-----
Brian Bell bkb@beol.net
-----
> -----Original Message-----
[snip]
In fact you only need store [180x 360y Vely].
[snip]
To derive the final velocity under my system you simply add the vectors
together to get [77.78, 0.0, 63.64]. Under yours... errr, I'll let you work it
out (any solution I derive would involve converting your course format into a
vector, calculating the sum and converting it back again). The answer is
[0.0deg,
50.71deg, 100.49] (I think - it's Monday and I've just done this on a
scrap of paper).
[snip]
> An additional problem with your system that's just occurred to me is