Object Timeline proposal

[chris]

Some of the more complex and interesting add-ons for Celestia are space mission recreations, such as the new Flight of Buran add-on from Runar, Andrea, and Christophe. To make such add-ons, a wide range of 'hacks' are currently required. I'd like to eliminate the need for ssc tricks like objects with empty names, and most of all, temporary objects that appear then disappear.

To take a familiar and simple example, the Cassini mission has two different Huygens probes: one is attached to Cassini, the other--named "Huygens (free flight)"--has an orbit defined relative to the Sun. It's not possible to select Huygens and follow it throughout it's mission: if you select the "Huygens (with Cassini)", you'll find yourself drifting in empty space if you try and follow it past the point it separates from Cassini. In addition, once Huygens lands on Titan, it just disappears. There should really be a third version of Huygens at a fixed position in Titan's body-fixed reference frame. Attempting to follow Huygens through the switch from the second to third phase of the Huygens mission would be similarly confusing for users: they'd findthemselves at a fixed point in space as Titan orbits away.

I think both add-on creators and users would have a better experience if it were possible to create a single object with multiple phases, each of which could have a different trajectory and reference frame. It would then be possible to use a single SSC object for a spacecraft across the entire mission. This is much more intuitive for users, and I think it also reduces the amount of work required for add-on creators.

Here's how Huygens might look:

Code: Select all

"Huygens" "Sol"
{
    Class "spacecraft"
    Mesh "huygens.3ds"
    Radius 0.00135

    Timeline
    [
        # Attached to Cassini
        {
             Beginning "1997 10 15 09:27"
             OrbitFrame { BodyFixed { Center "Sol/Cassini" } }
             FixedPosition [ ... ]
             BodyFrame { BodyFixed { Center "Sol/Cassini" } }
             FixedRotation { ... }
         }

         # Free flight
         {
              Beginning "2004 12 25 02:01"
              OrbitFrame { EclipticJ2000 { Center "Sol/Saturn/Titan" } }
              SampledTrajectory { ... }
              BodyFrame { EclipticJ2000 { } }
              SampledOrientation { ... }
          }

          # Landed on Titan
          {
               Beginning "2005 1 14 09:00"
               OrbitFrame { BodyFixed { Center "Sol/Saturn/Titan" } }
               FixedPosition [ ... ]
               BodyFrame { BodyFixed { Center "Sol/Saturn/Titan" } }
               FixedRotation { ... }
          }
     ]

}


Add-on creators: would you use this? And what would you do to improve it?

--Chris

[Cham]

Then, what about the model evolution ? In most of the timeline phases, the model may actually change in shape. The timeline should take care of this too.

And does the timeline definition allow a planet or moon to change over time (since it's about declarations in an SSC file) ?

This may also be interesting, in combination with the recent experiment on texture animation/evolution (from Toti ?).

[ElChristou]

Add-on creators: would you use this?

Yes!

[chris]

Then, what about the model evolution ? In most of the timeline phases, the model may actually change in shape. The timeline should take care of this too.

And does the timeline definition allow a planet or moon to change over time (since it's about declarations in an SSC file) ?

I hadn't thought of that, but it's a very good idea. All of the appearance attributes could be moved into the timeline as well. I'll propose that initially, a timeline phase just include information about positioning and orienting the model, but I could design the feature so that appearance changes could eventually be supported as well.

This may also be interesting, in combination with the recent experiment on texture animation/evolution (from Toti ?).

Possibly, although that requires cyclical changes which I think would be best handled through a scheme like the one Toti proposed here on the forum

--Chris

[Cham]

I see the opportunity to define a probe's evolution in time, with its solar panels extending, for example (the ISS is another good example).

In thise case, we may need to put the radius definition in the timeline too.

Hmmm, this may also be a whole can of worms, if we also need to put all the other attributes in the timeline...

[chris]

I see the opportunity to define a probe's evolution in time, with its solar panels extending, for example (the ISS is another good example).

In this case, it might be best to make the solar panels separate objects.

In thise case, we may need to put the radius definition in the timeline too.

Hmmm, this may also be a whole can of worms, if we also need to put all the other attributes in the timeline...

It's not that difficult to do in the code, but it would require some more though. How a timeline works with trajectories and rotations is a bit more obvious, which is why I'm proposing that as a first step.

--Chris

[Cham]

I see the opportunity to define a probe's evolution in time, with its solar panels extending, for example (the ISS is another good example).

In this case, it might be best to make the solar panels separate objects.

Yes, but the evolution of the ISS is another example, for which we need to put the mesh declaration in the timeline itself

[chris]

I see the opportunity to define a probe's evolution in time, with its solar panels extending, for example (the ISS is another good example).

In this case, it might be best to make the solar panels separate objects.

Yes, but the evolution of the ISS is another example, for which we need to put the mesh declaration in the timeline itself

It might be better to make the modules separate objects. This would result in smaller files. With separate objects, the geometry for each object is only defined once. But if you use different mesh files for each stage, the geometry for the first module is replicated in the mesh files for all the stages.

--Chris

[Cham]

The geometry may be replicated in several mesh files, yes. But I don't see this as a problem, for reasonable models.

Having a different mesh for each phase of the timeline has many advantages. Of course, the mesh used in phase 1 should disappears when we go to phase 2, and should be replaced with another mesh designed for that new phase. This way, we don't risk to click on another part, defined as another object (without using the clickable false option), and the SSC coding would also be much simpler than having to define the evolution of several objects at once.

The disadvantage of this method is the relative slow process of reading the model on the HD, at each new phase, which may result in some laggy evolution in Celestia. I guess this is about the same with the other method anyway (several objects evolving, as you suggested), especially since Celestia is slower to draw several meshes, instead of a single larger mesh alone (Selden's argument, from another thread).

Nonetheless, having the possibility to use both methods is an advantage.

[chris]

The geometry may be replicated in several mesh files, yes. But I don't see this as a problem, for reasonable models.

It can make a significant difference . . . Suppose there are 15 stages of ISS, with a 100K module added at each stage. If the modules all use separate meshes, the total size of all models is 15*100K = 1,500K. Total size is thus linear with the number of stages N.

With a mesh for each stage instead of each module, you end up with this situation:

1st stage model: 100K
2nd stage model: 200K: 100K first module + 100K second module
3rd stage model: 300K
...
Nth stage model: N*100K

Summing all the stages, you end up with 100K * (1+2+3+...+N), or 100*N*(N+1)/2 = 100*(N^2 + N)/2. The N^2 is a killer: for 15 stages, you end up with 12,000K, or 8 times as much geometry. The ISS with separate objects could be included in the base package; not so with the mesh-per-stage version.

Anyhow, I'm not trying to argue against the utility of adding meshes to the timeline. I think that it would have it's uses, but I don't think that ISS is one of them.

--Chris

[Cham]

Well, of course, it also depends on the number of stages. The ISS example is a bit extreme, on the number and size of meshes required (15 stages).

I was thinking about some simpler missions, with a few mesh modifications. The SSC coding should be much simpler in their case, if we include the mesh declarations in the timeline of a single object. With separate objects, we'll also need to take care for the objects size, placement and orientation, which is more work to do at the SSC level than doing it in the modeler.

We need the opinions of Selden, ElChristou, Runar and several others, who are the experts in these matters (spaceship missions).

[ElChristou]

What if we have each stages of a mission defined in a classic ssc and a time line/orientation doc where we could treat all about positionning those stage in space AND time?

Code: Select all

Timeline
    [
        # Cassini
        {
             Beginning "1997 10 15 09:27"
             OrbitFrame { BodyFixed { Center "Sol" } }
             FixedPosition [ ... ]
             BodyFrame { BodyFixed { Center "Sol" } }
             FixedRotation { ... }
         }

        # Huygens attached to Cassini
        {
             Beginning "1997 10 15 09:27"
             OrbitFrame { BodyFixed { Center "Sol/Cassini" } }
             FixedPosition [ ... ]
             BodyFrame { BodyFixed { Center "Sol/Cassini" } }
             FixedRotation { ... }
         }

         # Huygens Free flight
         {
              Beginning "2004 12 25 02:01"
              OrbitFrame { EclipticJ2000 { Center "Sol/Saturn/Titan" } }
              SampledTrajectory { ... }
              BodyFrame { EclipticJ2000 { } }
              SampledOrientation { ... }
          }

     etc..

     ]

[buggs_moran]

I love this idea.

I agree with the concept that each model in an ssc should have it's own timeline.

If I am interpreting this correctly the timeline Chris is proposing would be a location and orientation declaration only. So, in the Huygens example, Cassini would be it's own model. Huygens would be a separate model in a separate ssc all the way from launch. It would stick with Cassini using the new Orbit and Body frame declarations, then upon arrival it would detach, and no new models would have to be loaded until the parachutes deploy. The glorious part is that the Cassini model would remain the same throughout, no separate models to load as time passed...

Would it be possible to have a timeline declaration for the other parts of a ssc/stc? We have Toti working on a texture timeline. What about a radius timeline (expanding clouds) or a mesh timeline similar in nature ? This would avoid that memory hog issue or reloading a mesh at each new orientation change...

As always, I would be in favor of some cyclical option. Toti's texture work in this respect is already stopping me in my design tracks to wait for it's possibilities. A similar mesh change possibility would have astounding implications for Celestia.

I can make my cataclysmic binaries have their cataclysms...

[Chuft-Captain]

The tricky part is going to be ensuring that the transitions between reference frames (in terms of position) are smooth.

[selden]

Associating the same object name with multiple phases of a mission is certainly desirable. This timeline proposal seems like a good way to do it.

In case you didn't realize it, the cyclical appearance of objects (and thus of their associated textures) is already possible with the svn version of Celestia by using the Visible keyword and a Lua function which manipulates the Visible attribute. It could be implemented as a CELX script, which limits it to one at a time, or as ScriptedOrbits, with many running simultaneously. That's somewhat of a hack, though

[scaddenp]

An obvious extension of the idea would be to allow for texturing to change through time. Eg for tectonic plate reconstructions shown on Earth

[chris]

I've implemented the proposal, and am still in the process of testing it to make sure that I didn't break anything. There were a lot of changes required to make it work, but with the exception of some parsing stuff the new code is clearer than the old.

A few issues of specification came up during the implementation. I chose to disallow non-contiguous timelines by restricting the use of Beginning and Ending in timeline phases. The rules are:

- Any phase other than the last must have an Ending specified
- Only the first phase can have a Beginning specified; for all other phases, Beginning is implicitly the Ending of the previous phase.
- Beginning is optional for the first phase; if not specified it defaults to negative infinity.
- Ending is optional for the last phase; if not specified it defaults to positive infinity.

Here's an example of a valid timeline will look something like this:

Code: Select all

Timeline [
    {
         Ending "2008 2 1"
         EllipticalOrbit { ... }
    }
    {
         Ending "2008 3 14"
         SampledTrajectory { ... }
    }
    {
         EllipticalOrbit { ... }
    }
]


Here, the second phase of the Timeline is a SampledTrajectory that covers dates between 1 Feb 2008 and 14 Mar 2008. EllipticalOrbits extend the timeline to arbitrary dates before and after the valid range of the SampledTrajectory.

The second issue is in regard to the behavior of a Timeline with Modify. Say you have the following:

Code: Select all

"Thing" "Sol"
{
    Timeline [
       {
           EllipticalOrbit { ... }
           UniformRotation { ... }
       }
    ]
}

Modify "Thing" "Sol"
{
    SampledTrajectory { ... }
}


Here, the logical thing seems to be for the SampledTrajectory to override the EllipticalOrbit, just as it would if the original definition didn't have a timeline specified. But what if the original Timeline has multiple phases: should the first phase be modified, or should it be replaced completely? I've opted for the latter. So, a single phase Timeline behaves exactly like a conventional object definition with Modify. But a multiphase Timeline is replaced whenever Modify changes any of these properties:

OrbitFrame
BodyFrame
Orbit (via FixedPosition, EllipticalOrbit, SampledOrbit, etc.)
RotationModel (via FixedRotation, UniformRotation, SampledOrientation, etc.)
Beginning
Ending
Timeline

The interaction of Timelines and Modify is sort of a corner case, but the behavior should still be well-defined.

--Chris

[chris]

The tricky part is going to be ensuring that the transitions between reference frames (in terms of position) are smooth.

Yes. I want to make it easier by creating a script that will 'weld' together all phases of a timeline. An add-on creator will define an object with a multiphase timeline and then run this weld script. The script will write out to a text file the positions and rotations (in both quaternion and FixedRotation form) required to match up the timeline phases.

Suppose that you have a rocket on an Earth-based launchpad. The timeline may look something like this:

Code: Select all

Timeline [
  # Phase 1 - on launchpad
  {
       OrbitFrame { BodyFixed { Center "Sol/Earth" } }
       BodyFrame { BodyFixed { Center "Sol/Earth" } }
       FixedPosition [ ... ]
       FixedRotation { ... }
       
       # Three days on the launch pad
       Beginning "2008 2 18"
       Ending "2008 2 21"
   }

   # Phase 2 - off into space
   {
        OrbitFrame { EquatorJ2000 { Center "Sol/Earth" } }
        BodyFrame { EquatorJ2000 { } }
        SampledTrajectory { ... }
        SampledOrientation { ... }
    }
]


The rocket transitions between phases at launch on 21 Feb 2008. The script will generate two sets of values at that time: positions/orientations in the phase 1 reference frames and positions/rotations in the phase 2 frames. Presumably, one set is already known--suppose that it's the rocket trajectory into space and you need to figure out the Earth body fixed coordinates. You would put some dummy values in the phase 1 FixedRotation and FixedPosition (or just leave them blank.) Then, start Celestia an rund the script. Paste the values output by the script into the FixedRotation and FixedPosition, and restart. Voila! The two mission phases should match up perfectly.

--Chris

[Cham]

Chris,

this is all VERY interesting. I agree with your proposition. I feel it's the right way to do it.

Please, it would be good to allow for the change of mesh too, in the timeline itelf (of course, it could be added later).

Also, why the [] for the timeline ? Shouldn't be better to use {} instead, as for all the SSC code declarations (for consistency) ?

[chris]

Chris,

this is all VERY interesting. I agree with your proposition. I feel it's the right way to do it.

Please, it would be good to allow for the change of mesh too, in the timeline itelf (of course, it could be added later).

As important as it is to improve Celestia's animation capabilities, I don't want to rush ahead on this. There's a lot to think about--perhaps it would be better to add support for some standard 3D file format with articulation (like OpenFlight) instead of making Timeline more complex.

Also, why the [] for the timeline ? Shouldn't be better to use {} instead, as for all the SSC code declarations (for consistency) ?

The square brackets are consistent, since the timeline is an array of unnamed values and not a property list. Notice that with things enclosed in braces, you always have:

Code: Select all

{
    Name Value
    Name Value
    Name Value
    ...
}


...while with square brackets, it's just:

Code: Select all

[
    Value
    Value
    Value
]


In both cases, a value can be either a simple number or something more complex like another property list.

--Chris