Spherical terrain, a unique approach...

This topic is 3687 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

This may be old news (the site hasnt been updated in a while), but im curious to hear your thoughts on this approach... http://www.math.uni-bremen.de/~justen/Mich/planetrendering_gallery_e.html?lang=0&stylefile=Layout/default.css I am also using geo clipmaps, and would very much like to understand how this guy is mapping his height map data to the geo clipmap (I assume its in 6 square textures?). Also how does he transform the clipmap from 2d so that it 'hugs' the curve of the sphere? Anyone have any specifics about his implementation? Or any other ideas/advice for for mapping a geo clipmap to a sphere (note I am trying to stay away form the 'spherical clipmap' implementation, in favor of regular square clipmaps).

Share on other sites
Anyone have any insight? You cant deny those videos are pretty cool... He makes it look so easy..

Share on other sites

Currently, this is how im doing things. I simply run 6 geoclipmaps, one for each face of a cube (since cubes map to spheres so easily). That may sound like overkill, but in most cases there is only one clipmap running at a time. The onlytime the other clipmaps get processed/rendered is when the viewer transitions across a 'cube edge', at which point there are some extra draw calls, but its only as bad as how many patches are 'hanging' over a edge. To prevent overdraw, when a parts of a clipmap go 'over' a cube edge, I set the height to -x, backface culling takes care of the rest.

It 'works', but its not as elegant as I would like, thats why im exploring other options.

So, in the second thread, Lutz talks about 'cutting out' a square reqion on the sphere (using clipping plains). Anyone have any details on the math behind this algorithm? Mainly im just curious how you calculate a square region (is it truly square?), on a sphere, based on a camera position. Sounds complicated...

Share on other sites
I haven't worked on this for quite a while, so I don't remember all the details, but maybe I can give some advice.

The 6-clipmap-approach is good. I started with it, too, but dropped it again, since I was concerned about memory usage and couldn't get rid of cracks on the cube edges. In worst case at low altitude near a cube corner you have three fully expanded high level clipmaps, which triples the amount of RAM you need. However, that was at times when I had my RadeOn 9800 with 128 MB. Nowadays with 512+ MB cards, it's not a big deal anymore.

The approach I chose used a single clipmap centered under the camera. Note that there is no continuous 2d coordinate system on a sphere - there are always poles. For instance, the system using longitude and latitude has 2 poles and one can prove that every system has poles. So the coordinate system for the clipmap was kind of tricky. I initialized it with a random right-vector and a forward-vector perpendicular to it and updated those vectors as I moved over the sphere. That meant, when you come back to the same position, the coordinate system was likely to rotate. Though that was not visible, it meant that you always have to interpolate data as you update the heights of your clipmaps, which costs quite a bit of performance (although my implementation of Perlin noise was a bigger bottle-neck).

Anyway, the biggest problem was that the big clipmap levels are pretty much distorted at the boundaries since the were folded on the curved surface. Also note that one clipmap can't span the whole planet - the distortions would be way too bad. So I had to draw a "global" grid, which was simply a low-res subdivided cube blown up to a sphere. However, I had to cut out a hole under the camera where the clipmap was. To do this, I've drawn parts of the global grid four times with a different user clip plane activated for each turn. Each clipmap culled a different side of the clipmap, namely top, bottom, left, right. Computing the clip plane is very simple. For instance, consider the bottom part:
   oooooooo   o clip o   o  map o___XooooooY___ part of the global  grid to be drawn

We only want to draw the global grid part below the clipmap. So you generate a clip plane through three points: The planet center, X and Y. That's it. Note that you get quite some overdraw this way, for instance some area is drawn twice when you do the same thing for the right side.

This approach was not very good. A waaay better thing to do is for instance draw the planetary grid, clear the z-buffer and draw the clipmap over it. You'll also get some overdraw, but it's not worse and way easier to implement. Alternatively, if your planet is sufficiently round, you can draw the global grid without writing to the z-buffer, so the clipmap will just overdraw it. You get the idea. That's not my idea btw., I've talked to some guy but I've forgotten who it was. Note that you don't have to do that, since your 6 clipmaps cover the whole planet.

All in all, my method is far from being elegant and used a lot of hacks, although the end result was pretty neat. I had started a new approach with a single clipmap covering the whole planet, but I never finished it. It combines the cube approach with the one-clipmap approach. The main idea is that clipmap levels need not be square. If they fold around a cube corner, they are L-shaped. While the basic idea is simple, the implementation has issues as well that are hard to describe. But I wanted to throw it in here, in case someone wants to write a paper about it :-)

Share on other sites
Thanks for the reply! Still sounds tricky hehe. The one thing im a little uneasy with is your coordinate system. It sounds like youre using some kind of longitude/latitude? I guess ive just been spoiled with the idiot proof 'cube to sphere' coordinate system.

But anyway...

Quote:
 I had started a new approach with a single clipmap covering the whole planet

! you got my attention! You cant tease us like that, we want some details! A single clipmap, and SQUARE (good)! So its just like the old, super elegant 'cube to sphere' coordinate system I assume? Thats what im looking for, I have grown too attached to my current coordinate system to use anything else!

Share on other sites
I was also inspired by Lutz's engine a few years ago and started work on a similar system. I didn't know about geometry clipmaps, but just from his video showing the wireframe I came up with a system that worked the same way:
When the camera first comes close enough to the surface to trigger the creation of the clipmap, a local coordinate system is established using the vector from the camera to the planet center and another vector (first I try the planet local Y vector and if that is degenerate then I use the X vector). This coordinate system is then updated when level 0 of the clipmap changes, using the new center vertex of the level. To calculate the position of new points on the sphere I simply rotate the center point of the level around the up and right vectors of the coordinate system by the required amount.
I stitched to the planet mesh simply by clearing the zbuffer then overwriting with the clipmap (using alpha blending at the edges, as it is always guarenteed to be closer than the planet object. That worked okay, but was a bit hacky and I didn't like the alpha blending. Recently I have been working on a new approach which I am much happier with: I create the sphere using the same method I use to calculate points on the clipmap, i.e. by rotating a point on the sphere on a local coordinate system for each face, so that all quads on the sphere are the same approximate size, and I can finely adjust the resolution. I cut a hole out of one side, and save the quads that filled the hole as a seperate 'cap' mesh. I also save the indices of the verts that line the edge of the hole. If the clipmap is inactive then the cap mesh is rendered along with the rest of the planet. If the clipmap IS active then I remove the cap from rendering, and create another mesh that stitches the gap between the planet and the clipmap. The planet is rotated to align with the clipmap using the clipmaps local coordinate system I mentioned previously. That means the stitching is updated whenever level 0 of the clipmap updates. Also I apply the inverse transform of the planet to the planet textures. This opens some possibilities I haven't fully explored yet, such as increasing the detail at the outer visible edges of the planet mesh to make it appear more spherical while still keeping the poly count lower than would be required for a static mesh. Maybe this sounds a bit complicated but it actually only took me a weekend to implement the planet and the stitching (admittedly it was the second time I've done it!).

That shows the stitching. The reason I did it this way rather than using the clip-planes is (a) the overdraw is removed, (b) my clipmaps don't have perfectly straight edges and (c) it doesn't need any alpha blending like my previous technique. It seems to produce a perfect stitch and I get 30fps at the planets surface which includes drawing the clipmap ~2.5 times (once for land, and again for the ocean, allowing underwater exloration :D, and a bit of overlap where I split the scene into a close frustum and far frustum for better depth resolution at the water edge), 6 more draws for a reflection cube map (updated every frame, I haven't got around to improving that yet), and a poorly implemented particle based cloud system. This is on an 8800gtx, Core 2 Duo, but I am currently bound by the number of material changes I am doing!

From the surface.

P.S. I have no clue what you mean by 6 clipmaps on the planet? Any change you could elaborate?

Share on other sites
Quote:
 P.S. I have no clue what you mean by 6 clipmaps on the planet? Any change you could elaborate?

The 'old school' way to do a spherical terrain was to start with a cube, and 'push' each point on the cube face out to x radius (the radius of the planet). It allows for easy mapping of your coordinate system (since the cube faces are square, your coordinate system is square as well), its super elegant. So imagine your basic geo clipmap, now imagine 6 of them, one for each face of the cube.

This is what I dont get about the 'single clipmap' method. How in the hell do you guys store heightmaps? And how do you convert a point in 3d space to a point on your planets surface? It seems like if you just select a trvial angle for your clipmap, it would be imposible to establish any kind of coordinate system...

1. 1
2. 2
3. 3
4. 4
Rutin
18
5. 5

• 11
• 21
• 12
• 11
• 11
• Forum Statistics

• Total Topics
631405
• Total Posts
2999887
×