realtime interface to Celestia

[RocketMan@JSC]

I believe most of the changes tec brought forth are worth integrating into Celestia.

Most important is the ability to input spacecraft attitude, that is a must have. Next the UDP connection for vehicle position and attitude will allow Celestia to be connected to simulation tools for design of trajectories. If you've ever run Satellite Tool Kit you'll know what I mean. Try running a lunar targeting loop and watch the results as it calculates trajectories going to the moon. I know Celestia wasn't originally intended to do this but IMHO Celestia is a space based graphics engine with many uses.

As a software developer I understand your desire to keep the design and code pure, but a few handy features like this and Celestia can be used in some really cool ways. I'll be integrating some of tec's changes into our linux version and will be sure to post back on the results.

One other feature I would recommend is the ability to articulate vehicle models. By that I mean control things like engine plume, landing struts, antenna's, bay doors, inter-stage separations, etc... Pretty soon I will have a video posted on a AIAA web site showing a lunar landing that was produced in STK--BTW STK cost us over $50k USD per license--so an open source alternative can be attractive. Someday I would hope the same could be done in Celestia. I'm just not sure the 3ds format supports these features.

Scott

p.s. The 30 Hz cpu limiting feature from a separate thread is also a real good idea.

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

[t00fri]

I believe most of the changes tec brought forth are worth integrating into Celestia.

All agreed, but --given Celestia's complex overall structure-- an integration of these features straight into Celestia's CORE code appears to me as a sub-optimal choice.

Celestia's Lua scripting code is really powerful and expandable. Respective commands can be well integrated along this way. As I mentioned a whole networking module serving besides udp also other purposes like online ephemeris updates may be an attractive option to consider.

We must be very concerned of not degrading Celestia's multi-purpose design too much into a specialized application that might only serve few purposes.

Bye Fridger

[tec]

I don't understand how you expect to get a body into Celestia in real-time using Lua. Maybe you can give us an example of how Lua can dynamically drain the network for external simulation bodies. Remember this Lua process (or wheatever you are thinking) must be running continuously to look for incoming UDP packets. If you can explain it, I will code it up.

You keep stating that we need to think broader. I don't think Lua is the place for the Real-Time code because it forces users to learn and USE Lua. The core is where the Real-Time code should be implemented.

Chris??? Where are you Ole Great One. Help!

Tim

[t00fri]

I don't understand how you expect to get a body into Celestia in real-time using Lua. Maybe you can give us an example of how Lua can dynamically drain the network for external simulation bodies. Remember this Lua process (or wheatever you are thinking) must be running continuously to look for incoming UDP packets. If you can explain it, I will code it up.

Just have a loock in celestiacore.cpp how the execution of Lua scripts is bound into the simulation time loop.

Another relevant new aspect is Chris' recent implementation of /eventhandlers/ for LUA scripting.
I don't know how much you are following the dev list?

You keep stating that we need to think broader. I don't think Lua is the place for the Real-Time code because it forces users to learn and USE Lua.

Are you saying that our efforts of implementing Lua scripting were a vaste of time since it forces users to learn and USE Lua??

Bye Fridger

[Malenfant]

I'm not sure why you're so hostile to this implementation, Fridger - Scott's already explained some excellent possible uses for the realtime stuff. If adding this code wouldn't impact on Celestia's ability to do other operations then why complain about it?

Can you actually demonstrate a way that LUA can do all the things that the realtime code can do? Because if you can't, I don't think you're going to convince anybody that the realtime code is redundant and that people should stick to LUA.

[tec]

RocketMan,

I agree that the 3ds model format is not as supportive as other gaming model formats. I have use the OpenFlight model format extensively. I think it is a good format for this and other gaming software because of the Levels of Details, special effects, model switching, texture mapping, articulations, animation sequences and much more. I am sure it would be easy to link in a open flight loader into Celestia.

One downside is that the users would have to go out and get models or build/modify their own. This would be a lot of work. There are ways to export existing models in OpenFlight formats from the current tools. There are hundreds of existing OpenFlight models for free that we could get from the Internet to start with.

Tim

[t00fri]

I'm not sure why you're so hostile to this implementation, Fridger - Scott's already explained some excellent possible uses for the realtime stuff. If adding this code wouldn't impact on Celestia's ability to do other operations then why complain about it?

Can you actually demonstrate a way that LUA can do all the things that the realtime code can do? Because if you can't, I don't think you're going to convince anybody that the realtime code is redundant and that people should stick to LUA.

I am not at all hostile, but I usually prefer to see before the coding takes place

-- what the possible uses are and whether they would be attractive for a major community. OK we had some discussion about this already.

-- how to best implement the whole stuff. I know that Chris is also VERY reluctant in general to modify the Celestia kernel unnecessarily. So the Lua experts should just get together and discuss whether Lua could handle this.

-- also I think before implementing a specialized udp networking task, we should contemplate more generally how to implement best other network abilities as well, e.g. for updating emphemeris of asteroids and spacecraft online.

Bye Fridger

PS Perhaps you might tell me what e.g. a user like yourself would like to do with such real-time features? Start the external play-back pannel and send some rotation command for the antenna of Cassini spacecraft? Wow, it works...but how often would you repeat this exercise? Did I overlook something crucial?

[Malenfant]

Well it depends on whether the aim really is to integrate this code directly into core Celestia or whether to spin it off into a different build (like Mostly Harmless was). If the aim is the latter then there's no reason to complain at all, and if it's the former then if it can be integrated without the loss of any other functionality or speed then then where's the problem?

I find that while it might not be obvious what the general utility of some code might be now, someone will eventually come along to use it in some unexpected way that adds some functionality.

[hank]

I'm an advocate of Lua because it allows you to enhance and customize Celestia without modifying the Celestia C++ code. That means you don't have to compile a modified version of the Celestia code, or wait for the developer team to integrate your changes, or learn C++. You do have to learn Lua. But Lua, though very powerful, is a comparatively small and simple language. With Lua, many more people are likely to be able to contribute Celestia extensions and custom applications. And different users can mix and match such Lua add-ons according to their needs. Of course, the low-level hooks for Lua are needed in the core, but these should be designed for flexibility and generality, with special-purpose functions implemented in Lua outside the core.

- Hank

[t00fri]

I'm an advocate of Lua because it allows you to enhance and customize Celestia without modifying the Celestia C++ code.

...
- Hank

tec,

OK, you see , Hank is one of our Lua experts. His opinion matches mine completely.

Bye Fridger

[Christophe]

Yes, Lua could handle this, but there is no network support in Lua, you need to use an extension which targets Lua 5.1. Although a compatibility module is included for Lua 5.0, I haven't been able to get it to work from celx yet.

On the other hand, I haven't even tried Tim's Realtime extension to Celestia since it would require quite a bit of work to get it cross-platform.

Lua still seems the better way to do it to me. From an implementation point of view, no network code in C++ means no cross-platform hassles, and from a usage point of view it makes adaptation to various purposes a lot easier.

[hank]

Hank is one of our Lua experts.

I wouldn't say I'm an expert. But I've looked into Lua enough to think it has great potential for use with Celestia.

Yes, Lua could handle this, but there is no network support in Lua, you need to use an extension which targets Lua 5.1. Although a compatibility module is included for Lua 5.0, I haven't been able to get it to work from celx yet.

The LuaSocket extension requires a version of Lua with loadlib enabled. This needs to be added to Celestia.

Lua still seems the better way to do it to me. From an implementation point of view, no network code in C++ means no cross-platform hassles, and from a usage point of view it makes adaptation to various purposes a lot easier.

There may be some hassles getting Lua to work for this, but once we sort it out we'll have a very flexible extension capability in Celestia that can be used for many purposes.

- Hank

[RocketMan@JSC]

I don't know much about the Lua interfacing yet, but I agree it would be desirable to offload as much as possible to the interface and keep the core doing it's primary job. I'm curious why Lua was chosen over Python? Seems the same job and much more could be done via a similar Python interface.

I don't see how the spacecraft attitude quaternions could be done with Lua. What would be great is if we could interface with the JPL spice toolkit and read in kernels for planetary and space vehicle ephemerides. All the code is there and the data file formats are already established in a generic manner. There are many desireable utilities in spice that could be used for other purposes also. This whole spice toolkit is really a design and implementation issue that needs more discussion.

On a side note, a guy at work sent me a link to a NASA built visualization tool: http://centauri.larc.nasa.gov/see/

It appears to have many great features for trajectory and vehicle analysis, but I think Celestia has it beat on the visuals. Perhaps some of you guys would see a few desireable features that could be "borrowed".

Scott

I'm an advocate of Lua because it allows you to enhance and customize Celestia without modifying the Celestia C++ code.

...
- Hank

tec,

OK, you see , Hank is one of our Lua experts. His opinion matches mine completely.

Bye Fridger

[hank]

I don't see how the spacecraft attitude quaternions could be done with Lua. What would be great is if we could interface with the JPL spice toolkit and read in kernels for planetary and space vehicle ephemerides. All the code is there and the data file formats are already established in a generic manner. There are many desireable utilities in spice that could be used for other purposes also. This whole spice toolkit is really a design and implementation issue that needs more discussion.

C functions can be called from Lua, so it should be possible to make a Lua-accessible version of the SPICE library. Then, if Celestia allowed the location and orientation of an object to be defined by a Lua function, that feature could be used to implement SPICE-basd objects.

- Hank

[Rassilon]

I am wondering if it would be possible to have Lua control visible aspects of Celestia such as star color variations or galaxy rendering variations? That is if the devs are not already implementing this in the source...

[hank]

I am wondering if it would be possible to have Lua control visible aspects of Celestia such as star color variations or galaxy rendering variations? That is if the devs are not already implementing this in the source...

I don't really know what capabilities you're asking for here. But given the flexibility of Lua, I'd guess it would probably be possible.

- Hank

[Joe]

Hey, Tim

Are you there?

First thanks for the suggestion and I managed to get your latest realtime pach run on my WindowXP machine.

Second best wishes that you would keep this real time feature alive, regardless in whatever form (script or not). I believe more members in this forum would find it's a real use like what Scott has mentioned in his posts.

[tec]

Hey Joe and fellow Celestia users,

I am still trying to understand how a user would use Lua for the real-time bodies. As a user I would have to start a script to read the UDP messages. A script runs for a seconds and stops. This is crazy. Does this mean I have to execute a Lua script (thread) that runs indefinately or until I am done watching all 100 real-time satellites orbiting the earth? Remember, Celestia is a single threaded application. I would like for someone to explain the steps involved using the Lua script.

The real-time interface in the core could drain the UDP network message any time a message appears. The user would not have to run a Lua script. How about the cool master/slave features of the RealTime Celstia? How would that work using Lua scripting? How would the Celstia Broadcasting work.

Some one mentioned that you have to learn C++ to use the real-time code. This is true but most of the work is done for you. C++ and Lua are very similar. If you are going to argue that you have to learn C++, I can argue that you have to learn Lua. I like Lua and I think it serves a great purpose for what is does but I think that the UDP messages belong in the core.

Remember that the Lua is an interpreted language like MatLab and Java. Try interpreting 100 UDP message coming into your network card and processing the message and rendering the bodies. This will be impossible. I have been in exercises where there are over 1000 bodies on the network and all applications are required to process each UDP message and render. Good luck with a scripting language.

I have used this same UdpSocket.cpp class on Linux. It will not be an issue porting these features to Linux. I have 2 linux boxes in my office and I can start testing as soon as we come to an agreement.

Tim

[Rassilon]

I am wondering if it would be possible to have Lua control visible aspects of Celestia such as star color variations or galaxy rendering variations? That is if the devs are not already implementing this in the source...

I don't really know what capabilities you're asking for here. But given the flexibility of Lua, I'd guess it would probably be possible.

- Hank

Certain star subclasses have different spectural hues that cannot be controlled by a texture alone... Also the galaxies/nebula code added by Toti and Fridger could be used for other features such as giving a not so hard edge to mesh rendered objects used as nebula or ascension disks as long as the color of the galaxy/nebula code or particles can be tweaked to match the object color... Not to mention the ability to control weither a mesh can have a displacement map to give it a surface texture... Give meshes night lights... Bumpmaps... The list goes on... This would save Chris the trouble of adding it himself, instead the addon creator could script it in for just his addon using Lua...

[Christophe]

Lua doesn't run in a thread, but neither does your UdpSocket class. They both work by being called from the main event loop.

Something like this:

Code: Select all

socket = require "socket"
udp = socket.udp()
udp:settimeout(0)
udp:setsockname('*', 2000)

while 1 do
    local packet = udp:receive()
    if packet ~= '' then
        process(packet)
    end
    yield()
end


The master/slave feature could be implemented in just the same way with one instance running a master script broadcasting the observer's position and the other session data.

I've never used LuaSocket, so I don't know how well they perform compared to native code, this would have to be assessed.

I'm personnaly not sure Lua is the right way to do this, but I think it's worth investigating considering the flexibility this would give.

Regarding your C++ implementation, could you publish it as a patch? It's a bit hard to see what you changed at the moment. In any case, if you want to have your code included, you'd have to do some refactoring to follow the coding conventions (see coding-standards.html in the base directory) and also get rid of the platform specific code (using ifdefs for one liners, or virtual methods).