Reference frames

[Paolo]

I'm going to go lost.

Please tell me if I'm correct. Every object in Celestia already has Its own frame and its own reference frame. Eg. Atlantis -> Earth -> Sol.

The frame is the initial GL matrix associated to the object + the rules for the modification of the matrix along the time (eg. orbit or xyz path + q).

These two elements allows to know the position and orientation of the object at every time.

So I think i should have the following frame hierarchy: rover camera -> rover -> location -> planet -> star. To animate the rover's camera I would like to ask for the rover's frame that is defined elsewhere and define how the object has to be animated. Stop.

In a futuristic data format I would like to define the frames (that are associated to the various types of objects), each frame should be the reference for another and I would like to write in the same file something like:

Code: Select all


Location
{
    Name "OpportunityLandingLocationOnMars"
    ...
}

GenericObject 
{
    Name "OpportunityRover"
    Type "SurfaceMoveable"
     # This should allow to add a mechanism to automatically align the
     # object with the surface mesh if in a future 3D meshes for planets
     # will be implemented. The animation of the rover on the surface
     # should be done with a long , lat  and compass.
    Mesh  "OpportunityBase.cmod"
    Radious 0.0005
    ReferenceFrame "OpportunityLandingLocationOnMars"
    Begin [ yyyy mm dd hh mm ss]
    Displacement [ xx yy zz ] #initial from the reference frame
    Orientation [ xx yy zz ww ] #initial quaternion
    SampledPath "opportunityrover.xyz"
    SampledOrientation "opportunityrover.q"
}

GenericObject 
{
    Name "OpportunityCamera1"
    Type "Camera"
    # This type should allow to assign the current frame of the object to
    # the observer
    Mesh  "OpportunityCamera1.cmod"
    Radious 0.00001
    ReferenceFrame "Opportunity"
    Begin [ yyyy mm dd hh mm ss] #this shoul dbe inherited from the reference frame
    Displacement [ xx yy zz ] #initial from the reference frame
    Orientation [ xx yy zz ww ] #initial quaternion
    SampledOrientation "opportunitycamera1.q"
}

GenericObject 
{
    Name "OpportunityWheel"
    Type "MeshObject"
    Mesh  "OpportunityWheel.cmod"
    Radious 0.00001
    ReferenceFrame "" #none
    Displacement [ xx yy zz ] #initial from the reference frame to correct cmod if necessary
    Orientation [ xx yy zz ww ] #initial quaternion to correct cmod if necessary
    SampledOrientation "opportunitywheels.q" #this should be a little bit too much, but all the rotations of the wheels along their axis should be sampled.
}

GenericObject
{
    Name "OpportunityWheel1"
    Type "ReferenceObject" #this object is only a clone
    Reference "OpportunityWheel"
    ReferenceFrame "OpportunityRover"
    Displacement [ xx yy zz ] # of the wheel 1 against the rover
    Orientation [ xx yy zz ww ] #of wheel 1 eg on the left side 
    SampledOrientation "opportunitywheel1.q" #this should allow to sample the steering.
}


The system creates a tree of frames related to each other.

Ok ok its too much. I'm a dreamer I know. But in DirectX 5 retained mode the system was designed this way. PLIB-SSG, Ogre and OSG are similar. I don't see many other alternatives.

Of course this potentially changes radically the approach of the internal data structure of Celestia. A unique container of all the frames should allow to manage all the objects in the same way. Perhaps a unique Octree should cull all the objects in a single pass. I don't know which should be the impact on the performance. But IMHO this approach is an intriguing opportunity.

Kind regards

[Paolo]

Moreover instead of two files for xyz and q I would like to have a more Human readable format like

Code: Select all

Animation
{
    Name "MyAnimation"
    KeySequence
    [
        { Time [yyyy mm dd hh mm ss nnnn] Position [xx yy zz] Orientation [xx yy zz ww] }   
        { Time [yyyy mm dd hh mm ss nnnn] Position [xx yy zz] Orientation [xx yy zz ww] }   
        { Time [yyyy mm dd hh mm ss nnnn] Orientation [xx yy zz ww] }   
        { Time [yyyy mm dd hh mm ss nnnn] Orientation [xx yy zz ww] }   
        { Time [yyyy mm dd hh mm ss nnnn] Position [xx yy zz] }   
        { Time [yyyy mm dd hh mm ss nnnn] Position [xx yy zz] Orientation [xx yy zz ww] }   
        { Time [yyyy mm dd hh mm ss nnnn] Position [xx yy zz] Orientation [xx yy zz ww] }
      ...

    ]
}

I think that Celestia now should manage this syntax without any modification to the parser class.
This approach should avoid the multiplication of file formats and extensions.

Kind regards


[chris]

I'm going to go lost.

Please tell me if I'm correct. Every object in Celestia already has Its own frame and its own reference frame. Eg. Atlantis -> Earth -> Sol.

The frame is the initial GL matrix associated to the object + the rules for the modification of the matrix along the time (eg. orbit or xyz path + q).

This is roughly correct. Each object has two reference frames: one for it's trajectory, and one for it's orientation. Let me give a high-level overview of reference frames . . .

While you can use the new reference frames to implement articulated models, that's not what they're really designed for. Some other scheme will have to be devised, and it will likely be scene graph based like OSG. For rigid, articulated structures a hierarchical scene graph works well. The reference frame for each component of the structure is a composition of rotation and translation matrices. But a traditional scene graph is not ideal for describing a solar system full of bodies undergoing complex gravitational interactions. There are a lot of toy solar system programs that do use a scene graph, but the paradigm falls apart when you want to realistically simulate the motions of planets, moons, and spacecraft.

To define the position of a solar system object in Celestia, you must specify its trajectory in an ssc file. That trajectory can be one of several standard types: EllipticalOrbit, CustomOrbit, or SampledOrbit. Celestia 1.5.0 adds a FixedPosition trajectory type, which is used for an object that stays at the same point. All of these trajectories are functions that give the position in three dimensions at any given time. However, the trajectories do not generally produce the position in Celestia's universal coordinate system. Instead, the trajectory gives the position in a local coordinate system. In order to draw an object, Celestia ultimately needs to know where it lies in the universal coordinate system. On object's orbit reference frame provides the conversion from the local coordinates to universal coordinates.

For a simple example of local versus universal coordinates, consider the orbit of Mars's moon Phobos. The most straightforward first-orbit approximation to it's orbit is an ellipse around Mars. To find the position of Phobos relative to the Sun, we must convert from the Mars-centric (or barycentric) local coordinate system to the heliocentric coordinate system. This could be as simple as adding the Mars-centric Phobos position and the heliocentric position of Mars. Or it could be more complicated. A coordinate system requires not just an origin, but a set of axes as well. Celestia's universal coordinate system (as it is exposed through ssc files) has x and y axes that lie in the plane of Earth's orbit, called the ecliptic plane. The z axis points northward, perpendicular to the ecliptic plane. The orbit of Phobos may be defined with respect to some plane other than the ecliptic, meaning that a rotation from that plane to the ecliptic plane would be required in the local to universal coordinate conversion.

The orbit reference frame describes both the translation (shifting) and rotation required to map a trajectory to the universal coordinate system. The translation is the easy part. Every type of reference frame has a center that specifies the origin of the local coordinate system. Typically, the center is the Sun for a planet, or a planet for a moon (in some situations--such as the Pluto system--it makes more sense to use trajectories referenced to a system barycenter, but this isn't fundamentally different.) Rotation is trickier; the several reference frame types in Celestia 1.5.0 all provide different ways to specify the orientation of a reference frame.

It's important to note that a reference frame isn't necessarily static with respect to the universal coordinate system. For example, any Mars-centered coordinate system will have a moving origin. Rotating reference frames will have moving axes as well as a moving origin. A very familiar example is the Earth body-fixed reference frame, in which an object not moving relative to the surface of the Earth will have a constant position.

Reference frames have always been present in Celestia, but until 1.5.0 they were implicit and unchangeable. For planets (or anything orbiting a star), the origin was the central star, and the reference plane was the ecliptic. For moons, the origin was a planet and the reference plane was the equatorial plane of the planet. For backward compatibility, Celestia retains these defaults if you don't specify an OrbitFrame (and more often than not, you won't have to use one.)

These two elements allows to know the position and orientation of the object at every time.

So I think i should have the following frame hierarchy: rover camera -> rover -> location -> planet -> star. To animate the rover's camera I would like to ask for the rover's frame that is defined elsewhere and define how the object has to be animated. Stop.

I'm not really thinking about how to position the rover's camera right now--that's work for the future, and I believe that the moving the rovers components is a different problem than placing the rover on the surface of the planet. Let's cut the rover camera from your hierarchy. Also, separate location object isn't necessary to position the rover. The simplified hierarchy is just rover -> planet -> star. The rover's trajectory, presumably in an xyz file or SPICE kernel, will give the position of the rover. The only sensible coordinate systems to use for the position of a rover are those that are fixed with respect to the surface of the planet that the rover is visiting. Celestia's BodyFixed coordinate system is exactly such a reference frame:

Code: Select all

"Spirit" "Sol/Mars"
{
    Mesh "mer.cmod"
    Radius 0.001

    SampledOrbit "spirit-path.xyz"
    OrbitFrame {
        BodyFixed { Center "Sol/Mars" }
    }
}


spirit-path.xyz should contain coordinates on the surface of Mars. The radius of Mars is 6,805km. An xyz file record like this:

6805 0 0

Would place the rover at 0 degrees N, 0 degrees W right on the surface of Mars (I'm ignoring local topography.) It's slightly inconvenient not to be able to use latitudinal coordinates in the xyz file, but that's an issue with the xyz format and not the reference frame.

I understand what you were getting at by including the location in your object hierachy. But with a body-fixed reference frame, you don't need it. You can make the rover 'stick' to the surface of the planet without having to create a location.

--Chris

[chris]

In defense of the Celestia 1.5.0's implementation of reference frames, I want to mention that it's based heavily on NASA's SPICE toolkit and on conversations I've had with people working in the field of astrodynamics. The actual SSC syntax is original to Celestia, but the concepts such as body-fixed reference frames and local attitude coordinate systems are in everyday use by people designing space missions. I will do everything I can to document the new SSC features, provide examples, and make them easy to use as possible without sacrificing expressiveness. Even then it may still be a little hard to understand reference frames; nor do you even have to use them to create add-ons. But, I think if you are an add-on creator, taking the time to figure out reference frames will open up a lot of new possibilities.

--Chris

[Cham]

Chris,

as an addon creator, what I need most for addons creation are :

1- periodic motions along any xyz path (matter falling on an accretion disk, for example, in a perpetual way)
2- user defined precessionrate orientation
3- model orientation locked toward another moving object.

I need complete examples of how to achieve these with all the new commands.

[Chuft-Captain]

Chris,

as an addon creator, what I need most for addons creation are :

1- periodic motions along any xyz path (matter falling on an accretion disk, for example, in a perpetual way)
2- user defined precessionrate orientation
3- model orientation locked toward another moving object.

I need complete examples of how to achieve these with all the new commands.

Cham,
I'd be interested if you have any opinions on my earlier Periodic Motion suggestions.

[Starshipwright]

Cham, have you checked Seldon's Celestia Notes page:

http://www.lepp.cornell.edu/~seb/celestia/celestia_notes.html

He is keeping up with documentation on the new features of 1.5.0

I agree that a new .ssc guide would be nice because of all the changes, but I think that it should wait until the official 1.5.0 release, so that it will reflect all of the changes that are made.

For myself, I am copying information that is given in posts about new features to make a "scrapbook" guide.

[Paolo]

Chris Thank you for the explanations.

But I'm not so conviced about your argumentations. Other toy solar systems programs using scene graphs are using simpler trajectory calculations than Celestia. This is why are toy programs.

Thinking about SPICE. I've red a bit about it and it seems to me that the sytems works almost exactly as a scene graph where there are several pre-defined standard initial reference frames and where you can define as many reference frames as you want each somewhat connected to each other.

So thanks to your explanations I uderstood that in Celestia for an object orbitting round the Moon has the following hierarchy:

UniversalCoord<-SolBarycenter<-EarthBarycenterAtACertainEpoch<-MoonAtACertainEpoch<-ObjectOrbittingMoonAtACertainEpoch.

Each Frame represents an OpenGL transformation matrix. To each frame (except the first two that are fixed by design) is associated the animation stuff that is composed by a Trajectory function (position in time like orbit etc) some kind of Orientation function (eg like the new OrbitFrame::TwoVector ) and a spinning rotation function.
Each function produces an OpenGL transformation matrix.

In order to compute the position of the Object Orbitting around the moon all these transformation matrices has to be multiplied at each rendering.

IMHO it is already a scene graph except that there isn't a unique tree container of frames behind the scenes.

Please do not discard this system aprioristically for the models animation. I agree that the mesh vertexes morphing is a different matter. But for robotical arms is more than enough. And it seems to me that Roketman@JSC was asking for this and that SPICE kernels works this way.

I think that after version 1.5.0 some cleanup it will be advisable to simplify the data format and the object model. At least some names IMHO are obscure and misleading.
I know that the rising problem is the backward compatibility of all the existing add-ons, but I think that futures versions of Celestia need both an unified data format and a better internal object model.


Kind regards

[chris]

Cham,
I'd be interested if you have any opinions on my earlier Periodic Motion suggestions.

My current feeling is that periodic motion should be specified in the xyz file. I don't have a detailed proposal right now, but I'll consider all of your suggestions. I will unfortunately not have time to work on periodic motion until after 1.5.0.

--Chris

[chris]

Chris,

as an addon creator, what I need most for addons creation are :

1- periodic motions along any xyz path (matter falling on an accretion disk, for example, in a perpetual way)
2- user defined precessionrate orientation
3- model orientation locked toward another moving object.

I need complete examples of how to achieve these with all the new commands.

You'll get items 2 and 3 in Celestia 1.5.0. Item 1 will have to wait until Celestia 1.5.1 (which will be a minor update, and not the huge project that 1.5.0 is.)

The shuttle Atlantis example I posted to this thread shows how to keep an object's orientation locked toward another object. I'll have a sample soon that shows how to specify a custom precession plane.

--Chris

[Cham]

IMO, the simplest way (for the user) to define the Precession axis is something like this, in the SSC file :

PrecessionRate xxx
PrecessionAxis [x x x]

with the precession axis defined relative to Earth's axis, or relative to the object's orbit (normal to its orbit, actuallly).

Also, for the user which makes the SSC, it would be much easier to define an object orientation is like this :

OrientationLock "object name"

[chris]

IMO, the simplest way (for the user) to define the Precession axis is something like this, in the SSC file :

PrecessionRate xxx
PrecessionAxis [x x x]

with the precession axis defined relative to Earth's axis, or relative to the object's orbit (normal to its orbit, actuallly).

It won't work quite like that . . .

Also, for the user which makes the SSC, it would be much easier to define an object orientation is like this :

OrientationLock "object name"

That may be easy, but it also doesn't completely define the orientation of the object. Just specifying a single direction vector leaves one free parameter: the rotation about the vector. Celestia could choose some arbitrary secondary vector so that the orientation would be completely determined, but that's undesirable. For one thing, if the second vector happens to be aligned with the first, the orientation of the object would be undefined.

One way to express an orientation lock with reference frames is this:

Code: Select all

BodyFrame {
    TwoVector {
        Center "Sol/Object"
        Primary {
            Type "RelativePosition"
            Axis "z"
            Observer "Sol/Object"
            Target "Sol"
        }
        Secondary {
            Type "RelativeVelocity"
            Axis "x"
            Observer "Sol/Object"
            Target "Sol"
        }
    }
}


In this example, the object called "Object" will be oriented so it's z-axis always points toward the Sun. There's a lot more typing required than your proposal (which I'm assuming is a reference frame, not a rotation model):

Code: Select all

BodyFrame
{
    OrientationLock "Sol"
}


Why all the extra typing? First of all, it's necessary to define the secondary axis. My example chooses uses the velocity of Object relative to the Sun. Second, you're free to choose the axes of the reference frame, thus the Axis "z" and Axis "y"--perhaps Celestia could use some reasonable defaults so that you wouldn't always have to specify these. In general, the TwoVector reference frame is much more flexible than the OrientationLock frame, though it's obviously somewhat harder to use.

It would be possible to define an OrientationLock frame that is converted automatically to the appropriate TwoVector reference frame. But, creating such 'syntactic sugar' is only worthwhile if it simplifies a very common task, and I'm not sure how frequently you'll want to create an OrientationLock frame.

Now, I expect Hank to comment here about how you could define a Lua function library if the SSC format were Lua-based

--Chris

[chris]

I've made some changes to the TwoVector frame type that make it more consistent with how other SSC blocks work and also make it easier to use. The Type field is gone, replaced by a named block, so this:

Code: Select all

Primary {
    Type "RelativePosition"
    Axis "z"
    Observer "Sol/Object"
    Target "Sol"
}


becomes this:

Code: Select all

Primary {
    Axis "z"
    RelativePosition {
        Observer "Sol/Object"
        Target "Sol"
    }
}


I've also made the frame center the default observer for observer-target vectors. This is a very common case. Here's how the sun-locked frame looks like with the modifications to two-vector frames:

Code: Select all

BodyFrame {
    TwoVector {
        Center "Sol/Object"
        Primary {
            Axis "z"
            RelativePosition { Target "Sol" }
        }
        Secondary {
            Axis "x"
            RelativeVelocity { Target "Sol" }
        }
    }
}


That's a little bit simpler . . .

--Chris

[chris]

I have a new reference frame example. This one is more complex than previous ones. It defines a frame centered on an object, with the z-axis pointing from the center of the Earth through the object and the y-axis pointing northward perpendicular to z. This frame is most useful for an object on the surface of the Earth (or any planet.) The z-axis is up, the y-axis is local true north direction, and x is local east (the cross product of z and y.) It's very useful for orienting an object moving on the surface of a planet--the reference frame means that the up direction stays the same no matter where you position the object, and you can 'turn' it by changing the rotation about the z-axis.

Code: Select all

BodyFrame {
    TwoVector {
        Center "Sol/Earth/Object"
        Primary {
            Axis "-z"
            RelativePosition { Target "Sol/Earth" }
        }
        Secondary {
            Axis "y"
            ConstantVector {
                Vector [ 0 0 1 ]
                Frame { BodyFixed { Center "Sol/Earth" } }
            }
        }
    }
}


The slightly tricky part is the definition of the secondary direction. The ConstantVector {} block is just the north pole of Earth. In a planet's body-fixed reference frame, the vector (0, 0, 1) (+Z) is the north pole (that is, the pole about which the planet appears to rotate counterclockwise, so it will actually point south of the ecliptic for a retrograde rotator.) If it's useful, I could modify the ssc parser make:

Code: Select all

NorthPole { <object> }


equivalent to:

Code: Select all

ConstantVector {
    Vector [ 0 0 1 ]
    Frame { BodyFixed { Center <object> } }
}


But, I'll wait to see how often reference frames get used before introducing shortcuts.

--Chris

[chris]

The existing observer modes follow, sync orbit, chase, and phase lock will (after 1.5.0) be rewritten and implemented in terms of the new reference frames. Here's how they would look, given the objects target and reference.

Follow:

Code: Select all

OrbitFrame {
     EclipticJ2000 { Center <reference> }
}

# Body frame is identical to orbit frame


Sync orbit:

Code: Select all

OrbitFrame {
    BodyFixed { Center <reference> }
}

# Body frame is identical to orbit frame


Phase lock:

Code: Select all

OrbitFrame {
    TwoVector {
        Center <reference>
        Primary {
            Axis "z"
            RelativePosition {
                 Observer <reference>
                 Target <target>
            }
        }

        Secondary {
            Axis "y"
            ConstantVector {
                Frame { BodyFixed { Center <reference> } }
                Vector [ 0 0 1]
            }
        }
    }
}

# Body frame is identical to orbit frame


Chase:

Code: Select all

OrbitFrame {
    TwoVector {
        Center <reference>
        Primary {
            Axis "z"
            RelativeVelocity {
                 Observer <reference>
                 Target <parent of reference>
            }
        }

        Secondary {
            Axis "y"
            ConstantVector {
                Frame { BodyFixed { Center <reference> } }
                Vector [ 0 0 1]
            }
        }
    }
}

# Body frame is identical to orbit frame


Note that this is intended to be another reference frame example. I don't actually plan to have write the observer modes as ssc files

All of the existing observer modes have an orbit frame (for position) that's identical to the body frame (for orientation.) But, this does not have to be the case for new modes . . . For example, track could be implemented by using BodyFrame that's different than the OrbitFrame. An implementation of track in terms of frames would behave much better than the way track does now. With the following frame, an 'up' vector is defined so that the camera won't roll with respect to the horizon. Here, the object reference is the planet that the observer is on, and target is the tracking target:

Code: Select all

BodyFrame {
    TwoVector {
        Center <observer>

        # observer to target direction
        Primary {
            Axis "x"
            RelativePosition {
                Observer <observer>
                Target <target>
            }
        }

        # up direction
        Secondary {
             Axis "-z"
             RelativePosition {
                 Observer <observer>
                 Target <reference>
             }
         }
     }
}                 


--Chris

[ElChristou]

Here two other example for the MGS and Voyager, both with a slight rotation (via UniformRotation) ... pretty cool indeed!

EDIT: the orientation is ok for my models...

Code: Select all

"MGS" "Sol/Mars"

{
   Class         "spacecraft"
   Mesh         "mgs_F.cmod"
   Radius         0.01
   Orientation      [ 90 1 0 0 ]
   MeshCenter      [ -0.027 0 0.07 ]



   EllipticalOrbit
   {
   Epoch         2451973.25864
   Period         0.08127579
   SemiMajorAxis      3767.968213
   Eccentricity      0.005809
   Inclination      93.0092
   AscendingNode      28.452982
   ArgOfPericenter      267.202961
   MeanAnomaly      0.0
   }

   UniformRotation
   {
       Period         0.95
   }


}

Modify "MGS" "Sol/Mars"
{
   BodyFrame
   {
           TwoVector
      {
         Center "Sol/Mars/MGS"
         Primary
         {
            Axis "z"
         RelativePosition
                      {
            Observer "Sol/Mars/MGS"
                      Target "Sol/Mars"
            }
         }
                  Secondary
         {
            Axis "y"
            RelativeVelocity
                      {
            Observer "Sol/Mars/MGS"
                      Target "Sol/Mars"
            }
         }
           }
   }
}


Code: Select all

"Voyager 1" "Sol"

{

   Class         "spacecraft"

   Mesh         "voyager.cmod"

   Radius         0.019
   MeshCenter      [ -39.66 0.1 -30 ]
   Orientation      [ 90 1 0 0 ]

   
   Beginning      "1977 09 05 12:00"   #Launch

   SampledOrbit      "voyager1.xyz"



   Albedo         0.1
   
   UniformRotation
   {
       Period 0.99
   }


}

Modify "Voyager 1" "Sol"
{
   BodyFrame
   {
      TwoVector
      {
         Center "Sol/Voyager 1"
         Primary
         {
            Axis "z"
            RelativePosition
            {
            Observer "Sol/Voyager 1"
            Target "Sol/Earth"
            }
         }
         Secondary
         {
            Axis "y"
            RelativeVelocity
            {
            Observer "Sol/Voyager 1"
            Target "Sol/Earth"
            }
         }
      }
   }
}


[Cham]

I've found a major bug with the following code (from ElChristou) and some lock commands (I'm using the latest version of CVS). While following MGS, I selected Mars (by clicking on it) and used the ':' keyboard shortcut to lock the oberver's orientation between the probe and Mars. I then instantaneously got a fast and erratic behavior of Celestia. Even by slowing down time by any factor, the erratic movement wasn't affected, until I selected 'cancel' or 'follow' (F) the probe again. There's some incompatibility here.

I think the SSC building is getting very absurd, with all the new syntax, commands and all the necessary {}. It will make addons creators life much harder ! I'm taking ElChristou's SSC code for MGS as an example (which also revealed the bug). Using tabulations to properly format the code, here's what it's looking like, just to lock the probe's orientation toward Mars :

Code: Select all

"MGS" "Sol/Mars"
{
   Class   "spacecraft"
   Mesh   "mgs_NF.cmod"
   Radius   0.01
   Orientation [ 90 1 0 0 ]
   MeshCenter [ -0.027 0 0.07 ]

   EllipticalOrbit
   {
      Epoch      2451973.25864
      Period      0.08127579
      SemiMajorAxis   3767.968213
      Eccentricity   0.005809
      Inclination   93.0092
      AscendingNode   28.452982
      ArgOfPericenter   267.202961
      MeanAnomaly   0.0
   }

   UniformRotation
   {
      Period         0.95
   }
}

Modify "MGS" "Sol/Mars"
{
   BodyFrame
   {
      TwoVector
      {
         Center "Sol/Mars/MGS"

         Primary
         {
            Axis "z"
            RelativePosition
            {
               Observer "Sol/Mars/MGS"
               Target "Sol/Mars"
            }
         }

         Secondary
         {
            Axis "y"
            RelativeVelocity
            {
               Observer "Sol/Mars/MGS"
               Target "Sol/Mars"
            }
         }
      }
   }
}

[Malenfant]

I think the SSC building is getting very absurd, with all the new syntax, commands and all the necessary {}. It will make addons creators life much harder !

I must agree here. Though I wouldn't mind as much if we didn't need all this for planets, moons, and stars around barycentres. If we do need to enter all this for those, then it's going to make it a lot harder to write addons.

[chris]

I've found a major bug with the following code (from ElChristou) and some lock commands (I'm using the latest version of CVS). While following MGS, I selected Mars (by clicking on it) and used the ':' keyboard shortcut to lock the oberver's orientation between the probe and Mars. I then instantaneously got a fast and erratic behavior of Celestia. Even by slowing down time by any factor, the erratic movement wasn't affected, until I selected 'cancel' or 'follow' (F) the probe again. There's some incompatibility here.

The problem lies in the way that the phase lock coordinate system is defined. The primary axis points from the reference object to the selection, and the other axis is at right angles to the primary in the direction of the z-axis (typically the rotation axis of a planet.) If the z-axis and the reference to selection direction are aligned, then the phase lock coordinate system is undefined. This limitation has always been present in Celestia, but only very rarely did the two directions align.

However, ElChristou's reference system defines the z-axis to *always* point from MGS to Mars--in other words, it's exactly aligned with the primary axis of the phase lock coordinate system. I need to fix this by figuring out a secondary direction for phase lock that won't be aligned with the primary.

I think the SSC building is getting very absurd, with all the new syntax, commands and all the necessary {}. It will make addons creators life much harder ! I'm taking ElChristou's SSC code for MGS as an example (which also revealed the bug). Using tabulations to properly format the code, here's what it's looking like, just to lock the probe's orientation toward Mars :

You don't have to use any of this to build an SSC file. The current system is flexible enough that you can use it to define most of the reference frames used in astrodynamics and celestial mechanics. If you have an alternate proposal that offers just as much flexibibility but is easier to use, then I'd like to hear about it.

It's possible that the reference frames could be extended with some 'shortcuts' for situations like making one object maintain a fixed orientation with respect to another, but I'd rather wait until 1.5.0 to discover what the common usage cases will be.

--Chris

[chris]

I think the SSC building is getting very absurd, with all the new syntax, commands and all the necessary {}. It will make addons creators life much harder !

I must agree here. Though I wouldn't mind as much if we didn't need all this for planets, moons, and stars around barycentres. If we do need to enter all this for those, then it's going to make it a lot harder to write addons.

You need to do anything differently for stars; reference frames will eventually be supported for stars as well, but the the current OrbitBarycenter scheme will continue to be supported.

Making a barycentric planet definition isn't difficult:

Code: Select all

Center "Pluto-Charon" "Sol"
{
    CustomOrbit "pluto"
}

"Pluto" "Sol"
{
    EllipticalOrbit
    {
        ...
    }

    OrbitFrame
    {
        EclipticJ2000 { Center "Sol/Pluto-Charon" }
    }
}


That's not so bad, is it? Granted, it's not as easy as just making Pluto a child object of Sol/Pluto-Charon (which is still possible), but there are some advantages of doing it with a frame instead:

- You have the option to choose the most convenient reference plane for the orbital parameters.
- The full name for Pluto is Sol/Pluto instead of Sol/Pluto-Charon/Pluto (for compatibility with existing scripts, and because this fits most people's understanding of the solar system hierarchy)
- Pluto is a top-level object in the solar system browser (rather than appearing as a satellite of the Pluto-Charon barycenter)

--Chris