I’ve been working on a procedural planet renderer for quite some time. So far the project includes:
-Space-to-ground seamless transitions
-Dynamic level-of-detail
-GPU real-time generated heightmaps
-GPU generated normal maps and color maps
-GPU atmospheric scattering (based on Sean O’Neil’s shaders but in the future I would like to implement Eric Brunetons multiple scattering)
I don’t have much to provide as of yet but code and a video will soon follow. In the meantime, here is an image of the work so far:
As one an probably tell there are some big glitches present, namely the misalignment of cube-faces.
The main purpose I had for making this post is to potentially help anyone else that is doing something similar as this type of help would have been extremely useful for me starting out.
Feel free to comment or ask questions.
If the heightmap is GPU-generated: Is there a way for the program to get at it?
Without that, the illusion will break as soon as the player lands and walks around on the surface - it might still LOOK jagged, but the player would never encounter an obstacle.
Unless procedural generation exists twice, once as Java and once as shader.
Though that would be hard to do because round-off errors would be different.
@toolforger said:
If the heightmap is GPU-generated: Is there a way for the program to get at it?
Without that, the illusion will break as soon as the player lands and walks around on the surface - it might still LOOK jagged, but the player would never encounter an obstacle.
Unless procedural generation exists twice, once as Java and once as shader.
Though that would be hard to do because round-off errors would be different.
That’s a good question. Right now I am not doing any collision detection but I do need the height map offset for the center of each quad. I read this data back by calling renderer.readFrameBuffer(FBO, byte buffer);. If I ever do collision detection I would render a 17x17 height map in addition to the 256x256 one I use for lighting and coloring.
Yeah, if we are talking planet scales then you’d only see “characters” walking on the ground from a close distance, from that point on you can use the same algorithm for the creation of the actual physics collision shape / terrain and probably add some foliage etc. on the java side. This is looking good, if you make it modular enough so people can use it for their ideas I bet you get a lot of additions and contributions
@okelly4408 said:
I do need the height map offset for the center of each quad. I read this data back by calling renderer.readFrameBuffer(FBO, byte buffer);
Ah okay, that’s just what’s needed.
Are the sources available somewhere? Github or Bitbucket would be best, not so much for git/mercurial but because you can discuss individual lines of code there.
@toolforger said:
Ah okay, that's just what's needed.
Are the sources available somewhere? Github or Bitbucket would be best, not so much for git/mercurial but because you can discuss individual lines of code there.
@madjack said:
I'd be interested in seeing the planetary shaders of this, if they're available.
I’ll be releasing the code on github once I correct two small bugs and clean it up a bit.
Hello!
I have not forgotten about this.
Well a lot has been added and I guess the best way to sum it up is with horrible eye candy:
So there you are. I have continents using simple fbm which I am pleased with. The “biomes” are created in a similar fashion yet “moisture” of the area and the latitude factor into the selection. Currently I have mountains (around 30% of the land) and plain lands. I am pleased with the mountains yet the plain lands need some work…I might have to try some derivative noise with those but interpolation between smooth land and mountain land then adding some ridged turbulence gives some ok results.
I recorded attempted to record a video of it. The video was recorded before I added some intermediate biomes to blend things together and it only shows a flight through mountainous land:
I still don’t feel comfortable releasing the code as it is…It is very messy with huge blocks commented out and cryptic notes that I wrote for myself. Plus there are TONS of bugs to be hammered out…namely a memory leak dealing with heightmaps that is extremely annoying.
Eyecandy it may be, good-looking it is anyway
One thing I noticed is that the landscape is littered with ridges that criss-cross it at 60 degrees.
One less obvious way to get that kind of behaviour is using fractal generation formulae for square lattices in a triangular lattice, they need to be adapted. Of course, it could be anything, particularly if you still have tons of bugs to squash.
Actually an interestig feature would be to force set one tile of the terrain. (Idealiy via an interface so every terrain implementation could be used for this)
That way I can make important parts of the planet eg cities myself, and let the void between them be filled by random stuff. More or less only the heightmap must be matched at the seams, the rest of a fitting art style is of course my problem then.
@kwando said:
This is beautiful work so far! =) The number on issue that destroys the illusion is the seams between the tiles, they are really obvious =/
Thanks! And yea those need to be fixed. I think most of that will go away once I add skirts on every quad.
@Empire Phoenix said:
Actually an interestig feature would be to force set one tile of the terrain. (Idealiy via an interface so every terrain implementation could be used for this)
That way I can make important parts of the planet eg cities myself, and let the void between them be filled by random stuff. More or less only the heightmap must be matched at the seams, the rest of a fitting art style is of course my problem then.
That actually may be fairly simple. One can define a general area of the planet where such a city would be located and at that area city lights or something could modulate the color map. Then as one moves the region can be refined into individual quads where a model could be placed.
Hello,
First off you can download the .jar file for the program here if you are so inclined. It might not run that well on your computer as you need a rather beefy graphics card (where most calculations are performed). When you get into the atmosphere I suggest pressing “L” which will scale your speed to a level where everything is not breaking. “M” toggles wireframe mode on and off, “1” decreases speed and “4” increases speed (press and hold), “O” moves the light source direction to the left while “K” moves it to the right, “R” generates a new random planet (I suggest being far away from the planet if you are going to press this), F5 clears text from the screen, “0” increases LOD sensitivity (increases performance), “9” decreases LOD sensitivity (increases visual quality).
Since my last post I have:
>Tweaked atmospheric scattering to be much more realistic
>Improved HDR greatly with a new function (this combined with the above change has made the atmosphere a much nicer feature)
>Added desert biome specific terrain (canyon, mesas, shark peaks etc)
>Implemented LOD seam correction using quad-skirts
>Played a little around with specular reflection
>Totally rewrote the mountain algorithm to create much more interesting terrain
>implemented hardware/geometry instancing
Anyway here are some photos to demonstrate the progress:
(*Note: Some of these were taken before quad-skirts or the new HDR function was implemented)
Desert Biome Terrain (these terrain features are sort of rare):
Improved Mountains:
(this one appears to be on the edge of a desert biome)
Improved Scattering & HDR:
Things to Come:
>Multithreading
>More biome specific terrain
>Realistic Water
>Better specular reflection on water
>Tangent space normal maps converted to object space
