OpenGL Procedural Planet Generation - Quadtrees and Geomipmapping

Started by
28 comments, last by ray_intellect 11 years, 2 months ago

It still hates my computer, but I'm also running Windows 8. Do you have visual C project files or something?

Advertisement

I didn't give the whole project because the size is rather big but if it'll allow you to compile the whole thing too see it there's no problem. It was going to be OpenSource anyway. The problem is it relies on several libraries such as DevIL and SFML 2.0

I still can't get it to build on my PC. I tried remaking project files for my version of VS, but I think I might as well upgrade to 2012 express sometime soon anyway. Is there any chance you can post a video of it running? Sorry if I'm not being very helpful, I'm getting cramped for time with other things.

I'll try get a video up soon. I've not been working on the project for a little while over frustration. This positioning stuff is really annoying. It should be simple but there's something screwing it up somewhere.

have you considered using the OpenGL 4.0 Tessallator?

The tesselator as far as i can tell is not good for LoD like this. I would still need to split it into patches for the tesselator to act on. I believe the tesselation acts on the full model and not just the area near you. Not to mention the fact that not many people have access to OpenGL 4.0

Actually I think the opposite might be true. The tessellator is very good for terrain rendering and LoD, however the shader is difficult to implement.

I started to write a spherical patch renderer based on a cubemap projection (similar to yours) several years ago (probably 2008).

I would probably get rid of the patched sphere terrain idea and use a spherical coordinate grid ( with north and south pole ) . I think its perfectly easy to divide the spherical coordinate sphere into patches based on latitude and longitude, and if you think about it, the patches will be very close to square at high resolution - the downside to this is the fact for bigger planets you have more terrain visible at each height before the horizon. However for larger worlds, you don't need to tessellate until you are quite near the surface, and then you just need fine detail on surfaces like mountains and bumpy areas. I know this might sound obvious. So you would want a method for determining the curvature variation for distant mountains, and of course they could often be rendered into a cube map and morphed. And what about the errors on the north and south pole ? Well you don't want your players to go there, they wouldn't want to go there because the poles suck, obviously. On a cubemap patch grid there are 8 problem regions with a lot of warping. So perhaps you could render a mesh over the top of the spheres - if you really wanted your players to go hunting Arctic hares for example - you could drape a patch over the top and morph the two models / artistically merge them.

edit: in fact if you remove the point at the top of a spherical coordinate grid and a couple of rings you have a circle of vertices at the top, if you think of these as like the hour marks on a clock, you can join 1 O'clock to 5 O'clock, and 2 to 4, 12 to 6 etc, and the same for the horizontal direction, so then you have an easy way to patch over the top.

Anyway the google link I posted has a terrain renderer at the top of the search. It is based in Python ... my only criticism of the source is that to run the program on my desktop PC I had various issues - first I downloaded Python 3.3 (I don't have python on my desktop computer) and nothing worked, so I downloaded Python 2.7 and found out that the library required Python 2.5, so I downloaded this, and found out that another library needed Python 2.6, so eventually when I tried to run the code - it didn't even build.

I think if you really want to use a patch system based on a cube, then I think chunked lod is the best scheme for rendering the surface - see Thatcher Ulrich's code

However I really think CPU based patches are a Kludge compared to GPU methods.

Also you might need to look into efficient mega texturing.

Vangoule, on 05 Feb 2013 - 06:54, said:
The tesselator as far as i can tell is not good for LoD like this. I would still need to split it into patches for the tesselator to act on.

If you really want to go the all GPU route, you can stick your quad-tree in a vertex buffer, use a geometry shader to perform the LoD split/combine operations on the quad-tree, use transform feedback to store the result back in a vertex buffer, and use the tesselator to actually tesselate and render the various patches in the quad-tree.

I had a quick prototype of this up and running last year, and it worked pretty well, though I never got around to polishing it up for release.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Using an actual sphere rather than using a cube seems a much harder way to actually accomplish what i'm doing. The cube system i'm using now shows no seams and the heights carry on perfectly due to the noise being 3D using the position of the vertex. The only thing i need to worry about at the moment is splitting it into patches which is the thing that's not working. GPU Tessellation would be nice but that doesn't change the fact i still need patches for it to work on. I'm at the point of ripping my hair out with this Quad Tree. The positioning just won't happen...

Well, actually the spherical coordinate system wouldn't be as easy to map to a quad tree. Instead you could try creating large tiles in the latitude and longitude grid, these tiles could be numbered, then you could have a function that takes the visible section of the sphere and returns the tiles you need to display, Then you could select a tessellation level based on the distance between the viewer and a patch, and of course, the patches would probably subdivide, so perhaps a transform feedback approach would work.

And for your current problem of splitting into patches, perhaps have a single patch for each grid level, and use instancing to render these where they are required, so instead of splitting them into patches, perhaps you could start with a fine grid of tiles, and each tile represents a patch instance.

This topic is closed to new replies.

Advertisement