Celestia Forums

I was wondering if there was any form of sound support for celestia, such as the ability to play .wav or mp3 files.

I seen a patch posted by Vincent a while back, but that was for 1.4.1 and the file is no longer available.

DT,

Since there are many other priorities, and since it doesn't fit the main purpose of Celestia, sound support won't be included in the main development code of Celestia.

Then, I've been looking for some possibilities to add sound support to Celestia via the Lua interface. The LuaOpenAl library seems to be the most suitable candidate to do that. This would nevetheless require the addition of a short piece of code to the Celestia core code. So this has to be discussed first. But at the moment, the dev team have a lot of other priorities on which to focus...

In the meanwhile, the 1.4.1 patched version of Celestia that includes sound support is still available here: http://celestiaproject.net/forum/viewtopic.php?t=9503

Since there are many other priorities, and since it doesn't fit the main purpose of Celestia, sound support won't be included in the main development code of Celestia.

What I'm trying to create is a repository of code that can be used to implement specific features. This is for developers who want to create custom versions of Celestia. There have been a lot of useful features created over the years, but most of these are embedded into packages that include numerous other features. I want to strip them and separate out each of the functions.

I have some time on my hands, so I'm messing about with code and trying different things. I won't really need help from the dev team, other than asking some questions and ironing out bugs I encounter.

In the meanwhile, the 1.4.1 patched version of Celestia that includes sound support is still available here: http://celestiaproject.net/forum/viewtopic.php?t=9503

Thanks. I'm ripping Victor's code as we speak...

For those looking to add sound support here are the instructions:

1. Download the following file:
http://vincent.gian.club.fr/celestia/celestia_win32_1.4.1_patch3.zip

2. Copy alut.dll and OpenAL32.dll to the Celestia base folder.
3. Copy the folder 'Sounds' to the Celestia base folder.
4. Copy the Alut.lib and OpenAL32.lib to the libs folder you use for development.
5. Copy the headers from \inc\Al to the headers folder you use for development.
6. Three files need to be updated:

celx.cpp
celestiacore.h
celestiacore.cpp

Search for the term 'Victor' and copy the routines to your working copy.
7. Add the libs to the linker
8. Compile

Copy the file sound_test3.celx to your scripts folder.

Run Celestia and load the script. You should now have sound support.

DT,

while you are free to implement whatever feature you fancy into your personal code, let me emphasize that it is generally not a good idea to popularize such ripping-appart endeavours at this stage of the Celestia code.

Soon we will have to bother with lots of beginners, who followed your instructions, trying to obtain various non-standard, undocumented code versions. Soon or later the devs and Selden will have to spend plenty of additional time to sort the resulting chaos out....

Believe me, we collected considerable previous experience in that direction in the context of faulty add-ons done by inexperienced users...

Bye Fridger

while you are free to implement whatever feature you fancy into your personal code, let me emphasize that it is generally not a good idea to popularize such ripping-appart endeavours at this stage of the Celestia code.

Soon we will have to bother with lots of beginners, who followed your instructions, trying to obtain various non-standard, undocumented code versions. Soon or later the devs and Selden will have to spend plenty of additional time to sort the resulting chaos out....

Firstly, Celestia is not a platform beginners should be trying to work from. I think we can both agree on that. The goal here is to provide experienced developers with short-cuts that will shorten development time to implement certain features. Modding is a very important aspect of open-source development and that process is hindered if everyone must figure things out for themselves.

Believe me, we collected considerable previous experience in that direction in the context of faulty add-ons done by inexperienced users...

I don't doubt that for a second, but the material needs to be made available to experienced developers also. So, the solution would appear to be not to provide development support to beginners, only experienced developers. In addition to that, only provide support for the official release, unless it is something straightforward or how to slot something into the pipeline.

That should keep things under control.

Of course, as far as anything I post is concerned, I'm more than happy to have the support of that left to me.

DT,

firstly Celestia has a VERY satisfactory modular structure, yet for good reasons we have decided AGAINST implementing sound into the core code.

For good reasons we have also decided against implementing real-time gravitational effects, just in case you should bring this up again.

For good reasons we have also discarded to render explosions and to add laser guns . Given the excessively dilute distribution of matter in the Celestia universe, the chances would be tiny to come across an exploding supernova or space station by accident ...

Next: most inexperienced users will merely ask for the resolution of some striking, buggy phenomenon they come across, entirely FORGETTING to tell that they implemented some such "custom" patch in the code before. It usually takes about five vasted mails before you can hope to talk about the real thing.

Since you are also preparing a step-by-step tutorial of how to compile with VS2005 Express, it won't be long until we get to see the first faulty "hobby" results....

As an experienced Celesltia developer, I would certainly never look into your ripped apart code sniplets. It's much safer to just read the code and make subsequent modifications to ones gusto.


Bye Fridger

firstly Celestia has a VERY satisfactory modular structure, yet for good reasons we have decided AGAINST implementing sound into the core code.

I never questioned that decision.

For good reasons we have also decided against implementing real-time gravitational effects, just in case you should bring this up again.

I never mentioned this, but I'm quite capable of implementing it myself should I choose to.

For good reasons we have also discarded to render explosions and to add laser guns . Given the excessively dilute distribution of matter in the Celestia universe, the chances would be tiny to come across an exploding supernova or space station by accident ...

Not if you are studying such phenomenon and know exactly where and when it should occur.

Next: most inexperienced users will merely ask for the resolution of some striking, buggy phenomenon they come across, entirely FORGETTING to tell that they implemented some such "custom" patch in the code before. It usually takes about five vasted mails before you can hope to talk about the real thing.

That's part of the joys of tech support...you're not the only one:

http://www.techtales.com/techroom.html

Since you are also preparing a step-by-step tutorial of how to compile with VS2005 Express, it won't be long until we get to see the first faulty "hobby" results....

I'm actually using VS2005 professional edition under Vista. I also have Fedora 7 on another drive.

As an experienced Celesltia developer, I would certainly never look into your ripped apart code sniplets. It's much safer to just read the code and make subsequent modifications to ones gusto.

I was referring to experienced C++ developers, not Celestia developers.

DT wrote:
I was referring to experienced C++ developers, not Celestia developers.

Which is no contradiction, right? We have been in contact with quite a few experienced C++ devs (from outside Celestia). All could become familiar with the Celestia code pretty fast such as to code modifications.

You are sure aware that gravitational effects at the game level are trivial to code, but they are WRONG in general!

Bye Fridger

Which is no contradiction, right? We have been in contact with quite a few experienced C++ devs (from outside Celestia). All could become familiar with the Celestia code pretty fast such as to code modifications.

I agree. In saying that, there is no point in re-inventing the wheel. If the path to implementing feature can be shortened, then that is a good thing.

You are sure aware that gravitational effects at the game level are trivial to code, but they are WRONG in general!

Implementing gravity, in the context of Celestia, is very straight forward. We can use classical Newtonian physics for this:

F=Gm1m2 / r^2

G = the universal gravitational constant = 6.67 x 10-11 N m2 kg-2

Given that the representations of the planets, or stars are spheres, then we can simply compute a bounding sphere and offset the formula to correct for scale differences.

Its not perfect, it doesn't take into account the various gravitional differences at different points due to the shape and the difference in mass distribution throughout the planet(s). In saying that, even that is not too complex, its just intensive on computation. There will always be a trade-off between functional realism and accurate representation.

As for other objects, then we would need to take into account the shape and the distribution of mass.

DT,

Gravity is not included in Celestia not because it's difficult, but because it violates Celestia's fundamental design philosophy.

Calculating positions due to gravitational effects assumes that time is increasing monotonically. The position of an object at time t combined with its velocity and acceleration due to gravitational effects determines the position of that object at time t+1.

However, time is not monotonic in Celestia. The user can set the simulation epoch to have any value at any time. The simulation's time can be sped up or reversed. As a result, the formulae which are used to determine the positions of objects must have time as the only independent variable. When one specifies a particular simulation epoch, the positions of all objects in Celestia must be/are uniquely determined.

Of course, one can use Celestia to define the locations of major bodies and, if the user realizes the constraints and lets time progress "naturally", follow the path of a massless object through their gravitational fields. Variants of Celestia were created years ago that could do this, with the viewpoint affected by gravity. (The "game" Mostly Harmless was one such. It's still on SourceForge, although its author has disappeared.) These days, one would more likely use Lua scripts to implement this without having to modify Celestia at all. But, still, gravity is certainly not something that would be included in the standard version of Celestia.

DT wrote:
Implementing gravity, in the context of Celestia, is very straight forward. We can use classical Newtonian physics for this:

F=Gm1m2 / r^2

Come on. That trivial formula becomes of course badly wrong in realistic environments! I really thought we could be talking on a different level...

As we know since Kindergarden even a linear combination of such terms is only valid for highly idealized isolated point sources of the gravitational field! Note: this formula implies vanishing diameters of the massive bodies and almost infinitely far separation between them! In reality, this is almost never a valid approximation.

Imagine you are navigating with your spaceship through the Jupiter system with its many close-by moons, each distorting the resulting total field badly, and most of all, it's actually the elliptical shape of Jupiter that requires a completely different expression.

The practical issue is that this can all be taken into account in principle, but requires VERY expensive numerical integrations, which we simply cannot afford.

Sorry, but you are merely demonstrating a thorough lack of physics insight, if you claim:

Implementing gravity, in the context of Celestia, is very straight forward.

As I wrote earlier, game programers don't really care what is physically right or wrong. Usually they dont also have the respective knowledge/formation. From such a perspective your expression is certainly fine . But this is not at all what we have in mind at Celestia development.

Just believe me that I know VERY well what I am talking about

Bye Fridger

Gravity is not included in Celestia not because it's difficult, but because it violates Celestia's fundamental design philosophy.

I never questioned this. t00fri brought the subject up and I said I could implement my own.

Calculating positions due to gravitational effects assumes that time is increasing monotonically. The position of an object at time t combined with its velocity and acceleration due to gravitational effects determines the position of that object at time t+1.

That will break down when if you try to model the rotation of the galaxy. You're getting into dark matter, etc.

However, time is not monotonic in Celestia. The user can set the simulation epoch to have any value at any time. The simulation's time can be sped up or reversed. As a result, the formulae which are used to determine the positions of objects must have time as the only independent variable. When one specifies a particular simulation epoch, the positions of all objects in Celestia must be/are uniquely determined.

I feel that you are over complicating the issue, especially at this stage of development. There is a lot in physics that is still not properly understood and while there are classical formulas, they don't integrate well with quantum systems.

From a development point-of-view, short-cuts can be taken. There is no need to replicate every aspect in real-time, or even to model every aspect of gravitional influence. It would be nice to have, however, its just not feasible given the computational overhead that would be required.

Of course, one can use Celestia to define the locations of major bodies and, if the user realizes the constraints and lets time progress "naturally", follow the path of a massless object through their gravitational fields. Variants of Celestia were created years ago that could do this, with the viewpoint affected by gravity. (The "game" Mostly Harmless was one such. It's still on SourceForge, although its author has disappeared.) These days, one would more likely use Lua scripts to implement this without having to modify Celestia at all. But, still, gravity is certainly not something that would be included in the standard version of Celestia.

I have seen Mostly harmless, I think it should be called Mostly Incomplete or Mostly Useless. I could do a lot more in under a week, than has been done in the entire development of that "game".

As for using scripts, I feel that to be an overhead that would slow things down. I've been working on a TCP/IP server componant that can offload gravitional effects to another system. It pumps the results that effect you into the pipeline. Its only a toy at the moment, but its an interesting concept. I borrowed the idea from distributed grid computing.


t00fri:

Come on. That trivial formula becomes of course badly wrong in realistic environments! I really thought we could be talking on a different level...

I'm well aware of this. I told you that it wasn't perfect and that there was a difference between functional realism and accurate representation.

As we know since Kindergarden even a linear combination of such terms is only valid for highly idealized isolated point sources of the gravitational field! Note: this formula implies vanishing diameters of the massive bodies and almost infinitely far separation between them! In reality, this is almost never a valid approximation.

Imagine you are navigating with your spaceship through the Jupiter system with its many close-by moons, each distorting the resulting total field badly, and most of all, it's actually the elliptical shape of Jupiter that requires a completely different expression.

No offence, but I thought you would have exercised a little common sense when interpreting how such a formula would be expanded during its implementation. Of course fields must interact and I had already covered shape and distribution of mass.

The practical issue is that this can all be taken into account in principle, but requires VERY expensive numerical integrations, which we simply cannot afford.

Which I have already pointed out in my last post...

Sorry, but you are merely demonstrating a thorough lack of physics insight, if you claim:

No, I just have no intentions of spelling out every aspect of what I am describing.

I am replying to a post in a forum, not writing a thesis.

As I wrote earlier, game programers don't really care what is physically right or wrong. Usually they dont also have the respective knowledge/formation. From such a perspective your expression is certainly fine . But this is not at all what we have in mind at Celestia development.

I'm not a game developer, nor a member of Celestia dev. I'm modding the engine as I see fit. Its not really a mater of what is right or wrong, but rather, what is feasible in terms of real-time computation on the average PC.

Just believe me that I know VERY well what I am talking about

We all do and not recognising that has been your first mistake...

selden wrote:DT,

Calculating positions due to gravitational effects assumes that time is increasing monotonically. The position of an object at time t combined with its velocity and acceleration due to gravitational effects determines the position of that object at time t+1.

However, time is not monotonic in Celestia. The user can set the simulation epoch to have any value at any time. The simulation's time can be sped up or reversed.

Selden,

where did you get this argument from?

Suppose we were indeed to include real-time gravity effects for our "spaceship". What we have to do in general is to integrate a (complicated) differential equation (= our "spaceship's" equation of motion) between an arbitrary given value t and some other (neighboring) value t + dt. Here dt does NOT have to be positive! (J key !) and dt can be VERY small. Going backwards in time is perfectly straightforward in case of a gravitational field.

That task remains always true and feasible /in principle/ also in Celestia.

To make the solution unique at t + dt, you need some suitable initial values for the system at time t, which you would typically take from Celestia's time-averaged "default" configuration (VSOP87 etc).

For example, we would start to watch our "spaceship" for some (short) time dt after placing it to some point x0 at time t0 with speed v0=dx/dt|t=t0 . The planets and other bodies would be positioned at initial time t0 according to our time-averaged VSOP87 expansion!

Insert:
As I keep repeating, this is completely analogous to studying the time-dependence of a single electron in a Hartree-Fock background configuration of all the other electrons in the physics of atoms, molecules, solids, nuclear physics... ! The solutions to the resulting non-linear equations behave as if each particle is subjected to the mean field created by all other particles. That's the essence of the self-consistent Hartree-Fock approach!

Every physics student learns how to do this early on in his/her university education.

Back to our problem:
The result of the (numerical) integration from t0 to t0 + dt is unique but VERY expensive. This can be repeated taking t0+dt as initial time, integrating to t0 + dt + dt' and so on. That's all.

I really can't follow your above reasoning. Please explain.

Bye Fridger

Fridger,

You're right of course

Just now I wrote a lengthy missive explaining the difficulty of propagating objects' positions gravitationally for those objects that have osculating orbits defined at different Epochs, but then realized that, of course, those calculations are irrelevant in Celestia, except for the "test body". Celestia's catalogs, by definition, provide the "correct" positions of all of the other bodies.

Given enough computation and appropriate initial conditions for the body with the orbit that's being propagated, one can, in principle at least, calculate the body's current position if one has enough real-time available for doing those calculations.

Of course, if the test body is a spacecraft, those initial conditions will keep changing due to non-gravitational effects: unpredicted thruster activity, for example, or the variable effects of atmospheric drag due to solar heating, depending on how that's included. The test body's position at a particular simulated time will not always be the same. This violates various assumptions in Celestia's code -- the generation of the test body's orbital path, for example, is only done once.

Frank's use of Celestia for Education and his use of sound within it deserve support. While I sense the core developers think that this is merely for game purposes and beneath them, I struggle to see what is wrong with adding such a hook that would allow Vincent to provide Frank with sound. The closer Celestia -ED is to the "real" version of celestia, the better. It a pain for someone who is doing so much work in developing content to also be fighting version issues. It seems the hook that Vicent wants is minor code change with few implications for other Celestia developments. What really are the issues here with making this hook? What other impacts could it have?

In order to avoid the "game feel" about the sound, it should be better a "hook" with a multimedia player, playlists, etc. The question now is: what player we will "hook"?

Hooks are great in principle, but I personally have had to field dozens of questions about Celestia supposedly malfunctioning, when in fact it was an issue caused by the (beta) Lua edu tools hooks and this is probably what Fridger is warning against. BTW, since the Lua tools are in beta problems are to be expected but it does highlight the fact that bugs in hooks may appear to be indistinguishable from bugs in Celestia itself.

dirkpitt wrote:Hooks are great in principle, but I personally have had to field dozens of questions about Celestia supposedly malfunctioning, when in fact it was an issue caused by the (beta) Lua edu tools hooks and this is probably what Fridger is warning against. BTW, since the Lua tools are in beta problems are to be expected but it does highlight the fact that bugs in hooks may appear to be indistinguishable from bugs in Celestia itself.

Correct. I completely agree.

Bye Fridger

Correct. I completely agree.

There is a way around this. If it is something that causes the application to collapse and provide an error message, then there is no reason why the name of the offending extra cannot be passed along.

Other bugs are going to be difficult to track down, however, a -debug switch to enable the output of strategically placed print commands would provide an insight to what what causing the error.

It won't catch every scenario, but it should catch at least 90% and that would be better than nothing.