Orbits and Labels colors

[ElChristou]

Well, seems we will find a solution...
...but perhaps not in public...

[ElChristou]

Ok, because adaptative labels seems to be not so easy to code, here are 3 new palettes created using my above rules. Colors are a bit more vivid waiting for a solution for soft tones. No personal taste here, just the set of rules and 10 minutes this morning.

(BTW, Cham wanted, all stars here are not too bright.)

For sure those palettes still need tuning, but they show that using a few rules makes life easier

(I also add too new items (other grid 1 and 2) in case of necessity).

[t00fri]

Christophe,

in order that we can do some testing we do need a patch relative to the /latest/ CVS render.cpp. Otherwise it's really messy and prone of errors.

Bye Fridger

[ElChristou]

Christophe,

in order that we can do some testing we do need a patch relative to the /latest/ CVS render.cpp. Otherwise it's really messy and prone of errors.

Bye Fridger

You mean we must forget the distance dependent labels, right?
Ok I'll post colors over a fresh render.cpp from CVS in a moment. (then forget the one by mail)

[ElChristou]

CVS don't include Nebulae and Open Cluster separate colors. Could this been added? (dependently of fading labels) or someone can do the right patch?

[t00fri]

CVS don't include Nebulae and Open Cluster separate colors. Could this been added? (dependently of fading labels) or someone can do the right patch?

Of course my code should be added to CVS ASAP! But you will remember Chris L's 1-line verdict about the effective distance dependence of my fading nebula and cluster labels from some days ago...

I have explained thereafter why I think the effective distance dependence of nebula and cluster labels is the only practical approach for now.

http://www.celestiaproject.net/forum/viewtopic ... &start=171

But no answer...

In fact, all it takes in my code to return to app. magnitude dependent fading of the labels is to replace the fixed AbsMag = -8.0f by actual AbsoluteMagnitude values as soon as my IC/NGC catalog is ready. However, AbsMag entries are hardly found in nebula catalogs for good reasons. .

This situation hinders any significant and effective further work for this task. So I am out of this. Sorry. Got no time for that kind of "games". Blowing two days of work "into the wind" with you guys was just enough.

Last not least, I simply dislike such "1-line verdicts" about things where I have put in quite a bit of thought (and experience) before coding...

Instead, I returned to my ongoing preparatory work for the onset of my own "big-size" cosmological visualization project at SF...

Bye Fridger

[t00fri]

Christophe,

in order that we can do some testing we do need a patch relative to the /latest/ CVS render.cpp. Otherwise it's really messy and prone of errors.

Bye Fridger

You mean we must forget the distance dependent labels, right?
Ok I'll post colors over a fresh render.cpp from CVS in a moment. (then forget the one by mail)

Oh I forgot. No, leave the distance dependence in render.cpp!

So if you send me a table with the colors, then I will have to paste the numbers in by hand as long as my code is hanging around, instead of being in CVS...It's really too bad.

Bye Fridger

[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
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"?

So we should check to see if an absolute magnitude has been specified for the object. If not, then we use -8 as the default value for the purpose of labeling. It's a small modification to your current code that would give magnitude based labeling when it's possible and at the same time provide a fallback for nebulae with no absolute magnitude specified.

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.

What are the reasons? The difficulty of providing a meaningful value for an extended light source versus a point source?

--Chris

[Cham]

I don't think an absolute magnitude concept makes any sense for a nebula. Or at least it's very suspect to me. Physically, how do you define it ?

And a switching code between distance and AbsMagn (in cases there's an AbsMagn data) will lead to confusion. I suggest like Fridger to stay with distance dependant AppMagn in the case of nebulae.

[t00fri]

...
So we should check to see if an absolute magnitude has been specified for the object. If not, then we use -8 as the default value for the purpose of labeling. It's a small modification to your current code that would give magnitude based labeling when it's possible and at the same time provide a fallback for nebulae with no absolute magnitude specified.

To retain precisely THAT option was the technical reason why I coded the label opacity formally with AbsMag as a parameter for all 3 DSO members. But further thoughts and discussions over the weekend made clear that a pure distance dependence (i.e. AbsMag=const) is for various reasons the preferrable approach for nebulae and clusters. That's were we actually spent our time on...

I really did a lot of work to investigate this issue in detail, I made distributions of hundreds of respective catalog objects wrto distance and magnitude and studied practical AND physical arguments. Some you can find in this thread.

Sorry, I am NOT going through all this again NOW.

Actually, I don't really care: either you give green light for me to commit that code in render.cpp as IS, such that we can AT LAST continue to work on the label colors more effectively,

or you do whatever you please...and I continue to work on my other projects.

In any case --as Cham also emphasized above-- nebulae like planets, comets etc. need special consideration. In case of planets, for example, the definition of apparent and absolute magnitudes is DIFFERENT from the usual one. One has to include the phase angle, for example. So no "holy universality" anywhere.

In your code for the fading labels of solar system (non-emissive) objects you also chose another dependence instead of mere apparent magnitude. So why all this resistance in case of nebulae that are also special and --unlike galaxies-- comparatively nearby?

Your formula was something like

opacity ~ bounding radius/distance

Yes and there is some relation of the body's radius to AbsMag. That's OK, but also NOT what I used for galaxies, for example.

BUT SO WHAT. Isn't the main point really to avoid label over- cowdedness as function of FoV and to create a nice 3d impression?? After all, my original fading label code is nothing but a close relative of my old code to avoid overlapping location labels on Earth, Moon, Mars, Venus and of the code implementing the automag.

Bye Fridger

[Cham]

There's also a good page here, about nebulae magnitudes which are "special" and can't be treated the same as stars, for example :

http://www.starastronomy.org/Library/loso4.html

In the case of an astronomy software showing nebulae with labels, which is just a visual trick to identify objects without seeing the object itself, I think it's a good compromise to define the apparent magnitude of "labels" (not the object itself) with distance, instead of any other way. And we also gain a clearer picture of the spatial distribution, which the AbsMagn dependance can't give.

[chris]

...
So we should check to see if an absolute magnitude has been specified for the object. If not, then we use -8 as the default value for the purpose of labeling. It's a small modification to your current code that would give magnitude based labeling when it's possible and at the same time provide a fallback for nebulae with no absolute magnitude specified.

To retain precisely THAT option was the technical reason why I coded the label opacity formally with AbsMag as a parameter for all 3 DSO members. But further thoughts and discussions over the weekend made clear that a pure distance dependence (i.e. AbsMag=const) is for various reasons the preferrable approach for nebulae and clusters. That's were we actually spent our time on...

I really did a lot of work to investigate this issue in detail, I made distributions of hundreds of respective catalog objects wrto distance and magnitude and studied practical AND physical arguments. Some you can find in this thread.

Sorry, I am NOT going through all this again NOW.

Actually, I don't really care: either you give green light for me to commit that code in render.cpp as IS, such that we can AT LAST continue to work on the label colors more effectively,

or you do whatever you please...and I continue to work on my other projects.

I'm not yet convinced that distance based label brightness is right for nebula and star clusters. I've read the discussions and appreciate that you've done a lot of experiments with different catalogs. Check in your code as it is, for now. I'll step back from my stance that we absolutely shouldn't use distance based fading for nebula labels, but I've still got concerns that are worth some further discussion and may change what you think about relying on just distance.

In any case --as Cham also emphasized above-- nebulae like planets, comets etc. need special consideration. In case of planets, for example, the definition of apparent and absolute magnitudes is DIFFERENT from the usual one. One has to include the phase angle, for example. So no "holy universality" anywhere.

Yet if we were to implement fading for asteroid and moon labels, wouldn't you agree that the brightness of the label should be based on the apparent magnitude of the asteroid or satellite rather than the distance? Yes, the phase angle must be taken into account, but it's still the case that labeling based on the apparent magnitude is most appropriate.

In your code for the fading labels of solar system (non-emissive) objects you also chose another dependence instead of mere apparent magnitude. So why all this resistance in case of nebulae that are also special and --unlike galaxies-- comparatively nearby?

Your formula was something like

opacity ~ bounding radius/distance

Yes and there is some relation of the body's radius to AbsMag. That's OK, but also NOT what I used for galaxies, for example.

BUT SO WHAT. Isn't the main point really to avoid label over- cowdedness as function of FoV and to create a nice 3d impression?? After all, my original fading label code is nothing but a close relative of my old code to avoid overlapping location labels on Earth, Moon, Mars, Venus and of the code implementing the automag.

I see the main point of labels to be identifying what is visible, not in creating a 3D impression. So my big concern is that labels for prominently visible objects may have their labels omitted because they happen to be far away. What about the NGC 2070 (The Tarantula Nebula), which from Earth is quite a bright nebula despite the fact that it's located off in the LMC?

--Chris

[selden]

There certainly are times when one would like to have particular labels visible at all times. A DSC and/or SSC object of type Label might be appropriate for this.

[t00fri]

There certainly are times when one would like to have particular labels visible at all times. A DSC and/or SSC object of type Label might be appropriate for this.

That has also crossed my mind already at times. For now the foreground task seems to be to take care of the bulk of the appearing labels in a decent manner. The next step would certainly be to allow for exceptions.

Bye Fridger

[t00fri]

..
I see the main point of labels to be identifying what is visible, not in creating a 3D impression. So my big concern is that labels for prominently visible objects may have their labels omitted because they happen to be far away. What about the NGC 2070 (The Tarantula Nebula), which from Earth is quite a bright nebula despite the fact that it's located off in the LMC?

--Chris

You are addressing now some of the real points that make this fading label discussion difficult: depending on the objects there are observables like e.g. the standard catalog parameter "surface brightness" that would have to be possibly taken into account.

M33 is a most familiar example. Apparent magnitude says it's VERY bright, but still it's VERY hard to see due to it's extremely low surface brightness. So what's the relevant characteristics here?

This undisputable complexity speaks once more for a more simplistic approach: just distance. As Christophe repeatedly pointed out, one should see the label brightness as providing ADDITIONAL information about the object rather than the same as the object rendering itself.

At times, I even ask myself how an entirely consequent label fading would look like that for ALL objects would only depend on distance (AbsMag=<AbsMag> = const). Distance is a single parameter that for all Celestia objects MUST be given. And it is a valuable ADDITIONAL information to display via the label opacity.

It's so easy to code, I'll certainly try it out just to be sure (next time it rains in Hamburg over the weekend )

Bye Fridger

[ElChristou]

...
This undisputable complexity speaks once more for a more simplistic approach: just distance. As Christophe repeatedly pointed out, one should see the label brightness as providing ADDITIONAL information about the object rather than the same as the object rendering itself...

If nothing else is possible ok, but Chris is right in wanting to preserve the essence of the label -> to give a name at what is visible.

Another "tool" could be dev to accentuate the spacial position of bodies, but as Cham point out, this is another topic...

[t00fri]

If nothing else is possible ok, but Chris is right in wanting to preserve the essence of the label -> to give a name at what is visible.
...

Sure, I understand this. But then the label opacity should also know about the surface brightness parameter, since this is REALLY the crucial guy that decides who is visible and who is not.

And thus to keep things clean, well-defined AND simple, my plea went back to distance only. Anyhow, eventual changes are easy to implement at a later stage.

Bye Fridger

[Cham]

If we want to progress, at least by some small steps, we should use Fridger's suggestion for some time, until the dev team finds something better. Thus I suggest to use the distance dependance, so we could close that lenghty discussion. Since this isn't a huge code change anyway, it could be corrected at a later stage. During that time, the user could benefit from a usefull (and beautifull) feature, until something better comes.

I can't understand Chris hesitations about that.

[chris]

If we want to progress, at least by some small steps, we should use Fridger's suggestion for some time, until the dev team finds something better. Thus I suggest to use the distance dependance, so we could close that lenghty discussion. Since this isn't a huge code change anyway, it could be corrected at a later stage. During that time, the user could benefit from a usefull (and beautifull) feature, until something better comes.

I can't understand Chris hesitations about that.

I've already invited Fridger to check in his change as is:

Check in your code as it is, for now. I'll step back from my stance that we absolutely shouldn't use distance based fading for nebula labels...

--Chris

[ElChristou]

Now, we do need a distance dependence for Locations... to avoid this: