Celestia Forums

I've been thinking of adding some basic collision detection to Celestia as a mod. When navigating around, especially with high res dds files enabled, slightly slower machines will pause during loading resulting in the camera being within a planet or sun.

This can be somewhat annoying. With some basic collision detection, this could be prevented and the option toggled on or off.

(For those users who don't know what collision detection is: Collision Detection is used to make planets and other objects appear solid. You cannot fly through a planet or other object.)

Has this been discussed in any great detail, or has anyone tried to implement it?

This seems to be a good idea. Many of my students, while trying to move around some probe model, end inside of it. After that, they ask some stupid and annoying questions to the teacher. Basic collision detection could be a good feature.

DT, I'll be happy to test that, so go on without a doubt!

DT wrote:I've been thinking of adding some basic collision detection to Celestia as a mod. When navigating around, especially with high res dds files enabled, slightly slower machines will pause during loading resulting in the camera being within a planet or sun.

This can be somewhat annoying. With some basic collision detection, this could be prevented and the option toggled on or off.

(For those users who don't know what collision detection is: Collision Detection is used to make planets and other objects appear solid. You cannot fly through a planet or other object.)

Has this been discussed in any great detail, or has anyone tried to implement it?

I'm not sure just what you have in mind. How do you propose to avoid collisions?

- Hank

If implemented, it needs to be configurable. There are circumstances when you want the viewpoint to go inside a body. E.g when exploring the interior of a model. Similarly, objects do need to interpenetrate one another. E.g. the fragments of Comet Shoemaker-Levy 9 colliding with Jupiter.

You may have overlooked Ctrl-G, which is the "land on surface" command.

p.s. collision avoidance is the wrong way to fix the problems caused by slow loading of textures. Rather, texture loading I/O needs to be made asynchronous so that Celestia does not pause while it's happening.

selden wrote:p.s. collision avoidance is the wrong way to fix the problems caused by slow loading of textures. Rather, texture loading I/O needs to be made asynchronous so that Celestia does not pause while it's happening.

Selden,

correct me if I'm wrong, but if Celestia loads the textures asynchronously, we may see some white sphere just before a texture is applied to it (when the user move to the sphere, without lags), is that correct ?

Cham,

Yes, you are correct.

If that symptom is to be avoided, then the textures need to be "preloaded". This option already is available for most (but not all) types of textures.

p.s. first loading and displaying lores textures might be a reasonable workaround.

selden wrote:If that symptom is to be avoided, then the textures need to be "preloaded". This option already is available for most (but not all) types of textures.

Please, can you elaborate a bit more on this feature ? I vaguely remember having saw an option like this before, but I don't remember exactly where and never tested it before. At what stage does the texture is "preloaded" ? And which types of textures ?

Martin,

these are the first 2 lines in my start.cel script since ~4 years:

preloadtex { object "Sol/Earth" }
preloadtex { object "Sol/Earth/Moon" }

It works just fine. The loading of the specified textures proceeds in background after the command has been called and so is ready when you need it a little later.

Bye Fridger

Haa ! Thanks Fridger, now I remember. I did used that for some time on my config, but removed the option after a while, because the startup sequence was a bit too slow for my taste. It was a long time ago.

t00fri wrote:Martin,

these are the first 2 lines in my start.cel script since ~4 years:

preloadtex { object "Sol/Earth" }
preloadtex { object "Sol/Earth/Moon" }

It works just fine. The loading of the specified textures proceeds in background after the command has been called and so is ready when you need it a little later.

Bye Fridger

It's just with this command that the difference between texture format is selfevidence: .DDS are too fast than the others, and the MipMap is the same as the low resolutions texture's preload.

Perso, I "preload" about n=100 .DDS 2048x1024 textures (non VT and nor nebulae, of course) in approx 350 Mb RAM and 128 SDRAM. The 2k .PNG are limited just at few planets.

I voted yes, but not for the idea of view collision detection... although it is a nice idea. How about an event flag for object collisions to be used in scripts? Something with configurable (dynamic) proximity detection?

As far as use (being creative)? How about a spacecraft's reentry to Earth? Events like atmosphere entry, chute deployment... all their associated script timings which would be involved, now eliminated and replaced by proximity-to events?

Preloading of textures is fine if the textures are small. When you have images that exceed several Gigs in total, then there will be problems. The way to cure this is to have an additional thread running that determines your position, speed and heading and tries to predict what textures will be needed.

Also, an upgrade path to OpenGL 3.0 (http://www.opengl.org/) should be considered at this point.

In regards to collision detection, there are additional uses. Such as asteroids or satellites colliding. I feel that it is important to attempt to increase realism as the development progresses.

As I mentioned before, I've been working on a multi-threaded server component. It can be used as a central-point from which to control Celestia or off-load processing. In a classroom, or Internet, environment the server could push script commands to each of the clients that will allow for classroom presentations, or even co-ordinate multiple monitors to create a single extended viewing area.

I'm about mid-way through the design of the server. I'm trying to decide if syncronisation will be a major issue and if mutexes would introduce bottlenecks. Based on a few quick sketches, it looks as though it will be, so I need to build a solid management framework. Then there is the issue of where to place the hooks in the Celestia code. I torn between pumping commands to the parser or introduce my own custom routines and develop a full protocol. There is also the option of doing a mixture of both.

I'll know more this evening as I intend to finish off a functional version of the server side protocol parser.

DT,

If you haven't already, you should consider contacting the others who've done this in the past. Learning from their efforts ought to help a little.

Some examples are at
http://celestiaproject.net/forum/viewtopic.php?t=1374&
http://celestiaproject.net/forum/viewtopic.php?t=9065&

I know there was at least one other one, but I haven't located its thread.

If you haven't already, you should consider contacting the others who've done this in the past. Learning from their efforts ought to help a little.

Thanks very much, this has proved very helpful. Real-Time Celestia will prove very useful when it comes to implementing the hooks.

I have been reading about the orientaton issue, does this still exist as of the current 1.5.0 build?

Celestia v1.5.0 has several new ways to specify the orientation. I don't know which would be better for adapting to realtime interactions. It can use Lua methods (ScriptedRotation) or .q files (SampledOrientation). The latter are similar to .xyz trajectory files (SampledOrbit), but contain Julian dates, each followed by the four elements of a quaternion to specify the object's orientation.

Celestia v1.5.0 has several new ways to specify the orientation. I don't know which would be better for adapting to realtime interactions. It can use Lua methods (ScriptedRotation) or .q files (SampledOrientation). The latter are similar to .xyz trajectory files (SampledOrbit), but contain Julian dates, each followed by the four elements of a quaternion to specify the object's orientation.

Cheers Seldon. I'll take a look at the mechanism. I think it will be best to stick closely with the features that have been implemented in the official version.

I ran a few stress tests on the server I was building, it didn't look pretty under Vista. I was hoping to get away with a thread-per-client, but it dies after 10 threads.

So, I changed the architecture to support I/O Completion Ports and it is scaling much better. I stress tested the basic framework with 64 clients and its responding very well. If also goes well, the final version should support as many clients as the hardware and bandwidth allow.