What would you like to see from a procedural terrain editor?

I'm currently making a voxel engine that I'm planning on releasing to the asset store. The core functionality is done, but I want to present a nice way to define the generation rules to the end user, that is, generating a heightmap + vegetation + other environment objects with the help of simple rules, noise generators and basic function design.

Now my question is, what would you like to see for such a package in terms of workflow and configuration options? Please note that terrain can be procedurally generated at runtime, possibly infinitely in all directions. This means that hand made adjustments in the form of digging/raising/carving in the terrain with brushes (like in the default terrain) is not viable. I could add that feature too for constrained terrain sizes, but lets not talk about that here.

I'm already making a node editor system to generate heightmaps (with previews) for the basic terrain height, a bit similar to how shaderforge works. More importantly, I would like to know how you would want to arrange generation of various material types in the terrain: Do you want it to generate based on slopes and/or biomes, or would you like a layered-based approach (layer the terrain in dirt-clay-rock etc) or do you have any better ideas?

To add to it, there will also be a system to allow procedural object/vegetation placement across the terrain. How would you like to set up rules for that? Specify temperatures and rainfall parameters for every plant? Define custom parameters which each use their own set of noise generators? Better ideas? How would you like to combine each of these generation layers?

Thanks!

 

how about smooth terrain.. like 7 days to die

lol itd be nice if could like make a house like in minecraft and then save it as a prefab kinda thing...

(lol i guess im not your preferred answerer.. since i know how to do all the things youre talking about, but not the 2 things above)

 

I should add that it indeed does use a smooth surface instead of the popular minecraft clone. However, smooth or cubic isnt that relevant here for my question.

I guess Im pretty much in the same boat as you, trying to bring all the features voxels allow to the maybe more artistic end users without bringing all the technical details with it

 

Of course the ability to paint height and depth with various brushes. A hook brush kinda like ZBrush's SnakeHook brush to pull the terrain up and loop it over for cliff hangs. Pull two parts up and when they join they automatically decide that you are making a portal in the terrain. The ability to keep pulling and twisting and yanking things into place and then brush on noises and cracks, rock and stone sections. A hollowing brush that allows an xray view through to see what you are doing in the cave you hollowed out without alot of camera tomfoolery. One touch bolder extrusion which can make small boulder or large mountains that can then be refined with smaller detail brushes. The ability to attach textures to the modeling brushes so that is you do one type of noise you are making, for example, mineralized encrustation and another that would make dirt and sparse grass. Point, drag in any direction and let go and it stays put. Autojoining of pulled out terrains. I got more if you like these ideas.

 

Thanks for you reply!

As mentioned, the manual brushes will probably one of the last features I will add (together with baking terrain meshes etc), as the engine is focussed on procedural, infinite generation at runtime. Thus, apart from configurations in the generators, the engine is not 'meant to be' adjusted manually in the form of brushes.

Any more ideas for a nice interface to configure procedural terrain generation?

 

As for procedural. Perhaps provide a palette of tools where you can drop icons on the terrain for things like caves and terrain portal type features, cliffs with overhangs and the like. They store location and configuration and apply to the terrain at mesh generation time. Perhaps you can provide brushes but they store data to the procedural generator for use when that area is traversed. It must be customizable. I am leading a big project soon that will need underwater terrain and endless world terrain based on real world DEM data. but I must have control of the features.

 

Ease of use & efficiency. Focus on features second. If people CAN do something, they're probably going to. If you provide a solution that is not only faster but also likely to be better (and is extendable) than what they're going to come up with, they're going to choose your solution.

 

It would be nice if I could get such a feature to work properly, but I doubt that it is feasably without cluttering the codebase with special cases everywhere. May look into that later though.

As for real world data, a worldcomposer integration might be a possibility for the future.

I agree, I am already maintaining a modular system for programmers, where you can just implement some interfaces and everything should integrate nicely (including inspector popups that automatically show the new class options)

 

Floating origin support. Runtime LOD. Collider streaming (if possible). Simple road/path generation.

 

That's asking a bit much That would be the best thing ever, though. I think that's an engine limitation - everyone needs to re-origin the world by moving everything relative to the character and learn to do chunking with massive terrain currently. It'd be nice to be able to move and find things relative to some transform reference.

 

Although I do agree that the floating point problem is quite a limitation of the engine, I dont think it will be a problem for the average user. I noticed that artifacts started to show up behind the 100k mark, which I doubt a lot of people are going to reach on foot (I had travelled 10k in about 10 minutes with a noclip flyer at about 20 m/s). Reaching the 100k would take almost 2 hours with noclip, which would take considerably more time when on foot, having to climb all obstacles on the way.

Lastly, I think resetting object's positions is hard without knowing the specifications of the game being made in the end. Moving everything to the origin is therefore more of a responsibility for the game's programmers than my plugin.

Still, it would be nice to support it if I ever get to it.

As for the rest, the generation of a heightmap will allow for large viewdistances for height based far terrain (within a specified radius around the player, the terrain consists of voxels that are loaded into memory. Beyond that is the heightmap far terrain). I also hope to add in detail switching for scenery objects, vegetation etc at some point.

Mesh colliders are being generated as well

Spline road/path creation would be a great addition I'd like to add. I'm not sure yet how I want to implement endless road generation over an infinite chunked terrain though. If I can figure out something for that, I will also add support for village generation etc

 

@wasstraat65 that's kind of what I was getting at. What I tend to do is parent everything to a "worldmove" transform, move that to 0 so everything is moved relative to everything else, then load or unload chunks. It's too specific to the project requirements, I'm not sure if there's anything you can do other than make sure your system will work well with anything people are going to implement regarding world re-origins.

I like the road idea you have, but maybe that could be abstracted a little. There's a lot of things that could be laid out the way you're talking about roads.

 

it can be exported to low poly
has good shader with low draw call
we can model caves inside

 

Water is something I've noticed almost all of the engines are missing (except TerrainEngine that I know of). I know it's not that much to just create some meshes so where the terrain is less than sea level, but all that makes is just lakes / ponds and other still bodies.

 

Exactly. As for the roads, I will still have to take a look at the way it is (if ever) going to be implemented, as this can be quite a bit more complex than what it looks like at first.

Agreed. I would love to implement a decent water simulation, as this would indeed be a feature that would seperate my engine from the rest. I hope I can find a way to do this in a modular way, without losing too much performance.

 

You could do high performance voxels, maybe? Discovering that holy grail would let you raise the price a couple hundred, haha.

 

Im sure about that lol

 

I may not be understanding this but how will cliff overhangs and caves be implemented and how do you control the terrain surface? I did some research and attempted a voxel terrain back in 2010 but some of the math got me stuck. I did understand the theory.

 

Well that is basicly what I'm asking your guys' opinion for. How would you like to do that interface-wise? How would you want to control all the parameters and generation? I myself have though about a node editor to define terrainheights with noise nodes, arithmetic nodes etc. But other than that, I'm not sure how to work from that.

 

I do not see why the math and noise nodes cannot be attached to brushes and the coordinates of the brush contacts used to implement the placing of those nodes in your algorithms. Same with terrain object such as cliff overhangs and terrain portals and caves. Attach them to tools that devs and other apps that do terrains have a standard implementations. Terrains are generally "painted" on and the heavy lifting done by the algorithms called up when they are selected and put to use. Create a brush class for terrain height maps that allow the use of greyscale patterns to be attached and these can be sized by the user and the scaling instructions set by sliders and those numbers and greyscale data incorporated in your voxels classes to manipulate heights. Objects should be on an Objects palette with similar prototypes to the available abilities of your voxels class. Caves and overhangs being the more usable and wanted by developers. So a Heightmaps Palette of brushes, an Objects Palette with choices based on the current implementations of any and all kinds of classes of object the engine is capable of at that point. Then you can add to the palettes as functionality is expanded in updated versions. Perhaps for things like a cave you pinpoint a location and a Cave Editor comes up that you can pull and stretch and carve and make stalagmites and stalactites etc. That is then just mathematical data and the location becomes a node for that data at generation time. A manipulable Cliff Editor using the same paradigm sounds to me like a great idea.

 

Well the thing with the brushes is, normally you would have a density function so that you can get a height value for an arbitrary x,z position. If you were to adjust those heights manually with brushes like you suggested, you would have to store those manual adjustments somewhere. This would mean that you have to actually generate chunkdata and store them to the disk. Another problem this gives, is that you lose the ability to create an unlimited amount of level variations based on a single seed (like how minecraft does this), because the adjustments were only ever meant for one single case.

The idea of my engine is that you can generate unlimited combinations, levels in infinite directions, without the need of human intervention (having to paint manually on the terrain). This feature could be added later if Im going to support baked terrain (aka generate the voxels in the editor, save them to meshes for the runtime) as more of an enhanched version of the builtin unity terrain. However, this is not what I'm aiming for at the moment, but I may add to it later on.

 

Well if it just arbitrarily generates a terrain surface then how do I place a building needing a flat footprint or a set of terraces on it? I don;t get what the use of this is beyond a MineCraft thing at higher resolution.

 

Well thats exactly the thing, you are going to define HOW it generates the terrain. It is a runtime procedural generator which you get to control the parameters over. The fact that it is voxels doesnt mean it has to relate to minecraft in any way. When people hear 'voxels' they immediatly say 'minecraft' nowadays, for some reason..

 

The node editor sounds like it should be enough, right?

Just build a Generator object that contains multiple Graphs, where each Graph is a Layer/Pass that modifies the terrain or places objects. So the base layer would be a graph that creates the initial terrain shape, the second layer uses the resulting terrain data to make decisions about adding caves and cliffs and other geographic features, and a third layer uses that data to populate the terrain with vegetation and gameplay prefabs.

Allow the user to add as many layers as they want, and allow variables (int, float, bool, UnityEngine.Object, and possibly string) to be shared between layers.

So rules like temperature and humidity would be variables in the graph that the first layer might influence (the temp at position xyz is t), and the next layer might use to place plants (plant p generates at xyz if t > 30 && t < 60) or whatever.

This also leaves materials up to the user, because the user can say "I will make this entire terrain out of stone" or "I will first make a stone base layer, top it with dirt, then add pockets of iron and copper." It can be as simple or complex as the user wants.

 

Yes, this is what I needed. Thank you! You are thinking in the right direction. Are you suggesting a bit of a similarity to how mecanim's layers work? Anyway, I will also add the ability to acces the 'slope' and 'curvature' maps (basicly first and second deritive) of the heightmap, which would mean change in temperature or moisture at a specific coordinate for the respective maps. Allowing the user to define their own maps (maybe you want a 'magic activity' map for your purpose?) will add a lot of flexibility.

Thanks for your response!

 

Yeah, basically. I look forward to checking it out!

 

I will probably open up a WIP thread when my exam weeks are over, so stay tuned!

 

what would be very nice, although I admit difficult, is the option to generate a populated landscape, so it has tree's and water and all that nice stuff

 

Yeah I agree. I got vegetation (trees, bushes grass etc.), general object placement and water generation on the roadmap. The first two are a must for me, but the last one will definetly be harder in an interactive way, so I will have to see if I can get that right

 

Yeh water is always difficult. Best of luck to you man, this sounds fantastic!

Oh, and something else I thought of, that could be relatively easy. If you could have premade presets, so for example, you have a single button which generates a desert based on certain values in which deserts usually are.

 

Thanks!

Sounds like a great idea, will add it to the list I'm also planning on adding some example graphs/configurations/scenes so people can clearly see what can be done and how. Will take some time to get right though, especially when combining with my study.