realtime interface to Celestia

[chris]

As an experiment, I modified CELX to allow the current position of an object to be set to an arbitrary position in a CELX Lua script...

One interesting thing I tried with this was programming a test object to be at the position of the (first) observer. In multi-view mode I could watch the object move about in the other views as I moved the observer in the original view. It was very entertaining to view the solar system from high above the sun and watch the test object scoot from planet to planet in respose to goto commands...

- Hank

Cool! That's actually a very useful thing to be able to do . . . Having script orbits will be a nice feature indeed.

--Chris

[Chuft-Captain]

As an experiment, I modified CELX to allow the current position of an object to be set to an arbitrary position in a CELX Lua script. To test it, I wrote a script that sets the position of a test object so that the object is positioned on a line from the earth thru the moon at twice the lunar distance. Then I inserted a hook in Celestia to call the Lua script each time the simulation was updated. It seemed to work.

The Lua code for the test looked roughly like this:

Code: Select all

      earth = celestia:find("Sol/Earth");
      moon = celestia:find("Sol/Earth/Moon");
      moon2 = celestia:find("Sol/Moon2");
      earthPosition = earth:getposition();
      moonPosition  = moon:getposition();
      moonVector  = earthPosition:vectorto(moonPosition);
      moon2Vector = moonVector * 2;
      moon2Position  = earthPosition:addvector( moon2Vector );
      moon2:setposition(moon2Position);



Although this test script positions the object based on the moon's current position, in principle the technique would allow the position of an object to be determined in any way that can be programmed using Lua. For example, the position could be obtained from NASA's SPICE library, a network server, a gravity simulator, etc. And because Lua scripts don't need to be compiled into Celestia, such customized object positioning could be implemented without patching the Celestia application code.

- Hank

Hank,

This could also potentially be the solution to the lack of cyclical events in Celestia!!

If an object's position can be set arbitrarily, then it can be computed and set many times to define a trajectory, and then repeated in a loop. (For example, making a spacecraft travel in a figure of eight.)

The only successful method I've found to move objects, (albeit in very simple trajectories) is thru a bit of an animation hack which creates the illusion that the object is moving.): http://celestiaproject.net/forum/viewtopic.php ... highlight=
There's a couple of downsides to this:
1. Thousands of versions of the same object are created (one for each "frame" of the animation, and then each is "instantiated" at the right moment, which means that because each frame of the animation is actually a new version of the object, it's not really possible to "follow", "sync" or perform any other operations, whether interactive or scripted on the "moving" object (because none of them are actually in motion)

I've always considered this a real hack, but was the only way I found to make an object appear to move with accuracy (XYZ's are not accurate enough for short accurate journey's (eg. docking with other spacecraft) because of the units used, so if your ideas can be used to make the objects really move, then I'll be only too glad to ditch my current methods!!

Will your methods be able to be extended to allow an object's Long/Lat or EllipticalOrbit parameters (or for that matter, any attribute of the object) to be set programatically and with accurate timing?

[Cham]

We urgently need periodic motion in Celestia ! Lets define some arbitrary custom xyz trajectory, and a "repeat" command in the SSC file, so the object repeats the same pattern always and always. Thhis ccould be extremelly usefull. Chris ?

[Chuft-Captain]

We urgently need periodic motion in Celestia ! Lets define some arbitrary custom xyz trajectory, and a "repeat" command in the SSC file, so the object repeats the same pattern always and always. Thhis ccould be extremelly usefull. Chris ?

Hi Cham,

This would be good for interstellar or interplanetary distances, but not for short journeys where meter accuracy is required. (See my comments above)
I do think that Hank's approach has potential if it could be built as a Lua library so that attributes of an object could be easily programmed. (including but not limited to XYZ's I would hope)

I would want to be able to set a periodic motion going in an infinite loop, and then continue to perform all other Celestia operations interactively (ie. follow the object) while the object continues moving independently, but I'm assuming Hank, that your approach will only work under scripting control???

[chris]

We urgently need periodic motion in Celestia ! Lets define some arbitrary custom xyz trajectory, and a "repeat" command in the SSC file, so the object repeats the same pattern always and always. Thhis ccould be extremelly usefull. Chris ?

Yes, it would be useful . . . I'll get to it in the not-to-distant future. I welcome suggestions for how to specify this in an ssc file.

This would be good for interstellar or interplanetary distances, but not for short journeys where meter accuracy is required. (See my comments above)

XYZ orbits should have sub-millimeter accuracy well past the distance of Earth from the Sun. Even at Neptune's distance, double precision numbers are good for specifying distances in millimeters. If they don't, there's a bug in XYZ orbit interpolation.

--Chris

[Cham]

XYZ orbits should have sub-millimeter accuracy well past the distance of Earth from the Sun. Even at Neptune's distance, double precision numbers are good for specifying distances in millimeters. If they don't, there's a bug in XYZ orbit interpolation.

--Chris

I can't tell if there's currently a bug, but I'm presently trying to make a "proton" (1 meter wide !) to follow an xyz trajectory (magnetic path), and it doesn't work ! I don't know why. The time laps are about 0.001 sec, however. Is that the source of my problem ?

The periodic path command would be usefull, for example, to build an accretion bridge from one star to another, in a binary system. The way I see it is to define a path with an xyz file, then use some commands in the SSC file, like this :

SampledOrbit "file.xyz"
RepeatOrbit true

[Chuft-Captain]

We urgently need periodic motion in Celestia ! Lets define some arbitrary custom xyz trajectory, and a "repeat" command in the SSC file, so the object repeats the same pattern always and always. Thhis ccould be extremelly usefull. Chris ?

Yes, it would be useful . . . I'll get to it in the not-to-distant future. I welcome suggestions for how to specify this in an ssc file.

This would be good for interstellar or interplanetary distances, but not for short journeys where meter accuracy is required. (See my comments above)

XYZ orbits should have sub-millimeter accuracy well past the distance of Earth from the Sun. Even at Neptune's distance, double precision numbers are good for specifying distances in millimeters. If they don't, there's a bug in XYZ orbit interpolation.

--Chris

I was using XYZBuilder which may have had problems, or perhaps I was using the wrong frame of reference. Perhaps XYZBuilder had interpolation problems. It was a long time ago that I was doing this, so I don't remember exactly what the problems were, but I do remember that it drove me up the wall.
Actually, I do remember something being said at the time about the interpolation units being light-seconds (in XYZBuilder, not Celestia), which wouldn't make for the greatest accuracy.

RE: periodic motion, if you'd like, I can PM you my thoughts/wish-list once I get them together.

[hank]

I would want to be able to set a periodic motion going in an infinite loop, and then continue to perform all other Celestia operations interactively (ie. follow the object) while the object continues moving independently, but I'm assuming Hank, that your approach will only work under scripting control???

The idea is that you would define a Lua function which computes the position of the object, given a specified time. Celestia would call this function when needed to determine the position of the object.

In principle, the Lua function could calculate the position of the object by any method that can be programmed in Lua. Of course, it needs to be fast in order to maintain Celestia's frame rate. But note that Lua can call C functions, so C code could be used for time critical parts of the position calculation.

The .ssc file for an object with a "ScriptedOrbit" could specify a chunk of Lua code that would return a Lua object with a method for calculating the position of the object. The chunk of Lua code specified in the .ssc file could be a call to a library function that returns a particular kind of orbit based on its input parameters. The user could define various orbit library functions for this purpose, or install such functions (created by others) as add-ons.

This would be a very flexible means of creating customized orbits. Any kind of motion that can be programmed efficiently in Lua/C could be implemented. The only real limitation is the requirement that the position can be calculated quickly for any specified time.

- Hank

[selden]

XYZ orbits should have sub-millimeter accuracy well past the distance of Earth from the Sun. Even at Neptune's distance, double precision numbers are good for specifying distances in millimeters. If they don't, there's a bug in XYZ orbit interpolation.

Are you saying that xyz trajectories are now kept in Celestia as double precision? That would be very good news. I was under the impression that they were single precsision due to storage concerns.

[Chuft-Captain]

The idea is that you would define a Lua function which computes the position of the object, given a specified time. Celestia would call this function when needed to determine the position of the object.

AHA! so it's embedded in Celestia's "event-loop". So the only code-change you'd make in Celestia core code is to add a hook within the event-loop to a function called something like "position_objects()". The question is: what is meant by "when needed". Would this be arbitrarily set to "every frame/cycle", or would you allow the LUA writer discetion to specify the required "granularity" in some way. eg. User may specify "re-calc positions every 1/25th of a second".
Secondly, if this option was allowed, would it be "for all objects" or able to be specified on an "object by object" basis. eg. Object 1 re-calculated very 1/10th sec, Object 2, every 1/25th second.

In principle, the Lua function could calculate the position of the object by any method that can be programmed in Lua. Of course, it needs to be fast in order to maintain Celestia's frame rate. But note that Lua can call C functions, so C code could be used for time critical parts of the position calculation.

I think the fly-in-the-ointment is implied in my comments above. As the number of "periodic objects" is increased by the user, the frame-rate's going to take a hammering due to the overhead of "position_objects()" calls. (it's not as though Celestia's not got enough to do in each cycle already).
I for example, would pretty soon have plenty of these periodic objects, not just one!

The .ssc file for an object with a "ScriptedOrbit" could specify a chunk of Lua code that would return a Lua object with a method for calculating the position of the object. The chunk of Lua code specified in the .ssc file could be a call to a library function that returns a particular kind of orbit based on its input parameters. The user could define various orbit library functions for this purpose, or install such functions (created by others) as add-ons.

I'm not sure if an SSC file is the right place for LUA code.
I think I would prefer not to see a departure from the declarative style of the SSC files, but I think this also implies a generalised and parameter driven "movement" function (perhaps written by an expert like yourself) which would be designed to be efficient, and to interpret the SSC declarations... eg:

Code: Select all

PeriodicMotion
{
    ... some attributes carefully thought out to allow generalised motion
    ... (optionally repeating after a pause period)
}


Tthis would almost certainly have less flexibilty than what you're suggesting, but would arguably be less open to "abuse".

This would be a very flexible means of creating customized orbits. Any kind of motion that can be programmed efficiently in Lua/C could be implemented. The only real limitation is the requirement that the position can be calculated quickly for any specified time.

The downside of providing so much flexibility is that invariably it will not always be programmed efficiently (the aforementioned "abuse". )
Caveat Emptor, I guess.

[chris]

XYZ orbits should have sub-millimeter accuracy well past the distance of Earth from the Sun. Even at Neptune's distance, double precision numbers are good for specifying distances in millimeters. If they don't, there's a bug in XYZ orbit interpolation.

Are you saying that xyz trajectories are now kept in Celestia as double precision? That would be very good news. I was under the impression that they were single precsision due to storage concerns.

Oops . . . I'd forgotten about that. I still need to make a double precision option for xyz files. I'm considering something like this:

SampledOrbit
{
TrajectoryFile "orbit.xyz"
Precision "double"
Periodic true
}

Of course the existing syntax would continue to be supported as well.

--Chris

[hank]

The idea is that you would define a Lua function which computes the position of the object, given a specified time. Celestia would call this function when needed to determine the position of the object.

AHA! so it's embedded in Celestia's "event-loop". So the only code-change you'd make in Celestia core code is to add a hook within the event-loop to a function called something like "position_objects()". The question is: what is meant by "when needed". Would this be arbitrarily set to "every frame/cycle", or would you allow the LUA writer discetion to specify the required "granularity" in some way. eg. User may specify "re-calc positions every 1/25th of a second".
Secondly, if this option was allowed, would it be "for all objects" or able to be specified on an "object by object" basis. eg. Object 1 re-calculated very 1/10th sec, Object 2, every 1/25th second.

Actually, what I have in mind is adding a ScriptedOrbit C++ class to Celesta. It would be a subclass of CachingOrbit that would implement the computePosition virtual method with a method that calls the corresponding method in the Lua object to compute the position. So "when needed" means "when Celestia calls computePosition (from positionAtTime)". The Lua object would also implement the other CachingOrbit virtual functions, getPeriod and getBoundingRadius, which can be used for culling.

In principle, the Lua function could calculate the position of the object by any method that can be programmed in Lua. Of course, it needs to be fast in order to maintain Celestia's frame rate. But note that Lua can call C functions, so C code could be used for time critical parts of the position calculation.

I think the fly-in-the-ointment is implied in my comments above. As the number of "periodic objects" is increased by the user, the frame-rate's going to take a hammering due to the overhead of "position_objects()" calls. (it's not as though Celestia's not got enough to do in each cycle already).
I for example, would pretty soon have plenty of these periodic objects, not just one!

As I just described, the Lua code would be called only when needed, just like built-in orbits. Of course, if you have a lot of objects that can't be culled, calculating their positions will take time.

The .ssc file for an object with a "ScriptedOrbit" could specify a chunk of Lua code that would return a Lua object with a method for calculating the position of the object. The chunk of Lua code specified in the .ssc file could be a call to a library function that returns a particular kind of orbit based on its input parameters. The user could define various orbit library functions for this purpose, or install such functions (created by others) as add-ons.

I'm not sure if an SSC file is the right place for LUA code.
I think I would prefer not to see a departure from the declarative style of the SSC files, but I think this also implies a generalised and parameter driven "movement" function (perhaps written by an expert like yourself) which would be designed to be efficient, and to interpret the SSC declarations... eg:

Code: Select all

PeriodicMotion
{
    ... some attributes carefully thought out to allow generalised motion
    ... (optionally repeating after a pause period)
}


Tthis would almost certainly have less flexibilty than what you're suggesting, but would arguably be less open to "abuse".

The purpose of supporting scripted orbits is so that anyone can do whatever they want to do with them. They're not limited to doing what has been "carefully thought out" by the Celestia developers. One of the goals here is to eliminate the need for "patched" versions of Celestia. That makes maximum flexibility important. In addition, using Lua code simplifies the implementation signifcantly, since the Lua parser can be used. This increases the chances that an implementation might be available sometime soon.

This would be a very flexible means of creating customized orbits. Any kind of motion that can be programmed efficiently in Lua/C could be implemented. The only real limitation is the requirement that the position can be calculated quickly for any specified time.

The downside of providing so much flexibility is that invariably it will not always be programmed efficiently (the aforementioned "abuse". :wink: )
Caveat Emptor, I guess.

You don't have to use the full flexibility that's available if you don't want to. But it's there if you need it. And since Lua code can be shared and modified easily, efficient implementations of useful capabilties will be facilitated. Regardless, inefficient is usually preferable to impossible.

- Hank

[chris]

The idea is that you would define a Lua function which computes the position of the object, given a specified time. Celestia would call this function when needed to determine the position of the object.

AHA! so it's embedded in Celestia's "event-loop". So the only code-change you'd make in Celestia core code is to add a hook within the event-loop to a function called something like "position_objects()". The question is: what is meant by "when needed". Would this be arbitrarily set to "every frame/cycle", or would you allow the LUA writer discetion to specify the required "granularity" in some way. eg. User may specify "re-calc positions every 1/25th of a second".
Secondly, if this option was allowed, would it be "for all objects" or able to be specified on an "object by object" basis. eg. Object 1 re-calculated very 1/10th sec, Object 2, every 1/25th second.

Actually, what I have in mind is adding a ScriptedOrbit C++ class to Celesta. It would be a subclass of CachingOrbit that would implement the computePosition virtual method with a method that calls the corresponding method in the Lua object to compute the position. So "when needed" means "when Celestia calls computePosition (from positionAtTime)". The Lua object would also implement the other CachingOrbit virtual functions, getPeriod and getBoundingRadius, which can be used for culling.

My idea is that the bounding radius and the period (if any) are set in the ssc file so that the cull test can be performed without calling the Lua script at all. Omitting the bounding radius would indicate that the orbit should always be evaluated.

--Chris

[chris]

My idea is that the bounding radius and the period (if any) are set in the ssc file so that the cull test can be performed without calling the Lua script at all. Omitting the bounding radius would indicate that the orbit should always be evaluated.

Responding to myself . . .

But upon thinking about it further, you would want the Lua script to calculate the bounding radius, but it should only do it once on initialization. There would also need to be some way to get the orbit parameters from the SSC file to the Lua script. Otherwise, there's no way to implement a general orbit class with a single script.

--Chris

[hank]

My idea is that the bounding radius and the period (if any) are set in the ssc file so that the cull test can be performed without calling the Lua script at all. Omitting the bounding radius would indicate that the orbit should always be evaluated.

--Chris

As an example, suppose EllipticalOrbit was implemented as a scripted orbit. In the .ssc file you could have something like:

Code: Select all

ScriptedOrbit {
   orbitScript "EllipticalOrbit {
 ? ? ? ? ? ? ? ? ?  ?   Period=0.6152;? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
? ? ? ? ? ? ? ? ? ? ? ? ?  SemiMajorAxis=0.7233;? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
? ? ? ? ? ? ? ? ? ? ? ? ?  Eccentricity=0.0068;
? ? ? ? ? ? ? ? ? ? ? ? ?  Inclination=3.3947;? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
? ? ? ? ? ? ? ? ? ? ? ? ?  AscendingNode=76.681;? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
? ? ? ? ? ? ? ? ? ? ? ? ?  LongOfPericenter=131.533;? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
? ? ?  ? ? ? ? ? ? ? ? ?  MeanAnomaly=181.979;? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
? ? ? ? ? ? ? ? ? ? ? ? ?  Epoch=2452028.18381755;
              }"
}


Since the Lua object could derive the bounding radius from the orbit parameters, It would be convenient if you didn't have to calculate it separately to include explicitly in the .ssc file.

- Hank

[hank]

Here's another possibility for the .ssc file, again using EllipticalOrbit as an example:

Code: Select all

ScriptedOrbit "EllipticalOrbit" {
 ? ? ? ? ? ? ? ? ?  ?   Period 0.6152? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
? ? ? ? ? ? ? ? ? ? ? ? ?  SemiMajorAxis 0.7233? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
? ? ? ? ? ? ? ? ? ? ? ? ?  Eccentricity 0.0068
? ? ? ? ? ? ? ? ? ? ? ? ?  Inclination 3.3947? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
? ? ? ? ? ? ? ? ? ? ? ? ?  AscendingNode 76.681? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
? ? ? ? ? ? ? ? ? ? ? ? ?  LongOfPericenter 131.533? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
? ? ?  ? ? ? ? ? ? ? ? ?  MeanAnomaly 181.979? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
? ? ? ? ? ? ? ? ? ? ? ? ?  Epoch 2452028.18381755

}


The effect would be the same as in the previous example, but in this case the .ssc processor would parse the arguments, build the argument table, and call the specified Lua function ("EllipticalOrbit"), rather than just passing a string containing the call to Lua. It's more work for the .ssc parser, and less flexible for argument specification (no variables or expressions), but more consistent with existing .ssc syntax. In both cases the function would return a Lua object with "computePosition" and "getBoundingRadius" methods. The factory functions (e.g. "EllipticalOrbit") would be defined using preloaded script files.

- Hank

[Chuft-Captain]

Hank,

You've used EllipticalOrbit as the example in both cases however I was wondering if your plan would adapt equally well to objects whose positions are defined in terms of LongLat coordinates instead of orbits.

regards
CC

[hank]

Hank,

You've used EllipticalOrbit as the example in both cases however I was wondering if your plan would adapt equally well to objects whose positions are defined in terms of LongLat coordinates instead of orbits.

regards
CC

I used EllipticalOrbit to illustrate the syntax simply because it's familiar. With a ScriptedOrbit the position could be defined in any way that can programmed in Lua.

- Hank

[chris]

Here's another possibility for the .ssc file, again using EllipticalOrbit as an example:

Code: Select all

ScriptedOrbit "EllipticalOrbit" {
              Period 0.6152                       
              SemiMajorAxis 0.7233               
              Eccentricity 0.0068
              Inclination 3.3947                     
              AscendingNode 76.681                       
              LongOfPericenter 131.533                     
              MeanAnomaly 181.979                     
              Epoch 2452028.18381755

}


The effect would be the same as in the previous example, but in this case the .ssc processor would parse the arguments, build the argument table, and call the specified Lua function ("EllipticalOrbit"), rather than just passing a string containing the call to Lua. It's more work for the .ssc parser, and less flexible for argument specification (no variables or expressions), but more consistent with existing .ssc syntax. In both cases the function would return a Lua object with "computePosition" and "getBoundingRadius" methods. The factory functions (e.g. "EllipticalOrbit") would be defined using preloaded script files.

It wouldn't be difficult at all to make the ssc parser to convert ssc values to Lua values. I think that this is the approach we should adopt. One additional bit of flexbility that would seem useful is the ability to specify a script file that contains the specified Lua function. Otherwise, you have to make certain that the script that defined (in your example) "EllipticalOrbit" had already been loaded, and add-on with script orbits couldn't be completely self-contained. A 'ScriptFile' field could do the trick . . . Celestia could track what had already been loaded so that the same file wouldn't get loaded twice.

--Chris

[hank]

One additional bit of flexbility that would seem useful is the ability to specify a script file that contains the specified Lua function. Otherwise, you have to make certain that the script that defined (in your example) "EllipticalOrbit" had already been loaded, and add-on with script orbits couldn't be completely self-contained. A 'ScriptFile' field could do the trick . . . Celestia could track what had already been loaded so that the same file wouldn't get loaded twice.

--Chris

Celestia wouldn't need to track what had already been loaded if it used Lua's "require" function to load the script.

- Hank