Object Timeline proposal

Description: Discussion forum for Celestia developers; topics may only be started by members of the developers group, but anyone can post replies.

chris
Topic author, Site Admin
chris
Topic author, Site Admin
Posts: 4217
With us: 15 years 5 months
Location: Seattle, Washington, USA

#1by chris » 16.02.2008, 23:33

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 M
Avatar
Cham M
Age: 52
Posts: 4299
With us: 13 years 6 months
Location: Montreal

#2by Cham » 16.02.2008, 23:48

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 ?).
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

ElChristou
ElChristou
Posts: 3808
With us: 12 years 5 months

Re: Object Timeline proposal

#3by ElChristou » 16.02.2008, 23:50

chris wrote:Add-on creators: would you use this?


Yes! :D
Image

chris
Topic author, Site Admin
chris
Topic author, Site Admin
Posts: 4217
With us: 15 years 5 months
Location: Seattle, Washington, USA

#4by chris » 17.02.2008, 00:00

Cham wrote: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 M
Avatar
Cham M
Age: 52
Posts: 4299
With us: 13 years 6 months
Location: Montreal

#5by Cham » 17.02.2008, 00:07

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...
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

chris
Topic author, Site Admin
chris
Topic author, Site Admin
Posts: 4217
With us: 15 years 5 months
Location: Seattle, Washington, USA

#6by chris » 17.02.2008, 00:14

Cham wrote: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 M
Avatar
Cham M
Age: 52
Posts: 4299
With us: 13 years 6 months
Location: Montreal

#7by Cham » 17.02.2008, 00:17

chris wrote:
Cham wrote: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
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

chris
Topic author, Site Admin
chris
Topic author, Site Admin
Posts: 4217
With us: 15 years 5 months
Location: Seattle, Washington, USA

#8by chris » 17.02.2008, 00:27

Cham wrote:
chris wrote:
Cham wrote: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 M
Avatar
Cham M
Age: 52
Posts: 4299
With us: 13 years 6 months
Location: Montreal

#9by Cham » 17.02.2008, 00:42

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.
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

chris
Topic author, Site Admin
chris
Topic author, Site Admin
Posts: 4217
With us: 15 years 5 months
Location: Seattle, Washington, USA

#10by chris » 17.02.2008, 01:05

Cham wrote: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 M
Avatar
Cham M
Age: 52
Posts: 4299
With us: 13 years 6 months
Location: Montreal

#11by Cham » 17.02.2008, 01:20

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).
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

ElChristou
ElChristou
Posts: 3808
With us: 12 years 5 months

#12by ElChristou » 17.02.2008, 10:47

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..

     ]
Image

buggs_moran
buggs_moran
Posts: 835
With us: 12 years 9 months
Location: Massachusetts, USA

#13by buggs_moran » 17.02.2008, 15:09

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... :D
Homebrew:
WinXP Pro SP2
Asus A7N8X-E Deluxe
AMD Athlon XP 3000/333 2.16 GHz
1 GB Crucial RAM
80 GB WD SATA drive
ATI AIW 9600XT 128M

Chuft-Captain
Avatar
Chuft-Captain
Posts: 1725
With us: 11 years 7 months

#14by Chuft-Captain » 17.02.2008, 15:43

The tricky part is going to be ensuring that the transitions between reference frames (in terms of position) are smooth.
"Is a planetary surface the right place for an expanding technological civilization?"
-- Gerard K. O'Neill (1969)

O'NEILL COLONY
LAGRANGE POINTS

selden
Avatar
selden
Posts: 10014
With us: 14 years 10 months
Location: NY, USA

#15by selden » 17.02.2008, 16:49

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 :)
Selden

scaddenp
scaddenp
Posts: 55
With us: 13 years 11 months
Location: Dunedin, New Zealand

#16by scaddenp » 17.02.2008, 22:18

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
Topic author, Site Admin
chris
Topic author, Site Admin
Posts: 4217
With us: 15 years 5 months
Location: Seattle, Washington, USA

#17by chris » 20.02.2008, 17:34

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
Topic author, Site Admin
chris
Topic author, Site Admin
Posts: 4217
With us: 15 years 5 months
Location: Seattle, Washington, USA

#18by chris » 20.02.2008, 17:50

Chuft-Captain wrote: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 M
Avatar
Cham M
Age: 52
Posts: 4299
With us: 13 years 6 months
Location: Montreal

#19by Cham » 20.02.2008, 19:09

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) ?
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

chris
Topic author, Site Admin
chris
Topic author, Site Admin
Posts: 4217
With us: 15 years 5 months
Location: Seattle, Washington, USA

#20by chris » 20.02.2008, 19:32

Cham wrote: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


Return to “Ideas & News”

Who is online (over the past 5 minutes)

Users browsing this forum: 1 guest