Object Timeline proposal

[Cham]

Ok, the [] aren't a concern anyway. I was just asking. We already have some commands which are using [] :

Code: Select all

Color [x x x]
Orientation [x x x]
etc...

[scaddenp]

Dont see ability to modify texture on the timeline? That would be good.

[Chuft-Captain]

Sorry I haven't had time to follow this thread, but there is one thing that has occurred to me.

With regard to the use of absolute times within a Timeline:

Unless I've missed something, it seems to me that the use of absolute times within your implementation makes it incompatible with any future plans for Periodic Motion.

An idea I'd like you to consider is to use durations instead of absolute times in the Timeline (or find some other way to make it time-independent).
This would make it possible for a timeline to be used in conjunction with some sort of Periodic Motion construct (when that's finally specified).

eg. I can imagine that in the future quite complex repetitive motions could be specified by enclosing a Timeline within a Periodic Motion, where the Begin/End Times (and subsequent repetition behaviour) are specified as part of the Periodic Motion construct, whereas the Timeline construct is independent of any specific absolute time.

If you're serious about implementing Periodic Motion in the future, then IMO you should be avoiding using absolute times in any new constructs such as this.

[buggs_moran]

That actually makes a whole bunch of sense to me as well and it is similar to Toti's concept.

If we define a Beginning and then for each phase define a span of time, in seconds perhaps, future periodic installations would be easy. Maybe you could even leave off a beginning as you have left off the ending date for infinite time... I imagine the software could easily figure the dates given a span rather than an actual date...

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"
       Span "259200" # was Ending "2008 2 21"
   }

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

OR

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
         {
              Span "227032440" # was Beginning "2004 12 25 02:01"
              OrbitFrame { EclipticJ2000 { Center "Sol/Saturn/Titan" } }
              SampledTrajectory { ... }
              BodyFrame { EclipticJ2000 { } }
              SampledOrientation { ... }
          }

     etc..

     ]

[/b]

[chris]

Sorry I haven't had time to follow this thread, but there is one thing that has occurred to me.

With regard to the use of absolute times within a Timeline:

Unless I've missed something, it seems to me that the use of absolute times within your implementation makes it incompatible with any future plans for Periodic Motion.

An idea I'd like you to consider is to use durations instead of absolute times in the Timeline (or find some other way to make it time-independent).
This would make it possible for a timeline to be used in conjunction with some sort of Periodic Motion construct (when that's finally specified).

eg. I can imagine that in the future quite complex repetitive motions could be specified by enclosing a Timeline within a Periodic Motion, where the Begin/End Times (and subsequent repetition behaviour) are specified as part of the Periodic Motion construct, whereas the Timeline construct is independent of any specific absolute time.

If you're serious about implementing Periodic Motion in the future, then IMO you should be avoiding using absolute times in any new constructs such as this.

The Timeline isn't intended to be a general system for animation. It is intended to describe significant changes in the positioning of an object over its lifetime, thus eliminating the need to use multiple SSC bodies to represent a single entity.

I recognize that Celestia needs some sort of system for general animation, but that's not what the Timeline is really for. For animation, I think we should look to incorporate some sort of existing technology into Celestia. There's OpenFlight, COLLADA, Open Scene Graph, or perhaps the Orbiter file format. All of these support articulated models. Alternately, the cmod format could be extended to support animation (and a tool to convert from other formats written.) Also, there would need to be a mechanism for connecting Celestia's clock to the internal timeline of the mesh.

That said, if you want to do animation using independent SSC objects, you still can. The addition of a periodic sampled trajectories and orientations might help a lot. Mathieu Joubert from CNES and Selden have already done incredible things using ScriptedOrbits. These are both special cases though: the positions and orientations are coming from a simulator in the CNES app, and the Hale animations are dependent on the position of the currently selected object. I think that for less specialized animations, it would be easier to have the animation description in the model file rather than the SSC. The articulated parts of a model could be much 'lighter weight' than ssc objects. More importantly, much of the animation could be composed within modeling software instead of with a text editor.

--Chris

[Fenerit]

Fantastic!

[Chuft-Captain]

Sorry I haven't had time to follow this thread, but there is one thing that has occurred to me.

With regard to the use of absolute times within a Timeline:

Unless I've missed something, it seems to me that the use of absolute times within your implementation makes it incompatible with any future plans for Periodic Motion.

An idea I'd like you to consider is to use durations instead of absolute times in the Timeline (or find some other way to make it time-independent).
This would make it possible for a timeline to be used in conjunction with some sort of Periodic Motion construct (when that's finally specified).

eg. I can imagine that in the future quite complex repetitive motions could be specified by enclosing a Timeline within a Periodic Motion, where the Begin/End Times (and subsequent repetition behaviour) are specified as part of the Periodic Motion construct, whereas the Timeline construct is independent of any specific absolute time.

If you're serious about implementing Periodic Motion in the future, then IMO you should be avoiding using absolute times in any new constructs such as this.

The Timeline isn't intended to be a general system for animation. It is intended to describe significant changes in the positioning of an object over its lifetime, thus eliminating the need to use multiple SSC bodies to represent a single entity.

I recognize that Celestia needs some sort of system for general animation, but that's not what the Timeline is really for. For animation, I think we should look to incorporate some sort of existing technology into Celestia. There's OpenFlight, COLLADA, Open Scene Graph, or perhaps the Orbiter file format. All of these support articulated models. Alternately, the cmod format could be extended to support animation (and a tool to convert from other formats written.) Also, there would need to be a mechanism for connecting Celestia's clock to the internal timeline of the mesh.

That said, if you want to do animation using independent SSC objects, you still can. The addition of a periodic sampled trajectories and orientations might help a lot. Mathieu Joubert from CNES and Selden have already done incredible things using ScriptedOrbits. These are both special cases though: the positions and orientations are coming from a simulator in the CNES app, and the Hale animations are dependent on the position of the currently selected object. I think that for less specialized animations, it would be easier to have the animation description in the model file rather than the SSC. The articulated parts of a model could be much 'lighter weight' than ssc objects. More importantly, much of the animation could be composed within modeling software instead of with a text editor.

--Chris

I think we have a mis-understanding here...

When I refer to Periodic Motion, I'm not meaning animation, but rather the ability to repeat an XYZ journey. Currently XYZ's contain absolute times (as does your new Timeline feature). Consequently, both XYZ events and Timeline events can only occur at the specified times.

What I suggested in the Periodic Motion thread is the removal of the dependence on absolute time within the XYZ file itself (which would allow the XYZ journey to be periodically repeated according to a regime specified in the SSC definition of the associated object).

I'm simply pointing out in this thread that it may be a good idea to also remove any time dependence from Timelines as well, in order to give more flexibility in their use and possible applications.

I'm anticipating for example that a Timeline might be embedded within a Periodic Motion construct...(the Timeline providing the capability to change reference frames within different phases of the journey, whilst the Periodic Motion construct would provide the ability to repeat the whole journey according to some regime).
It occurs to me that an individual phase of the Timeline might also be subject to repetition.

This is all theoretical at this stage, however the point is that within any future Periodic Motion construct, in order to be repeatable, events will need to be specified in terms of relative, rather than absolute time.
(If this is done for XYZ's alone, then it would enable the periodic sampled trajectories you refer to above I think).

Sorry, this seems a little off-topic, but really all I was originally suggesting is that Timelines might also benefit in terms of flexibility (and compatibility with periodically sampled XYZ's), in the same way as XYZ's would by the removal of absolute times.

CC

PS. I don't know enough about ScriptedOrbits etc. at this stage, so I'm not sure if they address the same issue.

[selden]

CC,

A ScriptedOrbit (ScriptedRotation) function is called with a time and must return a position (orientation). That position (orientation) is relative to the OrbitFrame (BodyFrame) of the body for which it is called.

Whether it's periodic or not is up to the author of the function.

[chris]

I think we have a mis-understanding here...

When I refer to Periodic Motion, I'm not meaning animation, but rather the ability to repeat an XYZ journey. Currently XYZ's contain absolute times (as does your new Timeline feature). Consequently, both XYZ events and Timeline events can only occur at the specified times.

But animation is the point of periodic motion, is it not?

What I suggested in the Periodic Motion thread is the removal of the dependence on absolute time within the XYZ file itself (which would allow the XYZ journey to be periodically repeated according to a regime specified in the SSC definition of the associated object).

What you're asking for in xyz files could be accomplished by making two additions to SampledTrajectory: a boolean Repeat flag, and a TimeBase property. TimeBase would specify a Julian date which is added to each time in the xyz file. This could be useful in situations that don't use periodic motion at all. For example, you could use MJD (modified Julian days) in an xyz file instead of Julian days by specifying TimeBase 2400000.5. Other useful base times might be J2000.0 or mission start time.

I'm simply pointing out in this thread that it may be a good idea to also remove any time dependence from Timelines as well, in order to give more flexibility in their use and possible applications.

I'm anticipating for example that a Timeline might be embedded within a Periodic Motion construct...(the Timeline providing the capability to change reference frames within different phases of the journey, whilst the Periodic Motion construct would provide the ability to repeat the whole journey according to some regime).

That is not the intended usage of Timeline. Something like Buggs' proposed Span property might be quite useful as an alternative to specifying the end time of a phase, but the Beginning definitely must be an absolute date. What else could it be?

It occurs to me that an individual phase of the Timeline might also be subject to repetition.

Again, what it sounds like you're asking for is for Timeline to be the foundation for some sort of animation system. And while I agree that improved animation support would indeed be useful, I maintain that there are better ways to do it than complicating the ssc file format.

--Chris

[Brendan]

This would also be useful for the Galileo probe and its atmospheric probe.

[buggs_moran]

That is not the intended usage of Timeline. Something like Buggs' proposed Span property might be quite useful as an alternative to specifying the end time of a phase, but the Beginning definitely must be an absolute date. What else could it be?

I agree that there must be some beginning since you cannot have a span take place or intervals happen without one. I can see a definite use for timeline information in a ssc that pertains to radius and other ssc declarations... I have always wanted to do variable stars. The AAVSO has mountains of data that could easily be parsed by one of Fridger's programs or even one of my half-baked excel-word merge files to create timelines for many well known variables. In this case the timeline would definitely have to have a periodic function and involve the use of spans without any end date. Radius would have to be included in the timeline code which is one reason I would lobby for anything in a ssc to be able to be in a timeline bracket [ ]. I don't know if this is a programming nightmare, but if you can make an entire addon disappear with an Ending, why not have anything within an ssc be changeable.

I always envisioned roche lobe filling stars and variables being one of those "scientific" and "educaitonal" uses for Celestia... Of course, to get the luminosity to vary (the only scientifically known variable in variable stars), stc files would need the timeline added to it as well for magnitude...

For instance

Code: Select all

"Variable" "some star"
{
Emissive   true

Timeline
[
# First Observation
  {
       Beginning "1880 1 1"
   }

# Minimum
  {
       Mesh "sphere.cmod"
       Texture   "minimum.*"
       Radius   484e6    
       Span "14299200"
   }
# Maximum
  {
       Mesh "lobefilled.cmod"       
       Texture   "maximum.*"
       Radius   486e6    
       Span "14299200"
   }

]

   EllipticalOrbit {
      Period 1e10
      SemiMajorAxis 1e-10
      }

RotationPeriod   1000
}


[Chuft-Captain]

Hi Chris,
Bear in mind that I haven't got the Timeline code in my build so I may be misunderstanding it's usage to some degree, but anyway I'll try to make sense.

Here goes...

I think we have a mis-understanding here...

When I refer to Periodic Motion, I'm not meaning animation, but rather the ability to repeat an XYZ journey. Currently XYZ's contain absolute times (as does your new Timeline feature). Consequently, both XYZ events and Timeline events can only occur at the specified times.

But animation is the point of periodic motion, is it not?

Strictly speaking, yes. ... but I was just pointing out that anything with embedded absolute times (current XYZ's , Timelines), would not be repeatable, so I felt that it might be a good idea to avoid absolute times in all places except at the top-level of an object definition. -- Any sub-ordinate absolute times required by the engine could then be derived from the simple mathematical accumulation of relative offsets from durations in XYZ's or Timelines constructs, etc...

Anyway, as Selden suggests it seems that XYZ's can be replaced by a ScriptedOrbit. This should be fairly straightforward for simple trajectories, however for the situations I'm considering (eg. A repeating and reversing trajectory involving several separate phases of constant or variable acceleration/deceleration in a straight-line (Y-axis) or in a circular curve (X and Y axes) where the distance traveled is a pre-determined constraint), the factory function will be non-trivial (and maybe cannot be solved analytically).

I'll have a go at this ScriptedOrbit approach, but I very much doubt that this will be efficient for the complex trajectories I'm thinking of due to the amount of work the factory function will have to do in each call.
It would be more elegant if I could break it into several simpler pieces...In Lua, is it possible to have multiple factory functions in a single module and pass the results of one functions calculation as an input into another function, either iteratively or recursively???

What I suggested in the Periodic Motion thread is the removal of the dependence on absolute time within the XYZ file itself (which would allow the XYZ journey to be periodically repeated according to a regime specified in the SSC definition of the associated object).

What you're asking for in xyz files could be accomplished by making two additions to SampledTrajectory: a boolean Repeat flag, and a TimeBase property. TimeBase would specify a Julian date which is added to each time in the xyz file. This could be useful in situations that don't use periodic motion at all. For example, you could use MJD (modified Julian days) in an xyz file instead of Julian days by specifying TimeBase 2400000.5. Other useful base times might be J2000.0 or mission start time.

Sounds like a good idea... similar to what I suggested in the Periodic Motion thread, except that I was assuming the TimeBase of an XYZ would always be "inherited" from the BeginDate (ie. mission start date) of the object using the XYZ. As long as the Timebase is specified in the SSC and not in the XYZ (ie. XYZ times are zero-based), then I don't see any problems.

One proviso: I think that rather than a boolean flag... maybe 2 variables would be more useful:
1. an integer NumRepeats variable (default 1)
2. A PausePeriod --- time between end of previous interation and the beginning of the next repeat of the trajectory (Object would not be rendered during this time) -- default zero of course.

I'm simply pointing out in this thread that it may be a good idea to also remove any time dependence from Timelines as well, in order to give more flexibility in their use and possible applications.

I'm anticipating for example that a Timeline might be embedded within a Periodic Motion construct...(the Timeline providing the capability to change reference frames within different phases of the journey, whilst the Periodic Motion construct would provide the ability to repeat the whole journey according to some regime).

That is not the intended usage of Timeline. Something like Buggs' proposed Span property might be quite useful as an alternative to specifying the end time of a phase, but the Beginning definitely must be an absolute date. What else could it be?

Yes of course, but surely specifying an absolute Beginning Time can be done once only (at object level), and then inherited into any enclosed Timelines (and any referenced zero-timebased XYZ's).

PS. I haven't considered the implications of Buggs Span property as yet. I'll try to get my head around that next.

It occurs to me that an individual phase of the Timeline might also be subject to repetition.

Again, what it sounds like you're asking for is for Timeline to be the foundation for some sort of animation system. And while I agree that improved animation support would indeed be useful, I maintain that there are better ways to do it than complicating the ssc file format.

--Chris

No, I was not suggesting the Timeline should be the foundation for animation, but simply that by zero-timebasing Timelines (in principle the same as what you suggest for XYZ's above) you would have the option of enclosing an entire Timeline within another construct (which would be the foundation for repetition).

However, on reflection, it may be good enough to simply implement zero-timebasing of XYZ's and allow the Celestia engine to add the TimeBase of an object or Timeline phase to the zero-based XYZ times, and forget about trying to zero-base the Timelines, if you feel that would complicate the SSC's.
I actually felt that it would simplify it, as there wouldn't be all these separate absolute times al over the place. (Just the one : the mission start (Timebase) of the object.

[volcanopele]

I tried playing around with this new code in my Galileo add-on but it either fails or Celestia crashes. Here is a bit from my ssc. Io, Ganymede, Europa, Callisto, and Amalthea have similar code:

Code: Select all

Modify "Jupiter" "Sol"
{
   Timeline
   [
      # Before Galileo
      {
         CustomOrbit "vsop87-jupiter"
         EllipticalOrbit
         {
            Period           11.8622
            SemiMajorAxis     5.2034
            Eccentricity      0.0484
            Inclination       1.3053
            AscendingNode   100.556
            LongOfPericenter 14.7539
                 MeanLongitude    34.404
         }
         Ending    "1995 11 22 00:00"
      }

      # Galileo Mission
      {
         OrbitFrame { EclipticJ2000 { Center "Sol/JupSSBary/Jupiter_bary"}}
         BodyFrame
         {
            MeanEquator
            {
               Center "Sol/JupSSBary/Jupiter_bary"
                }
         }
         Ending    "2003 09 30 00:00"

         SpiceOrbit
         {
            Kernel "galileo_traj.bsp"
                        Target "599"
                      Origin "5" 
            Ending    "2003 09 30 00:00"

            BoundingRadius 1e10
         }
      }
      
      # After Galileo
      {
         CustomOrbit "vsop87-jupiter"
         EllipticalOrbit
         {
            Period           11.8622
            SemiMajorAxis     5.2034
            Eccentricity      0.0484
            Inclination       1.3053
            AscendingNode   100.556
            LongOfPericenter 14.7539
                 MeanLongitude    34.404
         }
      }
   ]

}


I am using SVN 4220 on a Windows XP machine.[/code]

[volcanopele]

WOOTAGE!!! I just needed to add beginning statements to the second and third orbit definitions.

[chris]

WOOTAGE!!! I just needed to add beginning statements to the second and third orbit definitions.

It's not good that Celestia was crashing, however . . . I'll try and figure out what the problem is. Is there somewhere I can get the file galileo_traj.bsp for testing?

You can simplify the object definition somewhat by removing the EllipticalOrbits: the VSOP87 CustomOrbits override them. They're present in solarsys.ssc just to give anyone looking at in an idea of the mean orbital elements.

The BodyFrame can probably be omitted as well. Unless maybe I'm missing something--was there something wrong with Jupiter's orientation without it?

Finally, recent versions of Celestia can automatically determine the coverage window for SPICE orbits, so if Celestia is working right, you probably don't need to specify either the beginning or ending inside the SpiceOrbit block. The exception is when the bsp file contains noncontiguous coverage for an object: in this case, you need to tell Celestia which (continuous) span to use.

--Chris

[volcanopele]

Okay, it wasn't working as perfectly as possible. How this SHOULD work is that prior to the Galileo mission, Jupiter and its satellites orbit according to the Custom Orbit, the first orbit definition in the timeline. During the Galileo mission, between November 1995 and September 2003, Jupiter and its satellites orbit around the Jupiter system barycenter (that itself orbits around the solar system barycenter) in accordance with information from a spice kernel file. After September 2003, Jupiter and its satellites should return to the CustomOrbit.

But something happens with this that causes Galileo to orbit the Jupiter system barycenter and Jupiter on the other side of the Solar system.

[chris]

Okay, it wasn't working as perfectly as possible. How this SHOULD work is that prior to the Galileo mission, Jupiter and its satellites orbit according to the Custom Orbit, the first orbit definition in the timeline. During the Galileo mission, between November 1995 and September 2003, Jupiter and its satellites orbit around the Jupiter system barycenter (that itself orbits around the solar system barycenter) in accordance with information from a spice kernel file. After September 2003, Jupiter and its satellites should return to the CustomOrbit.

But something happens with this that causes Galileo to orbit the Jupiter system barycenter and Jupiter on the other side of the Solar system.

What you posted should work, though it depends on exactly how JupSSBary and Jupiter_bary are defined. I'm looking at it right now, substituting de405.bsp for jupiter_traj.bsp.

--Chris

[chris]

This works perfectly for me:

Code: Select all

Modify "Jupiter" "Sol"
{
   Timeline
   [
      # Before Galileo
      {
         CustomOrbit "vsop87-jupiter"
         Ending    "1995 11 22 00:00"
      }

      # Galileo Mission
      {
         OrbitFrame { EclipticJ2000 { Center "SSB" } }

         SpiceOrbit
         {
            Kernel "de405.bsp"
            Target "5"
            Origin "0"
            BoundingRadius 1e9
         }

         Ending    "2003 09 30 00:00"
      }
     
      # After Galileo
      {
         CustomOrbit "vsop87-jupiter"
      }
   ]

}


Note that I'm using the DE405 SPICE kernel to position Jupiter relative to the Solar System barycenter. However, I'm just putting Jupiter at the position of it's barycenter, so I don't have the same frame hierarchy that you do. So, I'm guessing the problem is in the definition of JupSSBary or Jupiter_bary, though without more info I can't say whether it's in your add-on or in Celestia.

--Chris

[volcanopele]

This is my current Jupiter Timeline mod:

[code]Modify "Jupiter" "Sol"
{
Timeline
[
# Before Galileo
{
CustomOrbit "vsop87-jupiter"
Ending "1972 01 02 00:00"
}
# JUP256
{
OrbitFrame { EclipticJ2000 { Center "Sol/JupSSBary/Jupiter_bary"}}
BodyFrame
{
MeanEquator
{
Center "Sol/JupSSBary/Jupiter_bary"
}
}
Ending "2000 01 02 00:00"

SpiceOrbit
{
Kernel "jup256.bsp"
Target "599"
Origin "5"

BoundingRadius 1e10
}
}

# JUP230
{
OrbitFrame { EclipticJ2000 { Center "Sol/JupSSBary/Jupiter_bary"}}
BodyFrame
{
MeanEquator
{
Center "Sol/JupSSBary/Jupiter_bary"
}
}
Ending "2049 12 31 00:00"

SpiceOrbit
{
Kernel "jup230.bsp"
Target "599"
Origin "5"

BoundingRadius 1e10
}
}

# After Galileo
{
CustomOrbit "vsop87-jupiter"
}
]

}
[/code]
The Galileans and Amalthea have a similar code. Here, basically Jupiter is defined by VSOP until 1972 where it is defined by one spice kernel, then by another spice kernel from 2000-2050, then by VSOP again. The Galileans and Amalthea are defined by one spice kernel from 1995-2000 then by another from 2000-2050 and CustomOrbit all other times.

Using the above template, Jupiter ceases orbiting the sun when the switch over occurs in 1972 and starts up again in 2050. The Galileans and Amalthea cease orbiting Jupiter in 1995 and start back up again in 2050.

The code for Jupiter_Bary:

[code]"Jupiter_bary" "Sol/JupSSBary"
{
Class "planet"
Color [1 1 1]
Radius 10

Beginning "1899 07 30 00:00"
Ending "2053 10 08 00:00"

OrbitFrame { EclipticJ2000 { Center "Sol/JupSSBary"}}

SpiceOrbit
{
Kernel "de421.bsp"
Target "5"
Origin "0"
BoundingRadius 1e10
}

Obliquity 2.222461 # 1.82246 # 2.22246
EquatorAscendingNode -22.203 # -1.87785 # -22.203

}[/code]

and JupSSBary
[code]"JupSSBary" "Sol"
{
Color [ 1 1 1 ]
Radius 10

OrbitFrame { EclipticJ2000 { Center "Sol"}}
FixedPosition [ 0 0 0]
BodyFrame { BodyFixed { Center "Sol"}}
FixedRotation {}

Beginning "1899 07 30 00:00"
Ending "2053 10 08 00:00"


SpiceOrbit
{
Kernel "de421.bsp"
Target "0"
Origin "10"

BoundingRadius 1e10
}


}[/code]

I thought putting in beginning statements might help, but that just made Celestia ignore what I put in the Timeline array.

[volcanopele]

The BodyFrame parameter is used to ensure the object in question rotates.