Planet grids

[ElChristou]

...There are two problems: first of all, most planets have the color left at the default value of white (or [ 1 1 1]). But, I don't think that a black grid--which seems to be what would be derived via your method--would look good for most planets.

The second problem is more fundamental: the color specified in the ssc file is intended to be normalized so that the largest component is 1.0. This means that there's no value information present in the color at all. The actual value of the planet disc is derived from albedo, phase, distance to viewer, and distance to the illuminating star.

Mhhmm... don't follow you well... do we talk about the same? I was referring to the planetshine; how do you define the color used to illuminate orbiting object?

[chris]

...There are two problems: first of all, most planets have the color left at the default value of white (or [ 1 1 1]). But, I don't think that a black grid--which seems to be what would be derived via your method--would look good for most planets.

The second problem is more fundamental: the color specified in the ssc file is intended to be normalized so that the largest component is 1.0. This means that there's no value information present in the color at all. The actual value of the planet disc is derived from albedo, phase, distance to viewer, and distance to the illuminating star.

Mhhmm... don't follow you well... do we talk about the same? I was referring to the planetshine; how do you define the color used to illuminate orbiting object?

We're talking about the same thing. The color used for planetshine is the same color used for rendering ssc objects as points when they're too small to be resolved as discs: the ssc Color property. For the reasons I explained above, this color can't be used (effectively) to determine what color that grid should be drawn in.

--Chris

[ElChristou]

Understood!

[SU(3)xSU(2)xU(1)]

I think, that it would be nice to include tropics, arctic and antarctic circles in planet grids. They are well defined at least for planets (the only parameter, which set their position is the angle between planet's rotation axis and it's orbital plane).
I realise, that the issue is more complicated for moons, objects with unusual orbits (without well defined orbital plane) or unusual rotation (without well defined rotation axis). That's why I propose an additional boolean parameter. It's value would decide about displaying these 4 circles. It would look like that:

Code: Select all

"Earth" "Sol"
{
 (...) # all other parameters
 EnableTropics true
 }


There are two possibilities of displaying tropics, arctic and antarctic circles. They could be just parts of the grid, but they might also be displayable separately (like the terminator). They could also move in very long time scales, adjusting to eventual changes of the angle between planet's rotation axis and it's orbital plane. What do you think?

Paul

P. S. These circles should look quite funny on Uranus

[Guckytos]

P. S. These circles should look quite funny on Uranus

I don't think that this would really be usefull. It would only make sense for planets that are in the habitable zone and for all the others, as you already said in the quote above, it would be nonsense.
And how would you calculate them anyways for planets other than earth (solar system bodies) itself?

The grid itself is a good idea, that shouldn't be filled with too much information.

Just my 2 cents.

Regards,

Guckytos

[chris]

P. S. These circles should look quite funny on Uranus

I don't think that this would really be usefull. It would only make sense for planets that are in the habitable zone and for all the others, as you already said in the quote above, it would be nonsense.
And how would you calculate them anyways for planets other than earth (solar system bodies) itself?

The grid itself is a good idea, that shouldn't be filled with too much information.

Just my 2 cents.

The calculation of the tropics, arctic, and antarctic circles is straightforward for both planets or moons. For a planet, the tropics are at a latitude equal to +/- the obliquity (angle between the pole and orbital plane.) The latitudes of the arctic and antarctic circles are +/- 90 minus the obliquity. For moons, you can get a very close approximation by replacing the obliquity with the angle between the moon's rotation axis and its planet's orbital plane. This approximation only becomes problematic when the moon's orbital plane is substantially different from the planet's (e.g. the moons of Uranus) and the moon orbits at a distance from the planet that's some significant fraction of the planet to sun distance. In other words, the approximation is fine for any of the moons in our solar system except possibly some of the rocks orbiting the outer planets.

I'm in agreement with Guckytos, however: I don't think that showing these circles is especially useful.

--Chris

[t00fri]

I'm in agreement with Guckytos, however: I don't think that showing these circles is especially useful.

--Chris

I completely agree. Why don't we let Mr. "Standard Model" motivate ourselves about the need for this feature.

So far his argument was merely that it would be "nice" to have.

Fridger

[Hungry4info]

I don't see the point. For tidally locked worlds, such as GJ 876 d, the ideas of arctic, tropic, and such zones gets rather distorted. Furthermore, a lot of that involves an atmosphere. Venus is pretty much the same temperature everywhere, for example.

I must say I think the idea is useless.

[piellepi]

Hi Celestians!
Sorry to bother you: perhaps it's a feature of the planet grids...
Selecting the grid for the planet Venus (with clouds), I had this image

and then deselecting clouds I had this picture
.

Is it possible to have the grid over the clouds or am I doing something wrong?

Ciao
Pierluigi

[chris]

Noticed this issue with the grid labels that appear visible even when there is a body between the observer and the world that has the grid on.

RPCROSS3_celestia_grid_3.png

This issue has been fixed for a couple weeks in the SVN version.

--Chris

[duds26]

Being able to set the grid over clouds and other stuff would be usefull to the observer to see the grid.

And being able to change the grid number color and background transparency and color.
(Want to set it to a white opaque background with black letters to have maximum visibility.)


The ideas of arctic, tropic and other such zones isn't of much use.

Howerver, in an addon being able to define circles with customizable rotation, color and name modmakers want to implement seems a good compromise for this
(and could mayby (never say never with if it can't be used) be usefull in some cases for some addons ).

This way, you still can make an addon for it if you want to. If this is possible with celaddons.

[ElChristou]

I don't know why, I have some trouble with the above...

[samsmartguy]

Maybe you should think about thickness and color of lines for example I think that the equator must be different color.

[cartrite]

I got Planet Grids working on KDE. I also got all the reference frames working. Here is a patch for selectionpopup.cpp.

selectionpopup.txt.zip

Screenshot:

reference-marks.jpg

This works for me. I'm not sure what I should test to see if it fails in certain cases.
If we get this tested, this will eliminate one of the things to do list for 1.6.0

cartrite

[ElChristou]

I got Planet Grids working on KDE. I also got all the reference frames working. Here is a patch for selectionpopup.cpp.

There is a last option available in the code for the reference marks submenu , the terminator... (do you have it?)

[Imy]

I don't know how difficult it could be to code now, but as you ask for suggestions, I wonder if selecting a box of the grid could be fun! I don't have a precise and a global view of such feature, but for example, you press a special key and point with mouse over a box of the planet grid, then, the program changes camera position in order to be perpendicular to the surface. We can then even center this in the screen or why not zoom in or out. Now, I see that feature as an easy way to locate on planet surface. It could be steps where for every step more local information appears and a more precise grid is drawn to follow the zoom in.
It would be a feature between spatial interface and surface interface, wouldn't be?

[cartrite]

I got Planet Grids working on KDE. I also got all the reference frames working. Here is a patch for selectionpopup.cpp.

There is a last option available in the code for the reference marks submenu , the terminator... (do you have it?)

not yet. missed that. I was looking at the Win32 code from r4206. The terminator was added in 4247 I think. I thought there were more items then I had actionID's for. I'll have to move the alternate textures up a few and see if it still works.

The QT4 code didn't make any sense to me. Anyhow, I wanted to get what was in the kde menu working first. I got it working last night and went to bed. I'll have me another look today.
cartrite

[cartrite]

I got Planet Grids working on KDE. I also got all the reference frames working. Here is a patch for selectionpopup.cpp.

There is a last option available in the code for the reference marks submenu , the terminator... (do you have it?)

Now I do. I removed the old patch and uploaded a new one.

selectionpopup.txt.zip

You have a keen eye. Thanks.
Looks like our poor planet got shot up with arrows pretty good. Hope it lives.

reference-marks2.jpg

cartrite