I've decided that the "pause" statement I suggested in the above thread is not really nescessary as I think it can be allowed for with a cleaner implementation as follows...
This is what I think is needed to cover just about any situation requiring periodic motion (tell me if you disagree):
1. Decoupling of Absolute Time: Trajectory files should contain relative time offsets, rather than absolute times. (The first position would be time 0)
This means that the trajectory is not tied to a specific time, but may be used at any time. (the absolute time to be calculated by Celestia "on the fly" so to speak, by adding the offset to the beginning time of the iteration.
2. Reusablility: Any object can use the trajectory file at any time, and multiple times. The same trajectory can be used by different objects.
The first iteration occurs at the Beginning Date of the specific object, and is repeated at a specified interval until the End Date of the object.
3. Visibility: If the XYZ trajectory completes before the end-date, the object may optionally automatically disappear. (until the next iteration, at which time it will appear automatically again at the start-point) - This allows the pause functionality I referred to in the other post. ie. although the object's EndDate hasn't expired, it's not on a trajectory, so it's not visible. This should be the default behaviour (IMO). The other option would be to have it remain visible at the end-point of the trajectory.
Examples...
Obj1 first begins the trajectory at lunchtime Jan01 2001, repeats exactly a year later, and is visible between iterations.
Code: Select all
"Obj1" "Sol"
{
Beginning "2001 01 01 12:00:00"
Ending "2002 06 30 12:00:00"
SampledOrbit
{
TrajectoryFile "orbit.xyz"
Precision "double"
Repeat "0001 00 00 00:00:00" # Repeat once a year
RemainVisible true
}
}
Obj2 follows the same trajectory as Obj1, startin 1 hour later, repeats it every day for a year, and is not visible between iterations.
Code: Select all
"Obj2" "Sol"
{
Beginning "2001 01 01 13:00:00"
Ending "2002 01 01 13:00:00"
SampledOrbit
{
TrajectoryFile "orbit.xyz"
Precision "double"
Repeat "0000 00 01 00:00:00" # Repeat at the same time every day
RemainVisible false
}
}Obj3 begins 1hour 15m after Obj2, repeats the trajectory every 35 mins 30.61 secs forever, and is not visible between iterations.
Code: Select all
"Obj3" "Sol"
{
Beginning "2001 01 01 14:15:00"
SampledOrbit
{
TrajectoryFile "orbit.xyz"
Precision "double"
Repeat "0000 00 00 00:35:30.61" # Repeat every 35 mins 30.61 secs
}
}(NOTE: Depending on the duration of the trajectory, and the specified repeat period, and end-date of the object, any particular iteration of the trajectory may or may not be completed EDIT: (or started in fact).)
ISSUES/CONCERNS:
1. If the repeat period is shorter than the [edit:duration of the journey] specified in the trajectory file, this implies that the same object could exist at 2 different positions at the same time. This would have implications on tracking/selecting etc. so will have to be handled somehow -- any suggestions???
2. The replacement of absolute times with relative times implies that any object using periodic motion defined this way, would have to have at least a Beginning time specified (else Celestia cannot calculate the iteration times). Perhaps, the Beginning and Ending times used should be attributes of the "SampledOrbit", but this could conflict (or be incompatible) with the Object Begin/End times. EDIT: I suppose Celestia could default to using the time at start-up as a default Beginning Date for objects where it hasn't been specified (ie. when you just want the periodic motion and not too worried about the exact time that it begins)
3. Format of the Repeat statement - It might be more practical to allow the repeat period to be specified in a single unit of time only (eg. seconds), instead of, or in addition to, the "YYYY MM DD hh:mm:ss" format. (perhaps time UNITS to be specified in the SSC as well??). (On the other hand, this may be less practical depending on your opinion)
Any opinions on this??
GOING FURTHER WITH THIS IDEA
Extensibility I think this motion paradigm could also be applied to attributes which use coordinate systems other than XYZ (although this would probably require some new filetypes analogous to XYZ's for those attributes), so maybe this paradigm should be applied to attribute's rather than (or as well as) to the objects themselves.
I'm suggesting a general purpose method to dynamically vary currently static attributes.
eg. Long/Lat/Altitude - this would allow simulation of Lunar Rover or Mars Sojourner journeys. [EDIT: of course this can probably be achieved currently by converting LongLat's to XYZ's, but it's going to be less time-consuming to get Celestia do the conversion in C++ ]
eg. Orientation - animation of repetitive spacecraft movements such as solar panel deployments etc.
Sorry, I'm not in a position to contribute any coding effort, so you'll have to make do with my thoughts/ideas.
Any comments or criticisms?
CC
