Home | Documentation | Atomic Chat | Github

Atomic Terrain Editor


I’ve started to add a terrain editor to the Atomic editor. You can find the initial draft of the code here:

It’s off to a good start and already usable, but still very basic and rough around the edges. I am not really a C++ developer, so I’ve no doubt made quite a few errors and the performance really needs to be improved. It would be great if someone with more C++ experience could take a look and help me fix it up.


After terraining a little while, I could stand some new camera controls…

  • Teleport move the cam to the terrain cursor, and maybe face down
  • Page move across the terrain in 1/10th or 1/20th steps
  • Up and Over cam faces down or to 45degree angle
  • Zoom move cam closer or further away from current viewing position


Its also worth noting that the mouse wheel in the atomic editor can increase the speed of the camera, which makes moving around a terrain a lot easier.


@darrylryan Awesome work bootstrapping one of the most advanced Atomic modifications to date! This touches a lot of subsystems, great job pushing through… very :camel:!

If anyone else wants to try this out, Atomic is really easy to build from source, just kicked off a Build_AtomicEditor.bat while having some :coffee: :slight_smile: There’s also a scene editor hotkeys article on the wiki

Ok, so as you know, the editor needs better support for extensions. Terrain is core editor functionality, though I think should still be treated like an extension. What does this mean today? Not much, though it will soon-ish :wink:

In the meantime, I would love to get this on master… I am short on bandwidth, though can provide feedback/answers on pointed questions, especially wrt performance.

I did have a bug where in ToonTown when raising terrain it would raise at a different spot than I had selected, like the cursor was here and the terrain raised over there :bug:

Otherwise, looking great, we can talk a bit about how to integrate the UI, I’d like to see it in the terrain component area of inspector, though that can wait until a bit further along.

Thanks for sharing!


I think I’ve fixed that bug with the cursor raising in the wrong place… I’d put in a fix that worked in some cases but broke the rest :smiley:

I think in the long run we really need some sort of new TerrainManager component that will handle adding multiple terrain tiles, assigning them as neighbours and paging them in and out, allowing for huge terrains.
I’ve tried to design the terrain editor so far so that it edits whatever terrain the brush hits, so it should in theory be able to work across seams. although we’ll need to tweak it to deal with the case when the brush radius covers 2 or more terrains at once.


Starting to get useable :camel:


Really cool work and I admire it very much. But are heightmap-based terrains, where you can’t get caves, overhangs and such really worth it when modern systems can handle voxel-based terrains well?


In the last year I have written about a dozen different types of terrain system, including voxel cubes, smooth voxels and isosurfaces.

In then end I’ve come back to heightmap terrain as my option of choice. UE4, Unity and CryEngine 5 all still use heightmap based terrains, despite the fact they have active development teams and voxel terrain technology has been around for many many years.

The reasons? Heightmap terrains:

  • perform pretty well
  • are easy to store (just need 2d data not 3d)
  • easy to LOD
  • easy to load in and out in chunks
  • easy to join together at the seams
  • easy to texture and paint
  • easy to generate collision data and physics
  • easy to use in networked games

When you start using voxel terrains things get a lot more complicated. You can no longer simply use 2d splatmaps to texture the terrain, because the data is 3d, so you need some way to paint the underside of a cliff as well as the top etc. Its also really difficult to generate texture coordinates, so generally people use triplanar texturing, but then you can’t really paint the nice details in the way that you can with a splatmap.

Have you ever seen a voxel terrain that looks as good as a high-end heightmap terrain? Voxelfarm is probably the best voxel terrain out there, and even so I don’t think its terrains look as good as the AAA engines achieve with heightmaps.

Its also a lot more complicated for things like physics, networking and server-side collision detection, because now you have to worry about people being inside of or underneath the terrain as well as on top of it.

Overall though, the main reason is - I don’t think smooth voxels are actually all that fun. We all loved voxels in Minecraft and thought "Wow, what if we had smooth voxel terrains that could be sculpted in games with high-end graphics? That would be so awesome!"
The reality is though, carving spheres out of a smooth terrain to make tunnels just isn’t fun like it is with voxel cubes. You just end up with a mess of worm shaped holes. Caves in real life are complex, jagged, they have sharp overhangs, stalactites and stalagmites. The same with overhangs and cliffs - they aren’t just smooth drops or rounded columns, they have irregular shapes, sharp edges, bumps and details. Doing stuff like that with voxels is really, really hard -and its much better done with good old fashioned meshes and normal maps.


And… we have painting!


Gave the mountain a bit of a paint job to test :smiley:


Last pic for tonight - sleep calls


Really awesome, progress, I am looking forward to trying out the branch a bit later today! :dromedary_camel:


Yes, Blockscape’s “realistic” terrain. Jens Blomquist is a true genius. Everything is voxels there, even trees, bushes and so on. Also, Euclideon’s tech/Atomontage but good luck licensing either of those.

If you will be buying Blockscape to check it out, be advised that realistic terrain is bugged right now (regression) and the best idea is to install older release of Blockscape, which is available as beta 2014 branch (not actual beta, but since you can’t downgrade on Steam…)


As for your arguments,

Numbered for convenience in answering.

1 Not really a concern with modern computers. The reason voxels weren’t popular earlier is because of crap computers we had back then. Modern PCs can handle them very well.
2 Agreed, but with modern drive and RAM sizes storage is no longer a problem.
3 So are voxels if you lod before you turn voxel data into a mesh (decrease voxel resolution with distance from camera so you get big voxels in distance while you get nice pretty voxels close to the player). I believe this is the solution Blockscape is using, but not entirely sure.
4 So are voxels, you just need 3D chunks. Again, Blockscape proves it’s entirely doable.
5 Here I can agree, however as long as you sculpt voxels as one big (infinite, for all intents and purposes) terrain instead of sculpting each chunk separately, seams won’t be really a problem. Same thing with heightmap terrains, really - if you try to sculpt each chunk separately you’ll get seam errors as seen in many amateur Unity games made by the devs who haven’t realize you can just scale the terrain then increase its resolution in the inspector and instead use several terrains arranged in a grid, then try to make them fit together.
6 Sorta agree if we’re talking about most basic marching cubes from some tutorial, but again, there are better approaches.
7 Agreed, but you could also use it as an excuse for not implementing other collision types than a hitbox for 3d models - after all it’s easier to just use hitboxes so why implement other collision types like sphere, or, heaven forbid, precise polygon to polygon collisions? Also the best thing about terrains is that they are not supposed to move. So support for physics other than collision mesh for other objects to interact with is superflous.
8 Sorta agree, but if terrain is immutable (players can’t change it) and not procedurally generated, both sides can just store a copy of it and game proceeds without any terrain data transfer…



Performance is still a concern - even on modern hardware. Lots of people still have low-end rigs, and mobile hardware is still very limited. Even on high-end games, its nice to have a few extra FPS available for eye candy.

Also when I say easy, I mean more from a developer point of view. Sure, good voxel terrains are possible, but they’re much harder to achieve and create all sorts of other problems when developing other bits of the game or engine like physics and networking.

Blockscape does have a nice voxel terrain, but I don’t think its as good as Voxelfarm personally. And I think both look a lot worse than e.g. UE4 or CryEngine’s heightmap terrains.

Anyway - if you want to have a go implementing a good voxel terrain, I am sure there’d be a lot of interest from the community.


I am simply tickled by the progress on this, I love the smell of :camel: in the morning, it smells like victory :slight_smile:


This! I really couldn’t agree more! BTW: congrats on the awesome work @darrylryan.

Performance is almost always a concern in mainstream gamedev, so for a general-purpose engine you surely don’t want to underestimate its importance, especially since Atomic has a more ‘industrial’ approach. I echo that good voxel terrains are possible, and small positive details like stalactites can always be separated objects so you don’t really need that kind of resolution most of the time (you can’t have them in heightmap too), for negatives a decent artist can achieve something decent with that limitation. However, there’s a cost:benefit ratio to consider here. While in theory it’s possible to achieve good results, the question is whether that’s worth the effort, especially at this time. A voxel terrain system is certainly much more prone to all kinds of bugs and will need lots of optimizations, that is, assuming you have something decently looking to begin with, including an editor which is somewhat complex too. Another aggravator is the fact that the best voxel terrains out there aren’t that good really (as you pointed out), and let’s not underestimate the effort that was put into them.

Voxel terrains are the future, I don’t think one would argue against that, and for performance you could always preprocess everything so in the end it’s just a bunch of meshes with special LOD system for seams, but you could as well just use an external editor for that and use ordinary meshes with special logic for the seams. Voxels in my opinion should be more than just the visuals though, they provide an opportunity to increase interactivity, but then again, these days most games don’t have that level of interactivity not even with heightmap, for example, explosions could affect it, even if slightly and not additively (capped), but most games don’t have that, let alone in voxels.

Imho, it feels really cheap when a bush stops a tank and nuking a house doesn’t destroy it (and leaves a crater in its place), we got used to that, so as gamers that’s somewhat ‘normal’ and expected, but these days with efficient navmesh generation and dynamic obstacles and whatnot, at least on PCs we could go with way more interactivity than that. People from the future will watch videos of the classic games from our time and go “WTF” when stuff like that happens :stuck_out_tongue:.


Working on a terrain shader


Foliage system and triplanar array textures on the terrain starting to take shape


New terrain cursor