Question How does Orbiter draw it's planets?

[HarvesteR]

Hello,

If this isn't the proper forum, please move.

I've got a question... does anyone know how Orbiter handles it's planets? (in a 3D engine sense?)

The reason I ask is that I'm trying to do a planetary simulation of my own and, although it doesn't come near to orbiter complexity, I still have to draw planets

I took the naive approach yesterday, and created a HUGE geosphere to be my planet, and was faced with some weird texture bugs and floating point imprecisions, all due to the massive scale of the thing... furthermore, as one get's really close to the surface, the horizon becomes distorted since only a few polygons are visible from ground level.

Orbiter does it very nicely, and it's probably much more involved than a simple sphere... The horizon looks perfectly round at all altitudes (and appears flat from ground level)... I was wondering how that was accomplished.

Is it a sphere with multiple levels of detail, so that on ground level there are enough polys to remove the jagged horizon line? or is it something entirely different?

Thanks in advance

Cheers

 

[Rtyh-12]

I don't know, but the spheres aren't always smooth. On the Earth and Moon, yes, maybe on Mars too, but have you ever tried landing on Nereid? (moon of Neptune) It looks like... err, it looks bad.

 

[HarvesteR]

I've tried landing on Deimos and Phobos (more like sync'ing than landing really)... and they too seem to be just simple meshes... then again, given their scales, a basic mesh will do the trick...

But I'm stumped as to how to draw a planet even of a fraction of the radius of earth... A 10km radius sphere is the largest I could get, and at those scales, regular texture mapping looks real bad. Not to mention the immense spikes caused by the polygons... and that is with a geosphere so heavily subdivided that each face bends less than a degree from it's neighbours.

Any thoughts?

Cheers

 

[Rtyh-12]

I've tried landing on Deimos and Phobos (more like sync'ing than landing really)... and they too seem to be just simple meshes... then again, given their scales, a basic mesh will do the trick...

Well, yeah, but Phobos and Deimos are not supposed to be round. Nereid is...

Anyway, I know that Orbiter draws planets/moons with a higher resolution level with a higher quality mesh. Don't know how this could help you though...

 

[HarvesteR]

Yeah, but it can't be simply a heavily subdivided mesh... to get a nice round horizon at low altitudes, we are talking hundreds of thousands of polygons... (my huge sphere had 11000 triangles, and it looked bad even at a hundredth of earth scale)

Cheers

 

[martins]

Orbiter subdivides the planet surface into patches, where each patch has its own mesh and texture. Only patches visible from the current camera position are drawn.

Patches are available at multiple resolutions, and orbiter dynamically allocates the resolution for each patch depending on camera distance and angle.

It uses a recursive quad-tree algorithm to traverse the resolution levels. In pseudo-code it looks somewhat like this:

function render_patch (patch)
  
   is any part of the patch visible from the camera?
   if no, return.

   is the patch at the required resolution level?
   if no, split the patch into 4 sub-patches, and call render_patch for each of them

   render the patch

end

The actual code is quite a bit more complicated. For example, it has a texture request queue that dynamically loads the required patch textures in a separate thread. If you are interested in the details, look at the sources for the D3D7 client on OVP. It uses the same algorithm as the inline client.

 

[orb]

You can always look at sources of D3D7Client, or D3D9Client (sources included in the archive), to check how Orbiter does it. :thumbup:

Well, yeah, but Phobos and Deimos are not supposed to be round. Nereid is...

Number of faces depends on the maximum texture level, and Nereid is only level 4.

 

[HarvesteR]

Cool, I knew there was something more to it.

I'll look into that.

Thanks!!

BTW, if anyone thinks up another cool way to draw planets, let me know

Cheers

 

[Rtyh-12]

Well, yeah, but Phobos and Deimos are not supposed to be round. Nereid is...

Number of faces depends on the maximum texture level, and Nereid is only level 4.

Anyway, I know that Orbiter draws planets/moons with a higher resolution level with a higher quality mesh. Don't know how this could help you though...

What did I just say...

 

[HarvesteR]

Today I took the time to have a look at the D3D7 code, and found many interesting things... For one, I didn't know Orbiter did distance scaling... that's one mystery solved

On second though, it seems pretty obvious now... One has to account for the massive scales involved somehow, now, don't we? Distance scaling is the most elegant method.

Now, I have a question... Martin mentioned each patch has it's own mesh, right? How are the seams handled then?


The reason I'm back in this thread again is that once more I find myself not satisfied with my current planetary terrain approach....

What I have right now is a system that uses a flat, disc-shaped mesh, and conforms it to the planet sphere and the terrain heightmap, which is procedurally calculated in runtime through LibNoise.
This is a very heavy operation, which resulted in me having to split the refresh routine across several update cycles... at the speeds you'll be going most of the time, that isn't really an issue though...

The main problem is that this approach will produce 'unstable' terrain... that is, the mesh vertices are getting moved along, and they have a far lower density than the heightfield... Which means one moment a vertex might be sitting atop a high mountain peak, and at the next, 2 neighboring vertices might be sitting half-way up it's slopes... the end result is that mountains seem to wobble as you go... but worse yet, shorelines move around wildly... (I've done the ocean as another dynamic disk mesh, but without the heightfield, so shorelines are defined by the intersection of both meshes)

So, unhappy with the current state of the planetary terrain, I'm thinking of going the quad-tree way...

The main challenge is that my engine (Unity) defines a mesh as an array of vertices, and it's faces as an array of index references... Which means quad-tree subdividing such a thing would be a real nightmare of indexing...

So I though about the next best thing, which would be to have separate meshes for each patch, and recursively subdivide them... This way the terrain wouldn't wobble anymore... but there would be seams across the different meshes, which would have to be handled...

Also, subdividing a regular sphere would cause a lot of distortion and needless polygons when near the poles...

I though about a solution to the poles problem, which would be to use not a regular sphere, but a rhombic dodecahedron as a starting point (level 0 mesh)... this shape is a spherical solid, and each of it's faces is a quad. So that could solve the distortion problem. Also, by making each patch mesh already a little subdivided, it will look spherical even at the lowest detail level.
Hmm, thinking about it, even a simple tetrahedron could work... only, instead of square patches, we'd have triangular ones.

Anyhow, I'm still a little unclear about the quadtree structure... what happens once a node gets subdivided? Does it become one of the child nodes, or does it start to act as a relay, forwarding calls to it's children and doing nothing by itself?



Any help at this point would be immensely appreciated

Cheers

 

[HarvesteR]

Just a short update on this matter:

I've started working on the quadtree-based terrain, and I must say it's looking good! It's at least 50x faster than the old, stupid approach, which means it can run in real time, without any yielding. It also looks a whole lot better, since the quads can only double of half their vertex resultion, there is no more wobbling of mountains and shorelines.

Now, I'm working on fixing the seams problem... and that entails a whole new problem that is finding the neighbours for each quad... I can fix the seams alright, but I'm still having trouble with keeping the neighbours updated and the tree balanced (making sure the LOD difference between any neighboring quad doesn't differ by more than 1)...

Right now I'm using a brute force solution to balance the tree... If a node detects that a neighbour is 2 or more LODs away, it will subdivide it, which will prompt these new nodes to ask themselves the same question, and so on recursively until the whole tree is solved.

But the problem is that some neighbours are not getting assigned when this forced subdivision happens... even though they all search for their neighbours when they're spawned...

So I started thinking about how Orbiter does it, and more specifically, how does a patch know it's target resolution? Martins said it's based on distance and angle from the camera, but how exactly? If each patch can know it's target resolution by itself, maybe there will be no need to force the tree to remain balanced.

I'll dig through the D3D7 sources, but if anyone can explain it quickly here, I'd greatly appreciate it

Cheers