Ever heard of P-BDAM?

Abstract:
"This paper describes an efficient technique for out-of-core management and interactive rendering of planet sized textured terrain surfaces. The technique, called P-Batched Dynamic Adaptive Meshes (P-BDAM), is based on BDAM structure. Data is partitioned into a set of BDAM tiles, each of them constituted by a pair of geometry bintrees of small triangular patches and an associated texture quadtree. Each triangular patch is a general triangulation of points on a displaced triangle. The proposed framework introduces several advances with respect to the state of the art: thanks to a batched host-to-graphics communication model, we outperform current adaptive tessellation solutions in terms of rendering speed; we guarantee overall geometric continuity, exploiting programmable graphics hardware to cope with the accuracy issues introduced by single precision floating points; we exploit a compressed out of core representation and speculative prefetching for hiding disk latency during rendering of out-of-core data; we efficiently construct high quality simplified representations with a novel distributed out of core simplification algorithm working on a standard PC network. "

- Watch videos here.
- Read paper here.

You can see plenty of "roughness" especially along the terminator (the line between light and darkness). Just look at the half moon through a telescope. Of course, on Earth most of the surface is covered by flat ocean so you'd only see good shadowing if you look at the right spot at the right time (like photos of the Himalayas taken by ISS crew)... The effect is certainly more visible on smaller planets or moons. Look at Mimas or Miranda for example. Phoebe is even more extreme but it's more like an asteroid in size.

Quote:
Ever heard of P-BDAM?

I wonder why everybody is going crazy about this technique.. it is the 4th or 5th post i've seen this week speaking of it.

Sure it's nice and fast, but geez.. 7 hours of preprocessing, and 6 GB of disk space ?

Show me the same without any preprocessing and with reasonable disk usage, and then i'll be impressed..

Y.

Ysaneya, well show me a technique which achieves the same amount of detail / visual fidelity at the same speed and I'll happily post that link as well :)

The 5GB are mainly there because they use high-resolution NASA datasets. On the other hand, every solution which uses multi-resolution representation of geometric data, be it multiresolution-batched meshes or image pyramids (geoclipmapping!) will suffer from a severe overhead of course.

You could also use smaller datasets and add a fractal-based algo for continuous level of detail on the surface, normal mapping etc. and it'll look smooth and would be well suited for games.

Quote:It's not the height of a mountain which is important, its the slope. Although from space you don't actually see the shape of the mountains of a real planet, you do notice them because of lighting. It's like normal mapping! The normal maps don't generate bumps, but different shades. The same is true for mountains. The more variations in the slopes, the more the lighting will vary.

the height _is_ definitely important for edges of the planet, that's where you see features popping out, and normal/offset mapping can't do a thing about it. sure, slope is also important, but so is height (of course if the whole surface is displaced 200 Km upwards, it doesn't make a big difference ;))