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