I don't know if this is a bug or not.
When one specifies
FixedRotation {} (with no arguments)
one of the object's axes points in the opposite direction from the direction that axis points when one specifies
ScriptedRotation {...} (specifying Module and Function)
which returns a quaternion of [1,0,0,0]
Is this to be expected?
An Addon to demonstrate this is available at
http://www.lepp.cornell.edu/~seb/celest ... ripted.zip (200KB)
FixedRotation vs ScriptedRotation orientation problem
-
Topic authorselden
- Developer
- Posts: 10192
- Joined: 04.09.2002
- With us: 22 years 2 months
- Location: NY, USA
Further investigation reveals that specifying a 180 degree rotation around the Y axis in the ScriptedRotation produces the same orientation as a FixedRotation with no arguments:
Specifically:
v = celestia:newvector( 0, 1, 0)
q = celestia:newrotation(v, math.rad(180))
return q.w, q.x, q.y, q.z
This produces the quaternion values
[0 0 1 0]
This difference in coordinate system orientation has caused me quite a bit of confusion
Specifically:
v = celestia:newvector( 0, 1, 0)
q = celestia:newrotation(v, math.rad(180))
return q.w, q.x, q.y, q.z
This produces the quaternion values
[0 0 1 0]
This difference in coordinate system orientation has caused me quite a bit of confusion
Selden
-
Topic authorselden
- Developer
- Posts: 10192
- Joined: 04.09.2002
- With us: 22 years 2 months
- Location: NY, USA
I've discovered another discrepancy, this time between Lua getposition values and the positions specified in xyz trajectories: they're rotated 90 degrees around the X axis with respect to one another.
These differences in coordinate systems are extremely frustrating. They all really should be the same.
Here's a concrete example: if you Select a body that's following an xyz trajectory, and write a loop in Lua which calls getposition at intervals while the body travels along the trajectory, a file containing the resulting times and (supposedly universal) x,y,z locations should be usable to create an xyz trajectory which follows the same path in space as the original trajectory file.
The paths are not the same.
If the original xyz trajectory defines a path in the ecliptic plane, the new xyz trajectory file containing Lua getposition values defines a path which is perpendicular to the ecliptic.
*grump*
These differences in coordinate systems are extremely frustrating. They all really should be the same.
Here's a concrete example: if you Select a body that's following an xyz trajectory, and write a loop in Lua which calls getposition at intervals while the body travels along the trajectory, a file containing the resulting times and (supposedly universal) x,y,z locations should be usable to create an xyz trajectory which follows the same path in space as the original trajectory file.
The paths are not the same.
If the original xyz trajectory defines a path in the ecliptic plane, the new xyz trajectory file containing Lua getposition values defines a path which is perpendicular to the ecliptic.
*grump*
Selden
Selden,
there is a difference between internal Celestia reference frame and the most common reference frame J2000. As you discovered, it's a rotation about x axis.
To be compliant with J2000, a rotation is applyed to all data read in .q files (see here, lines 56 and 123).
On the other hand, when you specify an orientation with a Lua script, you are working in Celestia internal reference frame, so you have to apply yourself this correction rotation.
If you are working with quaternions, this Lua function do it for you !
Mathieu (spacebel)
there is a difference between internal Celestia reference frame and the most common reference frame J2000. As you discovered, it's a rotation about x axis.
To be compliant with J2000, a rotation is applyed to all data read in .q files (see here, lines 56 and 123).
On the other hand, when you specify an orientation with a Lua script, you are working in Celestia internal reference frame, so you have to apply yourself this correction rotation.
If you are working with quaternions, this Lua function do it for you !
Mathieu (spacebel)
Code: Select all
function rInertiel2rCelestia( q )
local racine = math.sqrt( 2 ) / 2 ;
local qCel = {} ;
-- Rotation de 90 selon x
qCel.w = - q.w * racine - q.x * racine
qCel.x = - q.w * racine + q.x * racine
qCel.y = q.z * racine + q.y * racine
qCel.z = q.z * racine - q.y * racine
return qCel
end
-
Topic authorselden
- Developer
- Posts: 10192
- Joined: 04.09.2002
- With us: 22 years 2 months
- Location: NY, USA
mjoubert,
Thanks!
However, I do think it would be very helpful if functions could be provided as part of Celestia's Lua library to perform the appropriate transformations. The frame-based transformation routines
position2 = frame:to(position1, t)
rotation2 = frame:to(rotation1, t)
position1 = frame:from(position2, t)
and
rotation1 = frame:from(rotation2, t)
cannot currently be used because
frame=observer:getframe()
only works for observers and not for objects
even though
getposition and setposition work for both.
Thanks!
However, I do think it would be very helpful if functions could be provided as part of Celestia's Lua library to perform the appropriate transformations. The frame-based transformation routines
position2 = frame:to(position1, t)
rotation2 = frame:to(rotation1, t)
position1 = frame:from(position2, t)
and
rotation1 = frame:from(rotation2, t)
cannot currently be used because
frame=observer:getframe()
only works for observers and not for objects
even though
getposition and setposition work for both.
Selden