realtime interface to Celestia

[Apollonian]

The XYZQ format will be wonderful. I hope everyone gets the bugs worked out.

As per recent discussion at work, if Celestia can somewhat accurate attitude dynamics, you may start seeing it more as a professional visualization tool!

viva la open source

[RocketMan@JSC]

Just thought I would bring you guys up to date on the shuttle/external tank separation visualization task. Remember I took tec's baseline code and pulled in the necessary changes to add orientation. I made several changes, the most notable being the reference frame. Apparently tec's frame is rotating where we prefer inertial. Nothing wrong with that, just preferences. Overall everything is working and it's cool to see the external tank, fall away and then the orbiter pitch over to get a better view from the overhead windows. There is some jitter between the two vehicles and we are working to remove that. Time syncing the data helps tremendously. It's also good to know that STK has the same issue when the data is out of sync.

1) I've sorted out all the orientation issues and we now feed Celestia a new data file format that we came up with, the file extension "*.rvq"--I like it cause it has a nice ring to it. Yep, you guessed it: range from central body, velocity, and attitude quaternion all in the J2k inertial reference frame. Not sure if we will end up with this format but it has everything that is needed.

2) We are experimenting with different position interpolation routines: linear, cubic and keplerian.

3) Tec's slerp routine to interpolate quaternions will work fine, it just needs a little tweak to avoid the big spinning around when the angle between them is > 90 deg. All you do is take the dot product of the two quaternions, q1 and q2. If it is less than zero, then use -q2 in the interpolation.

4) Celx seems to be doing most of what we need but we may need to add a few things to allow camera orientation to update and change when the vehicle orientation changes.

That's it for now.

[Joe]

Just thought I would bring you guys up to date on the shuttle/external tank separation visualization task.

It sounds very cool and highly technical. Does your visualization of the tank separation requires networks support or can it work standalone? I had tried with tec's code and was hoping to make the solar panels of spacecrafts gradually folding out while they are orbiting, but with not much success. Your work is very encouraging .

[phoenix]

...
Well, it seems there has not been more posts on this useful feature in this forum though I would hope it deserves more discussion.

Why?


I am still waiting to see some concrete applications (not words) that are of major interest to a larger sub-community of people. Personally I think the real time code is a too specific application to be part of Celestia's core code. If there was an implementation via scripting (lua) this would look much more appropriate to me.

Bye Fridger

well, i am certainly going to use some parts of that code for my game-project based on celestia
although i didn't think of realtime-udp connections rather than http-requests.

i think the realtime-celestia has great potential.
how about a central-server application receiving and sending instructions to any celestia-client connected?

[chris]

Just thought I would bring you guys up to date on the shuttle/external tank separation visualization task. Remember I took tec's baseline code and pulled in the necessary changes to add orientation. I made several changes, the most notable being the reference frame. Apparently tec's frame is rotating where we prefer inertial. Nothing wrong with that, just preferences. Overall everything is working and it's cool to see the external tank, fall away and then the orbiter pitch over to get a better view from the overhead windows. There is some jitter between the two vehicles and we are working to remove that. Time syncing the data helps tremendously. It's also good to know that STK has the same issue when the data is out of sync.

1) I've sorted out all the orientation issues and we now feed Celestia a new data file format that we came up with, the file extension "*.rvq"--I like it cause it has a nice ring to it. Yep, you guessed it: range from central body, velocity, and attitude quaternion all in the J2k inertial reference frame. Not sure if we will end up with this format but it has everything that is needed.

Thanks for the update . . .

I'm very interested in supporting this file format (or something close to it) in Celestia. I'd had the idea of using a second file for orientation rather than including it with the trajectory, but either approach could work. Why is it necessary to include the velocity? For better interpolation?

2) We are experimenting with different position interpolation routines: linear, cubic and keplerian.

Celestia currently uses cubic interpolation for trajectories.

3) Tec's slerp routine to interpolate quaternions will work fine, it just needs a little tweak to avoid the big spinning around when the angle between them is > 90 deg. All you do is take the dot product of the two quaternions, q1 and q2. If it is less than zero, then use -q2 in the interpolation.

There's also a slerp function in Celestia's quaternion class that you could use.

4) Celx seems to be doing most of what we need but we may need to add a few things to allow camera orientation to update and change when the vehicle orientation changes.

Please post your suggestions here . . .

--Chris

[RocketMan@JSC]

Thanks for the update . . .

I'm very interested in supporting this file format (or something close to it) in Celestia. I'd had the idea of using a second file for orientation rather than including it with the trajectory, but either approach could work. Why is it necessary to include the velocity? For better interpolation?

Yes, we were hoping better interpolation would remove the jitter for the second vehicle. Currently if the shuttle is being followed, the ET (external tank) will jump about--not a lot but enough to notice. I was hoping a kepler based interpolation would remove this but it does not. Apparently the best way will be to ensure both that both vehicle data sets are generated at the same times--it worked for STK so I'm hoping it will work here also.

Even though the velocity may not be needed for some interpolations, the proper thing to do is include velocity in the state vector.

4) Celx seems to be doing most of what we need but we may need to add a few things to allow camera orientation to update and change when the vehicle orientation changes.

Please post your suggestions here . . .

I've added the ability to retrieve a vehicle's orientation via the lua interface. Unfortunately the orientation needs to be in a universal frame, not the frame used in the rvq file. The reason we want this is to automatically position the camera view based upon the orbiter orientation.
As the orbiter moves, the umbilical camera and overhead window views need to move with it.

I have yet to figure out how to convert to this frame this in the code--mostly haven't had the time to dig into it.

Another good option for the rvq file is to add an input into the ssc file that will allow using different types of frames for the rvq data. I have already added an option to display inertial j2k axes on any body (except the sun and stars). Also, when using rvq files, I have used the existing ssc Orientation parameter to perform an offset rotation to correct the image model orientation to the proper body frame. Sometimes the cad models are not built on the proper vehicle body frame and an offset rotation is necessary.

Scott

[chris]

Thanks for the update . . .

I'm very interested in supporting this file format (or something close to it) in Celestia. I'd had the idea of using a second file for orientation rather than including it with the trajectory, but either approach could work. Why is it necessary to include the velocity? For better interpolation?

Yes, we were hoping better interpolation would remove the jitter for the second vehicle. Currently if the shuttle is being followed, the ET (external tank) will jump about--not a lot but enough to notice. I was hoping a kepler based interpolation would remove this but it does not. Apparently the best way will be to ensure both that both vehicle data sets are generated at the same times--it worked for STK so I'm hoping it will work here also.

Even though the velocity may not be needed for some interpolations, the proper thing to do is include velocity in the state vector.

Could the jittering be caused by floating point precision issues?

As for velocity, I think it should definitely be an optional part of trajectory files--they double the amount of memory consumed.

I looked at a bit at tec's descriptions of his changes to Celestia. I'd like to suggest that orientation kept separate from the Orbit classes. I think it would be cleaner to have separate Rotation and Orbit class hierarchies, so that different types of orbits and rotations could be arbitrarily combined.

In my design, there's a new base class called ObjectRotation (or something like that) with three subclasses:
SimpleRotation (what we've got now)
CustomRotation (hardcoded functions, akin to the CustomOrbits for planets and major satellites; definitely useful for Earth's rotation, precession, and nutation)
SampledRotation (like a sampled orbit; could use an rvq file as a source or perhaps a file with just quaternions)
And eventually SpiceCKRotation . . . The .ssc format would be expanded so that the new rotation schemes could be defined there.

I've added the ability to retrieve a vehicle's orientation via the lua interface. Unfortunately the orientation needs to be in a universal frame, not the frame used in the rvq file. The reason we want this is to automatically position the camera view based upon the orbiter orientation.
As the orbiter moves, the umbilical camera and overhead window views need to move with it.

I have yet to figure out how to convert to this frame this in the code--mostly haven't had the time to dig into it.

Another good option for the rvq file is to add an input into the ssc file that will allow using different types of frames for the rvq data. I have already added an option to display inertial j2k axes on any body (except the sun and stars). Also, when using rvq files, I have used the existing ssc Orientation parameter to perform an offset rotation to correct the image model orientation to the proper body frame. Sometimes the cad models are not built on the proper vehicle body frame and an offset rotation is necessary.

Long overdue is some way to use an alternate coordinate system for the positions. Currently, they're always relative to the equatorial plane of the parent body, but this is certainly not always desirable. Alternate frames for orientation would also be desirable.

--Chris

[RocketMan@JSC]

Could the jittering be caused by floating point precision issues?

For state vectors around the Earth, I don't think that will be a problem. I'm pretty sure I'm using doubles all the way through the calculations.

As for velocity, I think it should definitely be an optional part of trajectory files--they double the amount of memory consumed.

I looked at a bit at tec's descriptions of his changes to Celestia. I'd like to suggest that orientation kept separate from the Orbit classes. I think it would be cleaner to have separate Rotation and Orbit class hierarchies, so that different types of orbits and rotations could be arbitrarily combined.

In my design, there's a new base class called ObjectRotation (or something like that) with three subclasses:
SimpleRotation (what we've got now)
CustomRotation (hardcoded functions, akin to the CustomOrbits for planets and major satellites; definitely useful for Earth's rotation, precession, and nutation)
SampledRotation (like a sampled orbit; could use an rvq file as a source or perhaps a file with just quaternions)
And eventually SpiceCKRotation . . . The .ssc format would be expanded so that the new rotation schemes could be defined there.

Long overdue is some way to use an alternate coordinate system for the positions. Currently, they're always relative to the equatorial plane of the parent body, but this is certainly not always desirable. Alternate frames for orientation would also be desirable.

--Chris

Sounds great! All of these features are just begging to be integrated with SPICE. Not only can it do the emphemeris and orientation--but it also has the utilities for handling time, alternate frames and many other calculations that are needed. I guess I'm proposing a marriage of Celestia and SPICE--it certainly isn't the first.

I firmly believe that Celestia could be used for professional astrodynamic and spacecraft visualizations. I know there is a great fear of becoming a "game", which it could become with all the new features. The side benefit, as you are well aware, is that we would likely get some really good game programmers that are extremely proficient in the graphical aspects.

Scott

[Cham]

In my design, there's a new base class called ObjectRotation (or something like that) with three subclasses:
SimpleRotation (what we've got now)
CustomRotation (hardcoded functions, akin to the CustomOrbits for planets and major satellites; definitely useful for Earth's rotation, precession, and nutation)
SampledRotation (like a sampled orbit; could use an rvq file as a source or perhaps a file with just quaternions)
And eventually SpiceCKRotation . . . The .ssc format would be expanded so that the new rotation schemes could be defined there.

Chris,

could you elaborate a little on those options ? Can it be compared with my suggestion (in another topic) to constrain a model's orientation towards another object ?

[chris]

In my design, there's a new base class called ObjectRotation (or something like that) with three subclasses:
SimpleRotation (what we've got now)
CustomRotation (hardcoded functions, akin to the CustomOrbits for planets and major satellites; definitely useful for Earth's rotation, precession, and nutation)
SampledRotation (like a sampled orbit; could use an rvq file as a source or perhaps a file with just quaternions)
And eventually SpiceCKRotation . . . The .ssc format would be expanded so that the new rotation schemes could be defined there.

Chris,

could you elaborate a little on those options ? Can it be compared with my suggestion (in another topic) to constrain a model's orientation towards another object ?

SimpleRotation is what we have now. SampledRotation would point to a file with a sequence of orientation keyframes, possibly with angular velocity vectors. You could create one to make model point toward a certain object. SpiceCKRotation would use the SPICE toolkit to compute the orientation from a SPICE C-Kernel (available for all recent solar system missions.)

I haven't thought through it thoroughly yet; the rather vague descriptions I just gave are all I have right now.

--Chris

[Cham]

SampledRotation would point to a file with a sequence of orientation keyframes, possibly with angular velocity vectors. You could create one to make model point toward a certain object.

Then I'm concerned about periodic paths. I don't think a sampled file would do the trick for any periodic path (elliptical orbit). And the rotation animation will be ""jerky" (abrupt rotation jumps, or rotation in unatural steps), without any time dependant angular velocity informations.

[hank]

I firmly believe that Celestia could be used for professional astrodynamic and spacecraft visualizations.

I do too.

I've tried some simple experiments using Lua to customize Celestia, e.g. building custom overlays using Lua calling OpenGL to display text and images. I've also tried using Lua to call SPICE from Celestia. The results have been very encouraging.

Celestia is a wonderful astronomical visualization application, and has great potential to serve as an astronomical visualization toolkit for developing and deploying customized applications.

This is already happening, but unfortunately it has led to the emergence of various incompatible versions of the Celestia core code. I think it would be much preferable to maintain a unified version of the core code and use Lua to implement extensions for customized applications.

- Hank

[RocketMan@JSC]

A few pics of Celestia using the new orientation features.









p.s. Don't ask me for the tank model--no promises, but I'm in the process of trying to get it released--it may take a long time too.

[ElChristou]

Seems pretty cool...

...p.s. Don't ask me for the tank model--no promises, but I'm in the process of trying to get it released--it may take a long time too.

I've alredy done the complete stack... still not in final release because of the smoke (impossible to do realistic right now... )

[Joe]

A few pics of Celestia using the new orientation features

That is very good indeed. It is wonderful.

[mcarp]

I think there is an obvious solution to the issue here about the core and the scripting.


1: offer a dll extension system (or whatever cross platform libray) that can be loaded on the fly to extend program functionality. The library coder can impliment whatever non-core code he needs. Scripters can continue to script only or make calls to custom libraries without the need to learn c++.

2: offer a hook service that provides:

a) user rourtine to be run during the main loop.
b) callback system for user custom message handler.

An alternate idea: find a way to let Celestia be a window device that could be a child to an external application. Provide navigation goto and query services to the parent.

For example, A space shuttle simulator that is fully implimented BUT has no universe sim or an inferior one (who doesnt hate those fake star backgrounds). So now you build the shuttle sim and look out the window and boom, its Celestia. Switch to external and render your vehicle, behind that is a Celestia device. Theoreticly you'd declare a device Celestia passing to it a struct for width, height, address of a location coordinate struct, address of user input struct, etc. So now, we just keep updating viewport device's location like a camera (or we send input to the device to instruct it where to go, how fast, etc or perhaps both to be flexible) and we can have any number of Celestia devices running anywhere in the parent application. Parent tells device anytime it wants a new frame, so it only has to render a frame if its aske to.

Done in this way, and with the proper position and attitude setup that you guys have already discussed, a parent application could supply all custom content on top of Celestia devices including but not limited to: UIs, spacecraft simulators, parent rendered external vehicles and objects, enhancement effects, navigation tools, any kind of software that needs a universe.

Celestia need not ever violate it's core philosophy or be involved in excessive code development. Plus...guys!...there is no other universe sim out there hands down gentlemen. You guys have got the best on the planet!

[hank]

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

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

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.

That's a useful thing to be able to do from Lua. How extensive were the celx modifications?

I'm working on having Celestia use SPICE directly instead of through Lua--it's important enough that I think support for it should be built in. It will still be possible to build Celestia without SPICE support, however.

Another thing that I'm interested in doing (and I know you've suggested this before as well) is to implement a Lua script orbit type. Have you thought at all about how such a thing should appear in an ssc file and what the Lua script should look like?

--Chris

[hank]

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

That's a useful thing to be able to do from Lua. How extensive were the celx modifications?

My experiment was a bit of a hack, but it wasn't very much work. I noticed that SampledOrbit::computePosition always returns the first sample if there's only one. So my CELX setposition function just sets the coordinates of the first sample and resizes the orbit's sample vector size to 1. Obviously, this only works for objects initially defined with a SampledOrbit. I defined the test object with a dummy two-entry .xyz file to set the date range.

To call the Lua script after each simulation update, I used a mechanism I had previously put in CELX to send arbitrary events to a Lua script. I had used this in an earlier experiment to call a Lua script to implement a custom overlay (drawn by making OpenGL calls directly from Lua). For this I use a special LuaState in CelestiaCore (distinct from the one used for user scripts) which is initialized at startup with a script from a file specified in the config file. The script runs as an event handler coroutine. At the appropriate points in the CelestiaCore code I make a one-line call to the LuaState to run the event handler, passing it the event type and arguments.

This approach is very flexible and has worked well for experimentation, but may need refinement for general release. Also, it's probably better to define a new Orbit subclass for Lua scripted orbits, as you indicate.

Another thing that I'm interested in doing (and I know you've suggested this before as well) is to implement a Lua script orbit type. Have you thought at all about how such a thing should appear in an ssc file and what the Lua script should look like?

My thoughts on that are still evolving, but my guess is that the Lua script should define a Lua object containing methods like computePosition, etc. The ssc file might contain either a filename or a string containing a Lua chunk.

- Hank

[hank]

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