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?
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.
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)
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
@Vanamerax 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.
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.
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.
