Pioneer dev forum

This might be a little rambling but it's been bugging me.

Our terrain is ... rubbish, by modern standards.

Now it's quite an achievement in many ways, and this isn't a dig at the technical our artistic competancies of anyone who has worked on it (especially since I've done a lot on it!) but it just doesn't measure up against what we all know is actually possible.

I've tried several times now to come up with better ways of generating, texturing, rendering our terrain but everytime it's simply been too much because when taken in total it is a Herculean task to do alone.

So lets brain-dump:
Height generation
Problems start with it outputting values in ridiculously small ranges, this why we need to use double precision for it not because float wouldn't be enough.

I think that this is done because we generate the spherical meshes patches in the range 0.0 to 1.0, then we add on the terrain heights. Those heights are typically very small compared to the radius of the planet itself, take the Earth with a radius of 6371 Km which has a highest point above sea level of 8.8km. All of the surface of the Earths geography therefore has to fit into the range 0.0 to 0.00138125. Which makes having smooth landscape tricky unless you use the extra precision of double data types. It's also a further problem when you consider that most of that range will not actually be used, in fact the lower half of that range will account for something like 90% of the landscape on an earth like planet due to weathering / erosion. only a few peaks and ranges reach into the upper half.

This leads to the problem with my first attempt to fix this - texturing the terrain based on altitude and slope.
If the height was in a normalised range between 0.0 and 1.0 then we could easily calculate the slope/gradient of the terrain from it's normal and use these two values as a lookup into a texture atlas to give us varied terrain textures by height and the steepness of the terrain at that height. This is basically how the terrain in Infinity & Outerra works with added noise to break up uniformity, and we can all agree that it produces good results.
One way to get the normalised range this would be to multiply the terrain heights by the radius of the planet, which brings us to the next problem: our terrain noise algorithms don't produce noise within a reliable range, so when the values are multiplied up they can often be in 0.0 to 3.0, or 0.05 to 2.5 or anything in between. These values are still small but they're not normalised or predictable, worse still, turning the existing "Planet Texturing" on/off or altering the current noise values changes the ranges you might get out of the height generation making it unreliable - this is why if you change the terrain setting whilst on a landing pad you sometimes end up with buildings floating in the air or completely buried underground.

In the long run this is going to need completely rewriting to produce normalised terrain heights. It is the only option as far as I can tell.

So what I'd like us to start discussing is how to rewrite it.

...what I've started to do will come in a second post.

before I dive into what I've been doing I should give us some goals really, at least as far as I see them.

These are not fixed but a general goals and things that it seems make sense - challenge me on any of them if there reasoning isn't clear:

• Normalised height ranges from 0.0 to 1.0, alternatively from -1.0 to 1.0 either should allow for having DEEP oceans.
• Terrain heightmaps as textures (for passing into water shaders, and to allow for optional GPU generation).
• Texture mapped terrain, using a texture atlas, splatting or some other technique.
• Instanced detail on terrain - grass, trees, rocks, objects of other kinds (crashed ships, buildings, weird shit).
• improved terrain collision using the mesh rather than querying the noise system.
• Realtime water for Ocean and shorelines (this is relatively easy if we have normalised terrain heightmaps).
• Cloud atlas generation for whole planet, with instanced volume clouds when close.

I won't try to say too much because despite having dabbled around the edges for a couple of years, I'm still pretty much a beginner when it comes to terrain generation in general and Pioneer's implementation specifically.

I'll take your word for it that normalising heights is the best approach. It sounds right, and I have no counterargument, so I'll take it.

Our noise functions should be made consistent. There should be hardcoded rules that they should be in a specified range. I'd much prefer tripping an assert because your function did something stupid rather than either hitting a floating point exception and/or infinite loop down the track because some numerical error bubbled into a place where it wasn't wanted.

Whatever we do though, I want us to consider how terrain for cities is done. We've discussed this a number of times, so there's probably not much point going into it again. I have a vague recollection that we liked the idea of generating a "local" heightmap that would be used as the base of the city, generated along with the city layout to make it all consistent and allow clever things like roads and stuff because we no longer have to work around whatever retarded terrain we get stuck with. It sounds like your terrain texture lookup approach would fit well with that. Does it?

The other thing I want to make sure we do is get the code structure right. One of the difficulties with the current system is just how difficult it is to hack on. I'll volunteer to help with that because its one of my peeves.

FluffyFreak wrote:before I dive into what I've been doing I should give us some goals really, at least as far as I see them.

These all look like great things. I'm going to suggest not doing them all at once. Lets make a start that will allow for these things in the future but gives us something now. I don't mind ripping out the current generator and going with dumb spheres and rebuilding from there. I very much do mind a year-long project that has to be merged at the end. We've got enough of those!

Lets drop the idea that we have to use Noise to generate all aspects of our terrain.
Currently we just mix lots of noise in lots of Noise-y ways to produce every bit of terrain the game. We don't have to use Perlin/Simplex Noise in this raw way though.

Could we instead generate a series of high-level inputs into a planet generating system? Then build each planet in a series of refinements?
Never written this down before so I hope it makes sense.
In stage 1 we'd take what we know about a planet, it's distance from the sun, if it has an atmosphere, volatiles and things like that. We could decide to split the world into vector information, perhaps continents based on Voronoi patterns, we could move bits nearer and further from the core to get land and ocean plates, give them directions and speed and form coarse mountains, all done using some Noise to give us randomness. Put volcanoes along the subduction edges and other instances details.
Finally render all of it out to a planetary heightmap for the whole world, a bit like the Earth/Moon/Mars heightmaps but NOT saved to disk just in memory. At this stage we'd convert the information we'd created in vector format into the heightmap by rendering it to a texture with some noise systems but also by baking in textures of volcanoe heights, river valleys / deltas, mountains, ranges and other such things meaning that some of these could be artist driven. Change the heightmap texture for a mountain and it would change every single world that used it. Optionally apply some erosion for atmospheric worlds and we'd be done with this stage.

In stage 2 we process that coarse level planetary heightmap to generate water bodies (lakes etc), a civilisation map (like the lighting maps for Earth showing where cities/towns/roads are illuminated at night), weather/cloud maps, precipitation and eventually a biome map showing the different environments of the world i.e; desert/arctic/jungle/etc.

Now I can see us leaving it at stage 2 for the pre-generated data for each world within a given star system - we'd jump into a system and then generate this on demand.
Later stages would take all of this lot as inputs and follow some of the more typical noise methods we already use.

Stage 3 is patch generation - a patch being a little chunk of a planets landscape. We would sample the high level heightmap to get the "base" height, then we would choose from a blend of Noise methods based on what the Biome is and blend between them to get our final height. Next we texture it based on the height + slope from a texture atlas chosen based on the local Biome.

Stage 4 is instanced details - the icing on the cake that gives it a sense of scale a detail. These are things that sit on the terrain and give us familiar things to judge the scale of a world by so it includes grass, trees and other vegetation. Others might be rocks, boulders, protruding objects from the ground like ruins or crashed ships. All of this instancing would be based on the maps we'd generated so far. High level selection might be of buildings to instance where the civilisation density map (nighttime lighting from space in stage 2) is high enough. Rocks in the deep desert, but no trees or grass. Likewise for arctic conditions.

robn wrote:I very much do mind a year-long project that has to be merged at the end. We've got enough of those!

I agree, I think that's why I'm dumping this here now, because it's too much work to do alone or in one big lump! :)

robn wrote:I'm still pretty much a beginner when it comes to terrain generation in general and Pioneer's implementation specifically.

As are we all :) if we pull this off though we would be perfectly right in calling ourselves 'pro'!

I'm trying steer away from saying things like: "It should all be done on the GPU!", or from stating that what I've written is the "best way".
Because I think that after looking at it I've gotten too many implicit assumptions that I'm not fully aware of.

So what I've listed is just, what I've been thinking of, nothing more.
As much as anything else I'd like some opinions about what the best way to tackle everything is, what order, what it might break, where it's lacking, whether stuff is good at all!

This is one where I'd like input about the maths relating to the resizing and repositioning of the camera relative to the GeoSphere. If we're going to be having terrain generation normalised to a range (be it 0.0:1.0 or -1.0:1.0) then We'll have to rescale it either when the patch is uploaded to GPU or we'll have to do it on the GPU should we try to do something like modifying the position in the vertex shader.

If you give me a list of some objects that will be needed for the instancing, then I can start modeling them early on, so when you guys reach to that state, there will be models to grab. :) Same for textures if needed.

Not sure what to ask for yet :)
I'm thinking it'll be all manner of rocks, and rocky outcrops, rock tables, clumps / clusters of pebbles, stones and things underfoot.
Then foliage, lots of kinds of ferns, grasses, small plants, leaves.

I'd hold of on doing anything yet though until we've discussed it a whole lot more ;)

How much focus on Planetary environments do we actually need in a Space Sim? What is the "Baseline Environment" for the game? Earthlike worlds? Martian Worlds? Tiny Moonlets? Asteroids? Orbital Stations? Jovian Systems? Planetary Ring Systems?
Just throwing out a mess of ideas :)
Seriously, though... from a gameplay standpoint it might be more productive to get OTHER types of celestial bodies procedurally generated and leave Earthlike Worlds as places you never really visit much anymore, now that you have a Starship...