Varying transparency of star & galaxy labels

[t00fri]

ElChristou,

let me just report that I played a bit with your suggestion to make labels of more distant objects (stars, galaxies,..) increasingly transparent. As Chris mentioned already, the required code changes are utterly trivial .

What is not quite as straightforward is to find a suitable quantity related to the 'distanceToDSO' and ranging between 0 and 1 such that distant objects correspond to the smaller values and close-by objects to the larger ones. Well I tried a few possible such variables.

Anyhow, so far the resulting label display does not really excite me. We can go of course "private" on this again if you have further ideas

Cheers,
Fridger

[ElChristou]

Have you tested with asteroids? I think we should begin with this because of the quantity of bodies, the effect of 3D should be easier to catch in that case...

Can you post here the code change necessary for this? (if you have time...)

[t00fri]

Have you tested with asteroids? I think we should begin with this because of the quantity of bodies, the effect of 3D should be easier to catch in that case...

Can you post here the code change necessary for this? (if you have time...)

That's too complicated, really since one has to experiment with different distance definitions.

go to render.cpp and look for

Code: Select all

renderer->addLabel(dsoDB->getDSOName(dso),
                           Color(0.1f, 0.85f, 0.85f, 1.0f),
                           Point3f(relPos.x, relPos.y, relPos.z));


it's about line 7269.

The label transparency (here for galaxies) is the 4th entry in Color(). 1.0f is totally untransparent. 0.0 is invisible, i.e. totally transparent.

Now you may enter there some function of the DSO distance: (float) distanceToDSO, such that it ranges between 0 and 1.

In case of stars it's absolutely analogous. The rendering routine is just higher up in render.cpp.

Bye Fridger

[t00fri]

Have you tested with asteroids? I think we should begin with this because of the quantity of bodies, the effect of 3D should be easier to catch in that case...

Can you post here the code change necessary for this? (if you have time...)

Well asteroids...

If ony I had a bit more time .

I have told you that the implementation of asteroid culling (which we urgently need for being able to display MANY of them quickly) is complicated. The reason is that unlike stars and galaxies asteroids are constantly moving. Hence sorting them into a suitable octree structure becomes a time dependent affair, which tends to eat up all the gains we got in the first place.

But all is NOT lost...just requires some R&D. If I can manage to map the asteroid orbits to some suitable, quasi stationary=time-independent" coordinates, we may sort wrto these!

Think for example of an object moving exactly on a circular orbit. Hence the RADIUS of that orbit does not change in time and could again be used for culling...

Also I should definitely write another PERL script that extracts the REAL asteroid data base from the official archive. I am not so fond of bdm's synthetic asteroids...

+++++++++++++++++
But since I played with large numbers of asteroids some years ago already, I can tell you that in the standard field of view you rarely see all that many of them...so your envisaged 3d beauty is perhaps not so evident either, here...
+++++++++++++++++

But let's hang onto this...

Cheers,
Fridger

[Malenfant]

Well the asteroid *orbits* aren't moving, are they? (i.e. they don't precess over time). I know that half the time I don't want to know where the actual body is on the orbit, I just want to see what the orbit itself looks like...

Maybe if we had an option to just display the orbits rather than the bodies on the orbits, that might make things easier? If the orbits are stationary then that would significantly reduce the processing time.

[t00fri]

Hi again,

here is a concrete example for galaxy labels with distant-dependent transparency that works quite well. I actually constructed the function distr(distanceToDSO) with Maple.

Whoever is interested and knows how to compile from CVS, replace the code between the parantheses in line 7266 of src/celengine/render.cpp by this

Code: Select all

    {
        float distr = 1.0f/log10(1.0f + 1.0e-6f * distanceToDSO);
       renderer->addLabel(dsoDB->getDSOName(dso),
                           Color(0.1f, 0.85f, 0.85f, distr),
                           Point3f(relPos.x, relPos.y, relPos.z));
    }


To test switch on galaxy labels (E) and type into the command line:

Code: Select all

m 91 <return>
c


then play with "SHIFT mouse left" (zooming by moving).

You will see normal, untransparent and weaker, more transparent labels, depending on how distant the galaxies are from the observer. You may also play a bit with the contant 1.0e-6f in the variable distr above.

With star labels it's completely analogous, except that you have to adapt that constant.

Bye Fridger

[buggs_moran]

Well the asteroid *orbits* aren't moving, are they? (i.e. they don't precess over time). I know that half the time I don't want to know where the actual body is on the orbit, I just want to see what the orbit itself looks like...

Maybe if we had an option to just display the orbits rather than the bodies on the orbits, that might make things easier? If the orbits are stationary then that would significantly reduce the processing time.

As a quick short term solution you could probably run a find/replace search in a text editor and comment all Mesh and Texture lines out... (i.e. replace Mesh with # Mesh) that way it would be easy to reverse.

[ANDREA]

Hi again, here is a concrete example for galaxy labels with distant-dependent transparency that works quite well. I actually constructed the function distr(distanceToDSO) with Maple.
With star labels it's completely analogous, except that you have to adapt that constant. Bye Fridger

Hello Fridger, sorry for my probably stupid question, but this sounds similar to my own problem: could it be adapted for labels and orbit lines visibility (not dimmeriring) too?
If I understand what you are doing, perhaps it could be close to the solution of my problem: I need to show planet/moon labels and their orbits independently from their distance from the observer, in order to show in a detailed way the Ptolemaic, Tychoniac, Copernican Solar Systems, here
http://shatters.net/forum/viewtopic.php?t=9369&postdays=0&postorder=asc&start=15
where as you see the labels (here not shown, but it happens), orbits and epicycles disappear with distance (and/or the objects radii?).
Am I wrong?
If I'm right, do you think we can have any hope to see it implemented in some way some day?
Thanks a lot for the information.
Bye

Andrea

[t00fri]

Hi again, here is a concrete example for galaxy labels with distant-dependent transparency that works quite well. I actually constructed the function distr(distanceToDSO) with Maple.
With star labels it's completely analogous, except that you have to adapt that constant. Bye Fridger

Hello Fridger, sorry for my probably stupid question, but this sounds similar to my own problem: could it be adapted for labels and orbit lines visibility (not dimmeriring) too?
If I understand what you are doing, perhaps it could be close to the solution of my problem: I need to show planet/moon labels and their orbits independently from their distance from the observer, in order to show in a detailed way the Ptolemaic, Tychoniac, Copernican Solar Systems, here
http://shatters.net/forum/viewtopic.php?t=9369&postdays=0&postorder=asc&start=15
where as you see the labels (here not shown, but it happens), orbits and epicycles disappear with distance (and/or the objects radii?).
Am I wrong?
If I'm right, do you think we can have any hope to see it implemented in some way some day?
Thanks a lot for the information.
Bye

Andrea

Andrea,

once again to be sure: You want labels etc NOT vanishing with increasing distance from the observer?

I started off in our TF1.x releases with introducing labels that only show up if the /apparent/ luminosity of objects exceeds a certain threshold value. Also there is some automag philosophy involved to avoid overcrowded labels (dependent on field of view).

It seems now you would like the opposite for your application?

Bye Fridger

[ANDREA]

Hello Fridger,..... I need to show planet/moon labels and their orbits independently from their distance from the observer, in order to show in a detailed way the Ptolemaic, Tychoniac, Copernican Solar Systems, here
http://shatters.net/forum/viewtopic.php?t=9369&postdays=0&postorder=asc&start=15
where as you see the labels (here not shown, but it happens), orbits and epicycles disappear with distance (and/or the objects radii?).
Am I wrong?
If I'm right, do you think we can have any hope to see it implemented in some way some day?
Thanks a lot for the information.
Bye Andrea

Andrea, once again to be sure: You want labels etc NOT vanishing with increasing distance from the observer? I started off in our TF1.x releases with introducing labels that only show up if the /apparent/ luminosity of objects exceeds a certain threshold value. Also there is some automag philosophy involved to avoid overcrowded labels (dependent on field of view). It seems now you would like the opposite for your application?
Bye Fridger

Yes Fridger, correct, I have the need to show ALL the Ptolemaic System planet/moons labels and orbit lines (including the epycicles) independently from their distance or, even better, with the possibility to tune (e.g. in the .cfg file) their showing with the distance from the observer (otherwise, correct me if I'm wrong, letting them "always" ON, I'll see the "a", "b" and so on labels of all the extrasolar planets in the FOV, right?).
Thank you for your kind reply and for any help you'll give me.
Bye

Andrea

BTW, Fridger, thank you for your suggestion on the SATA II HD, it's very quick, appreciated!

[t00fri]

Andrea,

good to hear that your SATAII works well. Mine is also amazing. VERY quiet, super fast and not getting hot.
It's great to have 250 GB just for imaging work. So never any shortages

As to the labels. It's trivially easy to modify the code such that you always see the labels and orbits. But this is not a good solution for everyone. So we might consider some switch when Chris is back from Bolivia.

Cheers,
Fridger

One day we really should have a good coffee together when I am in Rome next time . But this may well take another year. This fall/winter, I'll be in Lisbon and then in Valparaiso/Chile.

[ANDREA]

Andrea, good to hear that your SATAII works well. Mine is also amazing. VERY quiet, super fast and not getting hot.
It's great to have 250 GB just for imaging work. So never any shortages
As to the labels. It's trivially easy to modify the code such that you always see the labels and orbits. But this is not a good solution for everyone. So we might consider some switch when Chris is back from Bolivia.
Cheers,
Fridger
One day we really should have a good coffee together when I am in Rome next time . But this may well take another year. This fall winter, I'll be in Lisbon and then in Valparaiso/Chile.

Fridger, why a coffee, it's better a couple beers, do you agree?
I'll be very happy to meet you in Rome, when you'll visit it for your job or for holidays.
Regarding the labels, well, I can say only....
HOOOORRRAAAAYYYYY!!!!!
Your solution would allow everyone to choose the final result as needed, and this could be useful for other situations.
Thanks a lot, Fridger, very very kind indeed.
Bye

Andrea

[t00fri]

here is an example image from around M 91, where you can get an idea how ElChristou's idea of distance dependent label transparency would look in practice.




Bye Fridger

[buggs_moran]

Those 10000 dso labels can really fill up the sky. This change also gives a feel for distance. Great idea guys.

[ElChristou]

here is an example image from around M 91, where you can get an idea how ElChristou's idea of distance dependent label transparency would look in practice.

Not bad!!
With a bit more tuning it will be pretty cool... now another step would be to give the orbits a "density" depending of the observer distance... feasable?

[t00fri]

Those 10000 dso labels can really fill up the sky. This change also gives a feel for distance. Great idea guys.

It is a great idea , but those 10000 dso labels should NEVER fill up the sky. After all, the automag protects overcrowdedness of labels, if everything is properly set.

In other words the number of labels remains ~constant when the field of view decreases (upon zooming in).

Bye Fridger

[t00fri]

here is an example image from around M 91, where you can get an idea how ElChristou's idea of distance dependent label transparency would look in practice.

Not bad!!
With a bit more tuning it will be pretty cool... now another step would be to give the orbits a "density" depending of the observer distance... feasable?

What is also neat is this: if you travel towards a galaxy whose label was dim originally (Goto). Then you see the label gradually brighten upon getting closer. And it's really simple to code (see above)

I am looking forward to trying the same effects with the star labels. I guess there the effect will even be more dramatic.

I'll also having a look at orbits.

Cheers,
Fridger

[t00fri]

OK here is a little image how star labels now look like.



Cheers,
Fridger

[ElChristou]

OK here is a little image how star labels now look like...

I won't be able to test this because since Chris new stars rendering, I don't get any longer the stars labels... (probably an osX bug...)

[Paolo]

Well
Its really cool!
I hope that will be included in 1.4.2
If the factor that drives the transparency should be adjusted using a slider in the GUI instead that being hard coded should be even more amazing.
So perhaps also the ANDREA's problem should be easyer to solve.

Kind regards