I'm trying to figure out a way in a space sim for a ship to fly in space and then to land on a planet seemlessly. I'm not sure graphically what work is needed to do this. I know there might be an issue with LOD and coordinates but I don't know much more than that. Any ideas or web links that you guys know of that might help me figure out what it is going to take?

Have a look at Ysaneya's journal for information about his planetary engine, then weep. [smile]

Dang. That is some nice stuff. Unfortunately I didn't see anything technical on how he did that. I may send him an email asking though! ;)

hmmm... i think theres some good tutorials that he used for it. I'm not sure if this is one, but i think he mentioned that he used some ideas from this guy (Ysaneya used SP O'neil)

But O'Neil has lots of good tutorial links that he has on his website, that might require free subscription to gamstura, but they're great reads and very informative.

His website is SP O'Neil's Website

Sean's stuff is definitely good to start with. IIRC he uses a ROAM-like approach. This is a link to his articles (just search for "Sean"). ROAM is (in its simple form) not well suited for modern hardware, since you can't store the geometry in VRAM.

Ysaneya uses another approach. He uses square patches with 31x31 vertices and larger (256x256 or 512x512) textures. He starts from a cube (with 6 patches) and then refines the patches - obviously in a very clever way. This approach is very well suited for modern hardware. Each patch can be stored in VRAM. But the refinement is very tricky. It's difficult to hide the jumps between different LOD levels. Moreover, the generation time for each patch is significant (can be more than a frame time), so you need to generate the patches in the background. Ysaneya does this in a separate thread. (*Hope I don't write rubbish here*)

Another alternative is geometry clipmaps. I've tried this (see link below), but it's rather difficult to apply it to a sphere since you can't really make a single quad fit to a sphere! Clipmaps are also well suited for the hardware and in my eyes you get the smoothest transition between LOD levels.

I'd start with ROAM, though.

Quote:Ysaneya uses another approach. He uses square patches with 31x31 vertices and larger (256x256 or 512x512) textures. He starts from a cube (with 6 patches) and then refines the patches - obviously in a very clever way. This approach is very well suited for modern hardware. Each patch can be stored in VRAM. But the refinement is very tricky. It's difficult to hide the jumps between different LOD levels. Moreover, the generation time for each patch is significant (can be more than a frame time), so you need to generate the patches in the background. Ysaneya does this in a separate thread. (*Hope I don't write rubbish here*)

A few fixes / precisions:

- patches are not 31x31 but 33x33 ( in general, 2^n+1 ); this allows to split a patch in 4, and end up with children which are still 2^n+1.

- you're right that popping problems are currently my nightmare; both in geometry and texture. For geometry, geomorphing in a vertex shader can be used to hide the transition. For texture, blending can be used for the same effect. Seams between adjacent patches are hard to handle, too.

- i do not generate patches in the background (although i was doing in my 2 years-older version). There are two things: geometry generation and texture generation.

Geometry generation is done by sampling a global heightmap (calculated at load time or precalculated for specific planets), and when reach the maximum resolution, use Perlin noise or Diamond square to add noise details, up to a few meters above the ground.

For texturing, i'm using a queue of requests that the GPU processes in a serie of pixel shaders. Each shader takes the 33x33 patch, upsamples it to the texture size (256x256), applies filters, adds noise details, and then performs many lookups to do detail texturing based on conditions like slope/altitude (like per-pixel splatting).

A good GPU can fullfill 50-100 requests per second, but when a patch is split it queues up 4 requests at once (since a patch is split in 4 children). Filling 4 requests at once would lead to a little slowdown, so i'm spreading this over many frames. Currently, there's a limit of 1 or 2 texturing requests maximum to process per frame.

The big advantage of this technique is that it allows me to generate a terrain that is looking unique everywhere, with some pretty nice details (see screenshot below) and very hardware friendly. The drawbacks are the popping/seams problems, and the system requirements (good pixel shading GPU).



Y.

Ysaneya,
How are you dealing with coordinates? Do you have a seperate system for solar coordinates and planet coordinates? What sort of method are you using to seamlessly convert from one to the other and when?

Thanks for the replies guys. I can see if I go down this path I am going to have a lot to chew on!

[Edited by - happylrac on January 10, 2006 10:10:39 AM]

I have three spaces: world space, object space and camera space. In world space, all objects positions are in 64 bits floats. A terrain patch is generated in object space, the vertex positions are in 32 bits floats. At run-time, i render everything in camera space: the objects in world space are calculated in camera space (all the calculations are done internally in 64 bits) to cancel out the big numbers in the matrices. Once this is done, i can submit the objects in 32 bits floats, and as i no longer have huge numbers in the transformation matrix, i've avoided the precision problem.

Y.

Out of curiosity will your engine support any non-uber cards? I have the distinct feeling this is one of those engines that require a multi hundred dollar video card with specific features available only to the very top range cards. I suppose this could be the standard by the time you complete your engine. Looking good though. Ive been following your project. Keep up the good work.

I doubt i'll ever add support for cards under pixel shader 2.0. My game will be released (best base) in 2 years; and there are already AAA games released *today* that have this requirement..

Y.