General Question What would be needed for creating ellipsoid planets in Orbiter?

[Urwumpe]

Hello everybody,

just like the thread title says, this question is about finding out what kind of changes in Orbiter and rendering clients would be necessary to support proper ellipsoid planets, like the WGS84 reference for Earth. One possible component that could need work might be how the surface bases are mapped. Also, do we stay at geocentric coordinates only or to we add functions for geographic coordinates into Orbiters API? (Its not THAT hard to perform the transformation in add-ons, though)

I find it a bit disturbing to see a perfectly spherical Jupiter, when in the real world, you just need a binocular to see Jupiter is not a sphere at all.

The first goal is to find out, how much effort this really is and then if others agree on the need for it. And in a second phase, have a plan how to do a contribution to Orbiter for it.

 

[n72.75]

To top it all, the original MOC data was mapped into an areographic reference frame, while MOLA and HRSC are using areocentric coordinates. For the current Orbiter Mars data, I mapped MOLA to areographic, but now it makes more sense to map everything to areocentric (and it better matches Orbiter's rendering geometry anyway). Also, I am now using elevation data referenced against the reference sphere instead of the geoid, so the oblate ellipsoid shape of Mars will be correctly represented.

To quote the Doctor, it is currently possible for terrain, we'd just need to reprocess.

For atmospheres (physics and rendering) we would need to add an "Oblateness" parameter.

Visually this is obvious with Jupiter and saturn. But it actually presents us with operational problems for NASSP, because the AGC expects an ellipsoidal Earth in programs like P22 etc. Also our launch site radius has to be cheated a bit for the LVDC to work.

 

[Urwumpe]

To quote the Doctor, it is currently possible for terrain, we'd just need to reprocess.

But that would get us negative altitudes, which create problems of their own. Also, the terrain resolution could suffer, if the altitudes must span even extreme values. I think the oblateness factor is better for solving many problems, especially since the terrain data is relative to a reference ellipsoid.

 

[n72.75]

But that would get us negative altitudes, which create problems of their own. Also, the terrain resolution could suffer, if the altitudes must span even extreme values. I think the oblateness factor is better for solving many problems, especially since the terrain data is relative to a reference ellipsoid.

We have negative altitudes currently on the moon. Also Vesta, Phobos and Deimo

The landing pads at Brighton Beach are 2.56km below mean lunar radius.

This is hovering at 0 altitude on the Moon.


Mars already has this too, without issue. And it's about 40km flatter around the meridians, similar to Earth altitude difference, but earth is bigger.

A numerical "oblateness" would still be needed to correct calculations like this:

    // convert geometric to geopotential altitude
    const double rad = 6.05184e6;
    alt *= rad/(rad+alt);

orbiter/Src/Celbody/Vsop87/Venus/Atmosphere/VenusAtm2006/VenusAtm2006.cpp at b8162a69e8a5b7134ee9486431e2627c12847c38 · orbitersim/orbiter

Open-source repository of Orbiter Space Flight Simulator - orbitersim/orbiter

github.com

But that's super easy to add. No challenge at all there.

Just wait a minute. We can just flatten the graphics by reducing the length of polar axis in a matrix. Which would leave the sunlight occlusion checks. This would not work for planets with land-able solid surface.

What if we only did this for:

• The lowest LODs (Level 1-3)
• The shadow check.
• Anything without: TileFormat = 2

 

[jarmonik]

Making Jupiter an ellipsoid shouldn't be a problem. Although, the horizon ring is ray-traced and needs a remake. The Earth would be a major problem because the atmospheric ray-tracing extensively relies on spherical symmetry transforming all related math equations in 2D, that's no longer the case with ellipsoid. Everything would need to be reworked on much more complex level. So, I guess for time being, the Earth would need to remain spherical on a visual level only, of course, it's radius could change depending on camera latitude.

EDIT: Visual and physical terrain still need to match.

Sunlight occlusion checks with ellipsoid shouldn't be a problem.

The lowest LODs (Level 1-3)

I am not sure what you mean there, what if the planet's surface is composed from level 3 and 4 tiles. The tile edges still need to match.

 

[jarmonik]

There is one other possibility to render a planet into a texture, let's say 512x512, and then render the texture on screen in smaller size and flattened so that the planet image becomes ellipse. Right now if the Earth is view from a great distance, let's say from the Moon, it doesn't look good at all because of sharp pixels. This technique could improve the quality of distant rendering due to anti-aliasing.

 

[n72.75]

Making Jupiter an ellipsoid shouldn't be a problem. Although, the horizon ring is ray-traced and needs a remake. The Earth would be a major problem because the atmospheric ray-tracing extensively relies on spherical symmetry transforming all related math equations in 2D, that's no longer the case with ellipsoid. Everything would need to be reworked on much more complex level. So, I guess for time being, the Earth would need to remain spherical on a visual level only, of course, it's radius could change depending on camera latitude.


EDIT: Visual and physical terrain still need to match.

Sunlight occlusion checks with ellipsoid shouldn't be a problem.

Given the complexity of implimenting something like that, perhaps it makes more sense to wait until we're working on a successor to D3D9 (and have removed D3D7) clients, just so we don't have to figure out how to do it twice. So this would not be a proposed Orbiter2024 feature.

I know I've seen examples of it done in other software, so I'll probably do some light reading of our code (probably over my head at the moment), and be on the lookout for papers on the subject.

I am not sure what you mean there, what if the planet's surface is composed from level 3 and 4 tiles. The tile edges still need to match.

For planets with elevation data--to the best of my knowledge--Orbiter uses a spherical mesh for L1-L3, and level 4 and above use elevation data. all I was saying was that if you have ellipsoidal elevation data for your higher levels, we'd probably want to squish the lower ones to match so there wasn't an abrupt transition in geometry as you got closer to a planet like Jupiter, where it would be visually obvious.