Celestia Forums

Hello,

I noticed that Celestia (1.3.1) doesn't seem to handle binary stars. Searching the forum, I couldn't find any interesting posts about binary stars support status, except that one of the problem with binary stars was the need for multiple light sources.

Has anyone got more information?

In anycase since I was thinking about how I could help with Celestia coding, here are my 2 cents:

CASE 1: handles only binary stars without planets or asteroids orbiting them.

This is straigthforward. Both stars orbits a virtual mass (m1xm2/(m1+m2))at their barycenter. (and if we don't care about an "accurate" movement for the barycenter in the galaxy, we can even have one star orbit the other (non inertial reference frame linked to the reference star).)
We don't have to worry about the two light sources since there are no bodies to light (except the stars but they are already bright enough without the light from the other star) .

CASE 2: handles binary stars with orbiting objects far away
Distance between the 2 stars << Distance barycenter - orbiting object

If the objects are small, the motion of both stars aren't changed and we can assume that the objects are orbiting a mass (m1+m2) at the barycenter.

We can assume that there is only one source of light at the barycenter. However the distribution of light varies with angle and time since in some direction a star hides the other at a certain time.

CASE 3: general case. N bodies problem (N>=3 )
Needs numerical integration. (maybe OK for real time and short simulation but wouldn't sit well with time acceleration, setting the simulation beginning time to any value other than the one corresponding to initial conditions and/or very long simulation)
Needs two light sources.

--->Too complex???

Maybe everything I talked about is already implemented in Celestia 1.3.2-pre??
If not, I might try to code it (when and if I finally manage to make my way through Celestia code), but I will need to know what we want Celestia to do for binary stars (What level of support are we expecting? case 1, 2 or (I hope not) 3?)


Comments?

Astro,

No, multi-star objects are not yet possible in Celestia.

There have been many discussions about binary stars and gravity. I'm surprised you were unable to find them.

Before you jump into coding, you need to read some more about Celestia's philosophy. Without doing that, you'll be making some fundamental mistakes.

For example, numerical integration is a big no-no in Celestia. The position of each object must be calculated with time as the only independent variable. The position of an object at any specific epoch must calculable by providing only the simulation date. It must not depend on the previous positions of any other objects. The window that Celestia displays at one refresh may be for a completely different time from the frames before and after: at any instant the user may specify a different simulation date. As a result, the positions of all of the visible objects are recalculated from scratch for every frame refresh, so the calculations must be as fast as possible.

Orbits usually are represented by their Keplerian elements, which are specified with respect to a central body. That body can be an invisible object representing a barycenter. Of course, when multiple bodies with similar masses are orbiting a common center, their individual Keplerian orbits have to be specified carefully if one is trying to represent a grouping that's physically possible.

I hope this helps a little.

selden wrote:
For example, numerical integration is a big no-no in Celestia. The position of each object must be calculated with time as the only independent variable. The position of an object at any specific epoch must calculable by providing only the simulation date. It must not depend on the previous positions of any other objects. The window that Celestia displays at one refresh may be for a completely different time from the frames before and after: at any instant the user may specify a different simulation date. As a result, the positions of all of the visible objects are recalculated from scratch for every frame refresh, so the calculations must be as fast as possible.

I knew about that. That's why I said Case 3 caused too many problems.

But still that doesn't prevent us from coding case 1 (or even 2). We would then be able to have double stars without other orbiting objects.

But Celestia can already sort of handle these if we define the stars as planets orbiting a non-visible star. So maybe there is no need for coding anything... except to tell the user that these are "stars" and not planets and that the orbiting planets far away are not orbiting a single real star.

An example would be the Rigel Kentaurus triple stars system.

In Celestia 1.3.1 components A and B don't move.

We could have A and B orbiting virtual mass ma.mb/(ma+mb) at A+B barycenter. (period is about 80 years)

We could also have (A+B barycenter) and C orbit virtual mass mc(ma+mb)/(mc+(ma+mb)) at ((A+B)+C) barycenter, but the period for this movement is probably so long that we might not care.

I may be mistaken, but I was under the assumption that the stars in Celestia did not yet have the ability for "stellar evolution". Is that possibly something we could expect in the future?

Thanks, --Starman

You can, sort of. AFAIK. The stars are a hack. Perhaps the best example of this is the Myriad system over by mostylharmless.

The hack is basically you create a star will zero radius. This will be your center of gravity. Then you create two planet and make them into stars via configuring the planets with thick atmosphere, and a bright glow. The real limitation at the moment, is that you can only have one light source in the systems.

I have to praise you programmers for being so creative. I'm sure you'll figure out a way to add a second light source.

Here's a question: how would the selecting objects by name work in a binary system?

It would be convenient to be able to type "Alf Cen B" from any point in the simulation rather than "Alf Cen/B" or "Alf Cen/Alf Cen B", as at least in all recent version stars are accessible from the "top level" of the tree.

Planet selection I think should work on a similar basis: if the system is grouped together it should be possible to select planets around one component of the system from the other component, e.g. if I am in the vicinity of Alpha Centauri A and there is a planet around Alpha Centauri B called "x" I should be able to select "x" by ENTER x ENTER rather than having to work from the top.

From Alpha Centauri A it would be convenient to be able to select Alpha Centauri B by typing "B", however I can see this may cause problems with extrasolar planets (e.g. from Errai A would "B" select the planet Errai A b or the star Errai B?)

And perhaps .ssc syntax should be expanded to handle things like grouping proper motion companions or free-floating planets.

Just a suggestion or two.

Guys,

Before anyone jumps on me for being combative, I'm not, honestly. This is just an observation...

It occurred to me that the problem with introducing true binary systems was one of data availability. However, Grant has already refuted this in another thread (he says he has BAGS of data for Binaries, which is V cool)

Does the problem lie with light sourcing? I dunno why this would be, because games have been produced using OpenGL with multiple light sources.

Does it lie with Temperature calculation? Nah, you guys are way too clever for that bit of code to be an obstacle.

I don't know where this issue lies on the development priorities ladder, I just wonder what the issue is?

Please don't flame me for this one... I love Celestia, I revel in all its works, and I love you all too (not biblically of course)

Keep up the stunning work, and keep the faith guys, you are producing a continual masterpiece...

I'll shut up now,

Cormoran

Comoran,

As best I can tell, the problem is simply the lack of skilled programmer time.

The number of people who are interested in adding Celestia features and who have the necessary skills and knowledge of C++, OpenGL, geometry and astronomy and who have the time to actually do the programming are, shall we say, very limited in number.

I think it did to begin with have to do with the light source. True that you could have many “directional lights” but at the time I think that video cards could only support one “omni light.” The reason why it was left out is because the addition of the second light would cause all the textures to go nuts. i.e. the cards could not figure out the lighting and shadows correctly. To some extent if you want to see this happen make an object, Ring World or Dyson Sphere [it must be a single object.] and loop it around the star. Basically the render cant make up its mind if its casting a shadow (dark side) or in (light side), so what tou would end up with is lighting that seems to come form nowhere casting shadows, where there are none.


With that all said, I don’t know if the latest OpenGL drivers and cards have fixed the problem or not.

This could really hinder the evolution of Celestia as a whole. A majority of the stars in our galaxy are binaries. Many are close binaries.

--Starman

I suspect that at some point it will be necessary to merge the syntax of stc and ssc files, because not only will binary stars become necessary, so will free-floating planets and the like: whereas TMR 1C was not a planet, there are almost certainly non-stellar objects drifting around out there, and it would be handy to position them using stc-style positioning.

I'm not skilled but this is mine.

Are that "true" multiple star systems are a bit too far for our PCs?
Even if a skilled coder solve the problem (about orbits over multiple masses). Isn't it too much for actual cpus?
I say. My celestia is very slow at startup, loading the huge 2.1c 2million stars database, and very slow calculating objects in space travels.
I don't know how and when star positions are calculated:
a) at startup? If so, how many time to calculate multiple stars positions?
b) in real time? When rendering? If so, how many fps would travel Celestia?
Sorry if I misjudged the problem.

What about a transition solution?
a) In addition to planets, asteroids, spaceships etc in .ssc add a "stellarcompanion" class (instead of an emissive-true planet).
b) These "stellarcompanion" are not stars at 100% for Celestia, but a hybrid between planets and true stars.
c) These "stellarcompanion" are treated as planets for orbits. Even if mass is the same of the main star (alfa cen, for example), they just orbit around.
d) These "stellarcompanion" are rendered even out of the stellar system, as stars. Like stars, they can eclipse main stars (to have eclipse variables implemented)

Notes:
a) imho, not hard to do.
b) ad a), just a new class
c) in other words, planets with stellar shape
d) too see them from earth!!! I don't know how are .ssc treated.
-if loaded at startup, Celestia creates a virtual db to take count of all the "stellarcompanions" planetes in Celestia, and render them as stars also from many ly
-if loaded only when approaching stars (ie planets are only selectable near the parent star), is it possible to change the whole thing?
Just parse at startup all the .ssc files in a specific directory, like "multiple stars" to know what "planets" are to be rendered (the "stellarcompanions") and what are to be hidden, as now.

As above, sorry if I have misjudged the problem.

Regards,
Paul Timpanaro