Celestia Forums

I'm putting the finishing touches on a new version of the Celestia Explorer script that contains bug fixes and some major new features. I thought I'd mention some of what I'm finalizing to see if anyone had a comment.

My objective in writing this script is to enhance the sense of being in the actual environment. For example in the previous version, the sensors detect objects that are nearby. Just knowing what's near you, and giving one the tools to point to and travel to these objects, should hopefully enhance that sense.

To this end, in this new version many of the clouds (dense molecular clouds, diffuse clouds and the so-called bubbles) are now implemented in full 3-D (in position, not visually). In this version, in addition to showing the local density of the ISM as you pass through these regions, you experience various environmental effects. For example slamming into a dense molecular cloud at high velocity can potentially cause your titanium hull to overheat and, in the extreme case, melt. (Don't worry. A beacon is automatically released to inform your loved ones of the unfortunate event. ) You might want to avoid the Coalsack for example.

Docking has been reworked and enhanced. The program now supports multiple docking ports and the user can add messages that will be displayed when docking or undocking.

The program now calculates and displays (on command) the amount of fuel used. Right now this is meaningless, but I?€™m thinking that in some future version, refueling by docking with a space station will be implemented. And of course, running out of fuel would then have consequences. Comments welcome.

Then there's the environmental effect of gravity fields. The only nod to gravity fields in the previous version was in calculating orbit parameters (I already calculate the gravity field of most objects.) What I'm thinking, although this is only in the planning stages right now, is that if you turn off the engines near a planet or a star, you will find yourself falling toward it. (Approaching something that is already in orbit puts you in orbit, or you can choose an orbit.) That should be interesting since impact physics has already been implemented. But of course, the really interesting body to approach would be a black hole. Too close and you'll be unable to overcome its powerful gravity field.

Of course, many will find this all a little tedious. I find it interesting because it allows me to experience in a simulation some of the parameters of spaceflight that we'll only know when our technology is advanced enough to take us to the stars.

Henry

I know I'd be glad to give it a try!

In searching the forum for discussions about nebulas, I've see the various comments on creating volumetric constructs. In my program I started out modeling invisible things externally to Celestia, for example the the "Local Fluff." The models are held internally in my celx program. This works fine but then I went on to model visible things like the Coal Sack. When I say model, I mean volumetric density models not Celestia models. But then I realized that there are existing Celestia models for gas clouds that are visible. What I'm trying to do is find a graceful way to integrate the two concepts. I keep running into things like since I can't assume anyone has a particular Celestia model should the user be able to point his ship at an invisible object? This is compounded by the fact that pointing to large volumes of gas in some cases doesn't make any sense, like when you're inside of it. But since ISM density can affect your ship in negative ways, you need to be aware of the location of "navigation hazards." Any suggestions would be gratefully appreciated.

Henry

hharris wrote:In searching the forum for discussions about nebulas, I've see the various comments on creating volumetric constructs. In my program I started out modeling invisible things externally to Celestia, for example the the "Local Fluff." The models are held internally in my celx program. This works fine but then I went on to model visible things like the Coal Sack. When I say model, I mean volumetric density models not Celestia models. But then I realized that there are existing Celestia models for gas clouds that are visible. What I'm trying to do is find a graceful way to integrate the two concepts. I keep running into things like since I can't assume anyone has a particular Celestia model should the user be able to point his ship at an invisible object? This is compounded by the fact that pointing to large volumes of gas in some cases doesn't make any sense, like when you're inside of it. But since ISM density can affect your ship in negative ways, you need to be aware of the location of "navigation hazards." Any suggestions would be gratefully appreciated.

Henry

The challenge for Celestia is to incorporate several 10 000 's of deep-space objects with all data in accord with published scientific catalogs.

Are you talking about modeling individual nebulae? A Lua script certainly will not be able to handle the culling of 20 000 DSO's, say, efficiently...

Bye Fridger

One possibility might be to use a single canonical representation for all of the different regions and not try to display their details. A sphere with different radii could be used for all of the regions, for example, maybe with different colors to indicate different physical characteristics.

p.s.
If you're just representing our local region, I would expect fewer than a hundred DSOs would be adequate and wouldn't significantly impact performance

Several thousand do slow things down substantially with the current code. (e.g. http://www.celestiaproject.net/forum/viewtopic.php?t=10501& )

selden wrote:One possibility might be to use a single canonical representation for all of the different regions and not try to display their details. A sphere with different radii could be used for all of the regions, for example, maybe with different colors to indicate different physical characteristics.

p.s.
If you're just representing our local region, I would expect fewer than a hundred DSOs would be adequate and wouldn't significantly impact performance

Several thousand do slow things down substantially with the current code. (e.g. http://www.celestiaproject.net/forum/viewtopic.php?t=10501& )

Selden,

it's crucial to distinguish ADD-ONS from DSO's implemented as e.g. our galaxies. Unlike Add-ons, the latter are most effectively /culled/ via our sophisiticated octree code in Celestia's core!


So it is NOT correct to state /in general/ that several thousand DSO's would slow down the code. Toti and I have done many checks within the octree culling showing clearly a negligible slow-down for 10000 galaxies.

Bye Fridger

Fridger,

I was just using your terminology.

While galaxies currently are being culled efficiently, OpenCluster and Nebula objects are not, of course.

selden wrote:Fridger,

I was just using your terminology.

While galaxies currently are being culled efficiently, OpenCluster and Nebula objects are not, of course.

But, all the infra structure is already in the core!
That's the CRUCIAL point. It is just that I have not yet found the time to extract the respective catalog objects and render them with sprites etc. But irrespectively, there is a HUGE difference as to performance compared to Add-ons, which have NO culling implemented.

The culling works equally well for ANY kind of internally implemented DSO.

I thought this was generally known...

Bye Fridger

Fridger,

I don't think I understand what you're trying to say.
Why would culling be any different for Nebula or OpenCluster objects that are "Addons"?

selden wrote:Fridger,

I don't think I understand what you're trying to say.
Why would culling be any different for Nebula or OpenCluster objects that are "Addons"?

You misunderstood:

++++++++++++++++++++++++
Add-on type implementations of DSOs invoke virtually NO culling, no matter whether these are galaxies, nebulae, clusters,...

DSO's implemented via .dsc files and a corresponding rendering routine (e.g. galaxy.cpp, nebula.cpp, opencluster.cpp,...) DO invoke a most effective octree culling!
++++++++++++++++++++++++

That's why I am not at all interested in add-ons in the context of DSOs!

The Universe is full of VERY MANY things which have to be simulated appropriately. An almost empty Universe is a joke. It's like a Hifi set without loudspeakers

Anyway, culling is of paramount importance. Individual objects have at best a meaning in the sense of an educational illustration. As you know that's not what I am concerned with.

Bye Fridger

t00fri wrote:

selden wrote:Fridger,

I don't think I understand what you're trying to say.
Why would culling be any different for Nebula or OpenCluster objects that are "Addons"?

You misunderstood:

++++++++++++++++++++++++
Add-on type implementations of DSOs invoke virtually NO culling, no matter whether these are galaxies, nebulae, clusters,...

DSO's implemented via .dsc files and a corresponding rendering routine (e.g. galaxy.cpp, nebula.cpp, opencluster.cpp,...) DO invoke a most effective octree culling!
++++++++++++++++++++++++

I'm not sure that I understand . . . All DSOs in Celestia are subject to octree culling whether they come from an add-on or the standard dsc files. Celestia treats all dsc files identically.

--Chris

chris wrote:...
I'm not sure that I understand . . . All DSOs in Celestia are subject to octree culling whether they come from an add-on or the standard dsc files. Celestia treats all dsc files identically.

--Chris

Certainly, all .dsc files are treated equally.

But according to my rememberance, DSO's without absolute magnitude entries are effectively exempt from culling, since absMag is used as the ordering parameter in the octree.

Virtually no add-on for nebulae etc uses absMag in their .dsc files.

At the time when we coded the DSO-octree stuff , I introduced the average absMag as a dummy for the add-ons with lacking absmag data. But still effectively there is no culling taking place.

It's too long ago and tonight I have no time to refresh my memory by digging in the code. But I am quite sure I remember this about right.

Bye Fridger

Selden,

You're pretty close. I model a gas cloud by a table of spheres, which can be overlapping. Each sphere has a "priority" which means I can model a gas shell with a density inside and another for the shell. For example the "local bubble" only takes about 15 spheres, even though it has a very complicated structure.

The works very well because gas clouds in space (including bubbles) are usually created by explosive events which create spheres.

All of space is divided into sectors 20 LY on a side. As you travel, the program continuously keeps a list of all objects that are inside your current sector (with some overlap from the last sector). This means the program can very rapidly simulate sensors that can tell you what's around you. The program also keeps track of the ISM density at your current position which is displayed and used to model engine performance and hull temperature. And of course radiation from nearby stars also affects hull temperature.

Henry

Henry,

Now *you* have confused me

It seems reasonable to me that if the script is modelling the regions as overlapping spheres, then it should be reasonable to use a small number of spherical 3D models to provide a visual representation of those regions. While it's slightly more complicated than simply providing a script, an Addon that includes the script, models and associated DSC catalog wouldn't be very complex.

Is it that you haven't done it before and thus it seems intimidating?

Selden,

Remember that most of this is invisible and covers hundreds of light years. I'm mostly modeling changes in the ISM. For example the "Local Fluff" is .1 atoms per cubic cm and the "local bubble" is .001 atoms per cubic cm.

However your comment directly addresses my original question above and I appreciate that. My question was, more or less, since some gas clouds are visible, shouldn't I have a more general method that includes add-ons.

So I guess it comes down to two questions: (1) Is it practical to create an invisible addon that is hundreds of light year in extent. And more importantly (2) can the necessary information about the add-on be extracted from the model inside a Lua program?

Addressing question 2, as far as I know, the only positional information that can be extracted is the radius and the position. That means that, for example, the local bubble would have to be 15 invisible add-ons. But this doesn't solve the problem because, if visible, you'd want a dense cloud to have a more complicated structure than simply a series of spheres.

One solution that occurs to me is to build an add-on with other information that could be recovered using the getinfo method. Is it possible to introduced new keys into a model that could be accessed through Object:getinfo()?

If not, then I'd have to have additional information inside my Lua program which introduces all the problems I was originally talking about.

Henry

Henry,

Don't forget that although such regions are invisible to the human eye, they are not invisible to long range sensors (i.e. astronomical telescopes ) Any navigational aid worthy of its name would be able to display the different regions.

Choosing appropriate representations is one of the difficulties, of course. In Celestia, one of the cruder representations would be a collection of spherical outlines.

The more traditional method of drawing a sphere using longitude and latitude lines gives the misleading impression that the regions have poles, but they have the advantage of being immediately recognizable.


This screengrab shows the positions and nominal sizes of many of the Hii (red) and CO (green) regions between the sun and the galactic center. The colors and opacities of the lines are easily edited.

It might be better to draw them using dodecahedrons or perhaps somewhat denser "buckyballs". I haven't taken the time to create models of those shapes, so I can't show them now.

An even better representation might include density contours. Unfortunately, those are only known as column densities seen from our local viewpoint, which makes it somewhat difficult to generate the appropriate 3d models.

The locations and sizes of the regions are specified in DSC catalog files. If one specifies a convention for comments to include the other information that the script would need (e.g. density) I would expect that DSC catalogs could be interpreted by the script. This allows the specification of the various parameters that Celestia doesn't use. I also think this would be more approachable by someone trying to understand the script than would extracting the information from data structures within Celestia.

t00fri wrote:

chris wrote:...
I'm not sure that I understand . . . All DSOs in Celestia are subject to octree culling whether they come from an add-on or the standard dsc files. Celestia treats all dsc files identically.

--Chris

Certainly, all .dsc files are treated equally.

But according to my rememberance, DSO's without absolute magnitude entries are effectively exempt from culling, since absMag is used as the ordering parameter in the octree.

Virtually no add-on for nebulae etc uses absMag in their .dsc files.

At the time when we coded the DSO-octree stuff , I introduced the average absMag as a dummy for the add-ons with lacking absmag data. But still effectively there is no culling taking place.

It's too long ago and tonight I have no time to refresh my memory by digging in the code. But I am quite sure I remember this about right.

Right--the default absolute magnitude is probably bright enough to guarantee that the object is always visible, thus no culling will occur. But provided that an absolute magnitude is supplied, there should be no problems with DSO add-ons with regard to culling.

--Chris