Rendering procedural planets.

About the actual programming of the game.

Rendering procedural planets.

Postby croxis » Thu Aug 22, 2013 4:42 pm

Based on feedback from ChemicalR I'm cross posting all the things I've bookmarked in reguards to planet rendering here in the code forums.

Sean O'Neil's 4 2001 part series is considered a foundation for realistic large scale (planets on up) rendering. Most of these methods are now obsolete and replaced with faster methods and gpu shaders. His atmospheric scatteringmethod is still used often due to its relative simplicity, but it only produces earth atmospheres.

Steven Wittens 2009 multipart series is frequently linked to as I've searched for best practices in creating planets using modern methods. It is based on a cube with mesh texture and normalizes the vertex points into a sphere. The advantage to this method is that conventional terrain LOD methods, often used in first person or third person games with vast outdoor scenes, can be used at a planatary scale. A simple normalization will result in a bunching of vertexes near the edges. There is a proof which will normalize the vertex in a way that results in polygons of equal area. Here is my vertex shader that demonstrates both methods. Here is a video of his method creating a small almost-sphere asteroid moon using an adaptive quadtree. Keep in mind that this object is, before shaders, a cube.

At Siggraph 2007 Maxis did several presentations on the methods they used for spore. They used a brush method to alter the heightmap. I haven't looked too much into this method yet but, combined with a quadtree-based storage system, might be a great way to handle player influences (craters, open pit mining) on a planet.

I bookmarked this site a while ago. This site has 10 tutorials that focus more on procedural generation of various planet types. My project takes place in our solar system so I have not spent much time looking into procedural generation practices.

Random interlude: How homeworld did its background.

Eric Bruneton has published a number of recent (2008-2012) on realistic rendering. One such is a precomputed atmospheric scattering shader which, while more complicated, is an improvement to oneil's.

John Whigham blog has covered assorted procedural planet generation elements.

Another paper (2011) 82 pages covering ROAM to river systems. Link to pdf at bottom

Miguel Cepero's blog coveres the development of his Voxel Farm engine, which is now being used in EQNext. His blog covers procedural generation as well as voxels.

Proland is a GPL3 "C++/OpenGL library for the real-time realistic rendering of very large and detailed 3D natural scenes on GPU"

There is another site in german with a lot of tutorials on procedural planets. Alas I could not find it.
croxis
 
Posts: 282
Joined: Tue Aug 13, 2013 1:37 am

Re: Rendering procedural planets.

Postby croxis » Thu Aug 22, 2013 9:15 pm

Two updates.

Here is a thesis that helps explains bruneton's atmosphere scattering method. Video

VTerrain contains links to a lot of sources on real time terrain rendering.
croxis
 
Posts: 282
Joined: Tue Aug 13, 2013 1:37 am

Re: Rendering procedural planets.

Postby mika » Fri Aug 23, 2013 11:32 am

KnightVision wrote:What kind of planet rendering algorithm are you wanting. This is a field I have studied for years. I even have physical books on this very subjects sitting here on my desk.

Wow, it's cool to have an expert in this with us.
I am not a lead in this project, but an algorithm that isn't just black-and-white planet types would be cool. Also, it would have to be very diverse, preferably written in GLSL, and easy to map to a approximate sphere.

That's just my 1 1/2 cents.
Alex ********, proud owner of 2 Rasberry Pi's (Home auto) and this PC, have been programming since I was 9, I know Java, C#, Python, HTML/CSS/PHP (Good at code, horrible at design), various assembly languages (including DASM), and C/C++
User avatar
mika
 
Posts: 31
Joined: Tue Aug 20, 2013 4:25 pm
Location: Boise, ID

Re: Rendering procedural planets.

Postby mika » Fri Aug 23, 2013 11:41 am

KnightVision wrote:I do not like minecraft BLOCK-LIKE planets.


I think we were planning on mapping a cube to a sphere by normalizing, or mapping a Mercator map onto a sphere. The algorithm would be real-time, on the fly.
Alex ********, proud owner of 2 Rasberry Pi's (Home auto) and this PC, have been programming since I was 9, I know Java, C#, Python, HTML/CSS/PHP (Good at code, horrible at design), various assembly languages (including DASM), and C/C++
User avatar
mika
 
Posts: 31
Joined: Tue Aug 20, 2013 4:25 pm
Location: Boise, ID

Re: Rendering procedural planets.

Postby JTxt » Sat Aug 24, 2013 12:09 pm

KnightVision wrote:What kind of planet rendering algorithm are you wanting.

Planet construction: 2d heightmap sphere (pit mining) Dynamic height map (pit mining, craters... gravity enforcing, no caves/floating islands) with custom ships/buildings sitting on top, seems to be the current consensus. But please discuss.
JTxt
Art Lead
 
Posts: 94
Joined: Tue Aug 13, 2013 5:08 am

Re: Rendering procedural planets.

Postby mrout » Sun Aug 25, 2013 2:29 am

KnightVision wrote:
JTxt wrote:
KnightVision wrote:What kind of planet rendering algorithm are you wanting.

Planet construction: 2d heightmap sphere (pit mining) Dynamic height map (pit mining, craters... gravity enforcing, no caves/floating islands) with custom ships/buildings sitting on top, seems to be the current consensus. But please discuss.



Out of curiosity, is everyone OK with the idea that each voxel represent a tiny cube ?


No, because voxels aren't necessarily cubes. Do I need to put that in the IRC topic or something?
mrout
 
Posts: 731
Joined: Mon Aug 12, 2013 10:49 pm

Re: Rendering procedural planets.

Postby JTxt » Fri Aug 30, 2013 8:39 pm

I just saw this in IRC posted by Eldalar:
http://www.volume-gfx.com/
Perhaps some of these posts about voxels, terrain... may be useful here too.
JTxt
Art Lead
 
Posts: 94
Joined: Tue Aug 13, 2013 5:08 am

Re: Rendering procedural planets.

Postby Eldalar » Sun Sep 01, 2013 2:38 am

Though there is a small problem with the algorithm as it is given in the paper/articles, or I simply read them wrong and overlooked the part where they correct that.

Basically when a small cube borders a bigger cube and you calculate the vertice on the edge between the two (weighted by the differences in size so it isn't being pulled out towards the bigger cube) it is still distorted from when two cubes of the same size border each other, because the centers of the two cubes aren't on one axis.
Also there is the problem, that the edges aren't the same size, bigger cubes produce far bigger edges then smaller cubes (naturally).

Though I think I have found a solution, basically once you are at the last step, you pick the smallest of the 8 involved cubes, with him you calculate the vertice that all four cubes share, you then construct a 1x1x1 cube (as in the smallest possible cube) at that position. Then you construct three 1x1x"smallest size-1" sized cuboids and place them at the +x,+y and +z axis. last you make three "smallest size-1"x1x"smallest size-1" sized cuboid to place at the faces that are bordered by those first "edge-cuboids", so +x/+y , +x/+z and +y/+z. The edge-cuboids and the corner-cube can become the edges and corners for that cube, because of their size acting as if that cube was made of cubes of the smallest size. And the face-cuboids are just that, faces.
The 7 dualcells created that way together with those around them now form a grid of "simulated" one cube sized dual-cells with larger face cells between them.

It naturally multiplies the amount of dualcells by 7 and thereby increases the amount of vertices and faces that have to be drawn, but I think those two effects, while not that obvious on a planet would be catastrophic on ships, since it makes the exact look of the ship dependent on factors that are unknowable to the average player.
Also now that I think about it again it could be further optimized, by checking whether or not the different edges and the corner are really necessary or if they will be flat anyway (since the edges only have 2^4 possibilities and 4 of them are flat). And if they aren't just merge them with the face. Also perhaps a seperate rendering algorithm for the edges might be worth it, since they only have 16 configurations.

So, that were my experiences/thoughts/ramblings about Dual Marching Cubes, if I completely missed some point and my alterations aren't necessary: sorry for wasting your time :oops: .
Eldalar
 
Posts: 8
Joined: Tue Aug 20, 2013 12:42 am

Re: Rendering procedural planets.

Postby JRandomHacker » Thu Sep 26, 2013 4:51 am

Shamus Young of Twenty Sided Tale did a blog series on his experience writing a voxel-ish game, including a few posts on marching cubes. It's aimed at a less technical audience, but I think it's a decent look at what comes up when implementing this. Article here
JRandomHacker
 
Posts: 1
Joined: Tue Aug 13, 2013 6:32 pm


Return to Code

Who is online

Users browsing this forum: Google [Bot] and 1 guest

cron