Orbits and Labels colors

[ElChristou]

..it feels very awkward if you travel to a bright labeled star and passes a darker labeled star on the way, it really doesn't make any sense to me...

It's one of the point I dislike with magnitude dependent label, but indeed Chris is right.

[Cham]

[Now any idea on a distance dependent rendering for manipulations at large scales of any system? via markers?

This is OFF TOPIC.

[julesstoop]

Chris,
I do have a feeling it is worthwhile, especially when roaming around in interstellar and intergalactic space.

I would even go further and allow for an option of purely depth cued display of stars themselves (so all stars are normalized to a standard brightness). Even if it were just for the educational value of being able to show that Deneb must be very bright if it suddenly disappears when you toggle to and from depth based display mode.

Something like: "look people, this is what the sky would look like if all stars were as bright as our own Sun, and this is what the sky would look like if all stars were as bright as Rigel.", etc...

I'm not sure though if an option like this should be a feature of the core Celestia package itsself.

[Cham]

Again, this is OFF TOPIC !

[ElChristou]

[Now any idea on a distance dependent rendering for manipulations at large scales of any system? via markers?

This is OFF TOPIC.

True. Let's return to the important here.

Vivid colors or smooth ones?

If smooth, any way to have an adaptive label working on all render path?

[Cham]

If smooth, any way to have an adaptive label working on all render path?

This is making things already more complicated than what it is right now. This may even affect FPS, which is already at its limits. And I don't think Fridger or Chris are ready to put more time on this, just to satisfy your need for "smooth" colors.

And let me recall you that my palette is already "smooth", with just few more intensity here and there to help the readability.

[ElChristou]

If smooth, any way to have an adaptive label working on all render path?

This is making things already more complicated than what it is right now. This may even affect FPS, which is already at its limits. And I don't think Fridger or Chris are ready to put more time on this, just to satisfy your need for "smooth" colors.

Cham, you are not the indicated to argue on code modification, it's a dev job.
Again you take things the wrong way. I'm waiting for a consensus. If the vote is vivid colors, no problemo to me. Won't be "my" taste but I repeat no problemo.

Will you accept the contrary?

[Cham]

What "vivid" colors ? There is NO vivid palette here !

[ElChristou]

Cham, I'm out the topic for now, let's breathe a bit.

I repeat the use of smooth color will be a problem soon or later with a body having a similar color.

If an adaptive label is possible (or other solution to contrast the label) it would be excellent.
Else vivid colors are necessary.

Perso I'd like to see the first solution.

[Cham]

Cham, I'm out the topic for now, let's breathe a bit.

I repeat the use of smooth color will be a problem soon or later with a body having a similar color.

If an adaptive label is possible (or other solution to contrast the label) it would be excellent.
Else vivid colors are necessary.

Perso I'd like to see the first solution.

First : this adaptive feature could be added later.

Second : it's again OFF TOPIC. We are currently making the labels better than what it was. This is already a great step forward, BEFORE adding any adaptive feature.

[dirkpitt]

Just to show how personal tastes can really matter here, I don't really like either ElChristou's or Cham's palettes. Actually, I think "a little bit of both" works for me.

In principle however, I think the labels don't have to be that vividly distinguishable, because labels are just meant to be optional annotations. Also, except in the case of location labels, most of the time the label background will be black so a high contrast label color is not really needed. In short, a subtle palette that's closer to ElChristou's is probably a better choice overall IMHO.

[t00fri]

I don't care for the idea of distance based fading of nebula, open cluster, or any other labels. I think that it should always be based on apparent magnitude.

--Chris

It would have been great if you had made that ingenious comment 2 days earlier. Then we all could have spent the weekend otherwise!

I'll go away now and spend my time on more useful things...

I was unfortunately too busy with other things in my life to follow every forum thread this weekend. Anyhow, experiments with different labeling approaches are interesting and useful even if they don't end up ultimately being included in Celestia.

--Chris

Perhaps even more than you, I have to economize the little spare time I have available for Celestia. Your attitude of letting us "experiment" for a whole weekend and then eventually cut the results short with one sentence is both uneffective and unacceptable in style!

Of course there is a very good reason for why I implemented a mere distance dependence (for now) for fading nebula and cluster labels, while galaxies depend on apparent magnitude. My above code

Code: Select all

  unsigned int labelMask = dso->getLabelMask();
   
    if ((labelMask & labelMode) && dot(relPos, viewNormal) > 0)
    {
    Color c;
    float appMagEff = 6.0f;
    switch (labelMask)
        {
            case Renderer::NebulaLabels:
                c = Color(0.85f, 0.35f, 0.29f);
                appMagEff = astro::absToAppMag(-8.0f, (float) distanceToDSO);
                break;
            case Renderer::OpenClusterLabels:
               c = Color(0.38f, 0.71f, 0.58f);
               appMagEff = astro::absToAppMag(-8.0f, (float) distanceToDSO);
                break;
            case Renderer::GalaxyLabels:
            default:
                c = Color(0.1f, 0.85f, 0.85f);
                appMagEff = appMag;
                break;                 
        }
        if(appMagEff < labelThresholdMag)
        {
           // introduce distance dependent label transparency.
           float distr = 6.0f * (labelThresholdMag - appMagEff)/labelThresholdMag;
           if (distr > 1.0f)
               distr = 1.0f;                               
           renderer->addLabel(dsoDB->getDSOName(dso),
                              Color(c.red(),c.green(),c.blue(),distr),
                              Point3f(relPos.x, relPos.y, relPos.z));
       }
    }


uses a uniform dependence on ABSOLUTE magnitude for all three DSO kinds. However, specifically, I set AbsMag CONSTANT (-8.0f) for nebulae and clusters, which then implies a mere distance dependence.

The reason was that otherwise the fading labels would break hundreds of existing nebulae and cluster add-ons that are ALL lacking an AbsMag entry!


So how did you imagine this problematics solved in your one-line reply about apparent magnitude dependence?

Once my forthcoming IC/NGC data are available for nebulae and clusters, we can always check for existing AbsMag entries and otherwise work with AbsMag = -8.0f, a convenient value. I thought you like the approach in terms of "small steps"?

If you check e.g. in Simbad you will find that AbsMag is usually NOT quoted in catalogs for nebulae! This has good reasons, of course.


Bye Fridger

[ElChristou]

...I think the labels don't have to be that vividly distinguishable, because labels are just meant to be optional annotations. Also, except in the case of location labels, most of the time the label background will be black so a high contrast label color is not really needed. ...

BUT right now we cannot avoid vivid ones for the reason previously explained.

If an adaptative label is not possible someone will have to find another idea.
Chris emitted the idea of a shadow, wil this run on all rendering path?

[ElChristou]

Because "some" people here seems to not understand how I define the palette I've proposed, here are the simple rules I used.

1) Graduante colors by groups of objects:

- Planets/Moons
- Asteroids/Comets
- DSOs (Galaxies/OpenClusters/Nebulae)

2) Avoid too close colors between groups and else objets

3) Use of smooth colors to gain visual comfort


To this 3 simple rules, one must also think in the relations between groups and others objects and between any objects in general. The groups above follow a logic related to those relations.
For example, will the moons orbit will be used with the DSOs labels? if not very probable, then the color relation of moon orbits vs DSOs labels got less priority than for example the one for Stars label vs DSOs labels...

To do well and because those explications seems to be needed by some, I'm ready to discuss the topic till complete agrement of how those colors should work together.

Once this exercice is over then the palette can be composed again.

**

Cham express the use of colors related to an average chimical composition of bodies. IMO it's a valid option BUT then it must be systematic (or else it's not a valid point of view). This become the one rule for all labels colors, no aesthetical here, just facts.

I know almost nothing of the average composition of nebulae or asteroids or comets, but perso I fear such solution will lead to a very chaotic palette (unpleasant/uncomfortable)...
But perhaps I'm wrong so we should explore also this possibly.

**

The debate is still open, so guys let's see more logic could be used here.

[Cham]

Here's a comparison of both palettes. You'll notice that it's almost the same set of colors (the colors at the right are a bit more intense, for the ease of reading on screen, especially in the case of planets and locations, since the background may be very different from one case to another).




Now some objective crittics :

In the case of the left palette :

1- The stars labels aren't of the same kind of color as their associated orbit. This is inconsistent with the rest.

2- The stars labels are "vivid" and agressive on screen while in Celestia (yellow on black), especially when many stars labels are shown, even with the transparency effect. Actually, the transparency effect has some problems in the case of yellow on black. It appears ugly on screen.

3- Labels are much harder to read on planets background. As I have shown above, the planet name may be totally unreadable for several cases (Venus, Earth, Uranus, Neptune, and even Jupiter), WITHOUT adding some new "adaptive" code to Celestia.

4- The nebulae and clusters labels are too alike. In Celestia, it's very hard to tell which is which. This isn't good, since nebulae are physically very different in nature than clusters (even if they are DSO objects). They don't have to be in the same "familly" of colors, since it's confusing and kills the usefullness of labels.

5- The galaxies labels are harder to read on screen, as shown above.

6- The planet label/orbit colors are of the same kind as for the openClusters, which is confusing.


In the case of the right palette :
1- Some labels and orbits are a bit too "vivid" and may be "agressive" on screen. This is the case of the Moons labels and orbits, and of the Locations. The Locations need to be "vivid", because of the body's texture (planet, moon), and it's about the same as for the left palette anyway (barely harder to read, since it's just a bit less "vivid"). The Moons labels and orbits need to be changed.

What else ?

Some may say that the asteroids, comets, nebulae and galaxies labels are "vivid", in the case of the right palette. Well, they must take into account the transparency effect, which reduces considerably that intensity (especially in the case of the galaxies). So I don't think that we could consider these labels as "vivid", while in Celestia.

A good compromise could be to use the Moons labels/orbits from the left palette into the right palette. I will test this to see if there isn't any conflict with other similar colors (stars and openClusters in the right palette).

[ElChristou]

Too quick Cham...

I'd like you to explain why not using some gradient colors for DSOs (whatever color we chose).

I chose this group because those 3 kind of bodies are under a same denomination (DSO). The idea is to recognize bodies in two steps: this color seems to be a DSO (group of color), let's have a closer look, ok, this is an open cluster... See what I mean?

It's also why I say that DSOs and stars for example should not use a similar color...

This reason sounds simple and almost stupid, but for Mr EndUser or for a student it will be useful... I suppose...

[Cham]

This reason sounds simple and almost stupid, but for Mr EndUser or for a student it will be useful... I suppose...

Nope. In the classroom, I don't teach "DSO". DSO is a vague term and isn't that usefull. In all the books I'm using for teaching (I'm using three), nebulae, galaxies and clusters are very separate subjects shown in separate chapters. And for a very simple reason : they aren't of the same scale of size and distance, and aren't of the same physical state (gaz, clusters of stars, and, well, entire galaxies). And they really don't look the same ! So a clear distinction at the labels level is necessary.

[ElChristou]

This reason sounds simple and almost stupid, but for Mr EndUser or for a student it will be useful... I suppose...

Nope. In the classroom, I don't teach "DSO". DSO is a vague term and isn't that usefull. In all the books I'm using for teaching (I'm using three), nebulae, galaxies and clusters are very separate subjects shown in separate chapters. And for a very simple reason : they aren't of the same scale of size and distance, and aren't of the same physical state (gaz, clusters of stars, and, well, entire galaxies). And they really don't look the same !

Beside I understand perfectly your point, something tells me that the DSO denomination visible in almost all astronomy paper is not here for nothing...
Of course I'm not specialist on the matter to discuss this with you...
Fridger was fine with this group a few post above, perhaps more opinion would help?
I still think that determining at first sight this is a star this is a DSO is useful. Using 3 really different colors for DSO gives you 4 colors to pick from to determinate what is a star among x labels... (off course here I'm talking from the ground point of view...) This is IMO uncomfortable.

[Cham]

Having a different color for the clusters and nebulae also helps to see the spatial distribution, one versus the other.

[ElChristou]

(BTW, all my arguments are based on automag of course...)