Terrain system using Blender models

Hey guys. New to the forum, but I’ve been messing around with JME3 for a while. With the TerrainGrid being phased out in the future, I decided to mess around with the idea of creating a new Terrain system, that would allow users to modify their terrain however they want. The easiest way seemed to be actually modelling or importing a heightmap into Blender. This way, you can design your own roads on the terrain, or put houses onto the terrain, etc.

I played around with it for an hour or so and got a simple prototype up and running. It works similarly to the TerrainGrid as it has a (very) simple paging system that destroys grids that are unused and loads in new ones on the fly. This new system would also allow users to pick a distance at which the grids would disappear.

So, I just wanted to throw this idea out there. I just want to know if this is an okay idea, or if it’s nonsensical. :smile:

A simple prototype using just one tile, repeated over and over

TerrainGrid is deprecated because it isn’t versatile enough, but there are ways of creating one yourself, such as this one I made myself. I should note, I’ve used the basic principle of my system several times and you can get rid of those thread-safe collections to speed things up a bit, amongst other minor changes for extra speed.

The basic principle is to use either an image-based heightmap (greyscale, white = 1, black = 0, multiplied by a world height, for example 256) or a perlin-noise-based world.

Tiles are generated in a threadpool and added to the scene one by one (one each frame) when they have been generated to avoid adding too many things to the scene at once and causing stutter.

The only problem with this system is float accuracy in the far reaches of the world, notably visible in early versions of minecraft. The best way around it is to move the world instead of the player if you require a truly endless terrain.

Having said all of that, I have made it my personal goal to implement a better terrain system, and will be doing so at some point in some way or another, including making a better terrain editor for the SDK.

Here is a video of it in action:

Nice! Will your terrain editor include support for road systems and the like?

The first port of call is the ability to modify multiple terrainquads. Currently you can only edit one. Even if you add two, you can only edit the first.

This is a prototype I made over a year ago now:

Secondly, via a plugin (not a built-in feature) i’ll create something like this (again, a prototype made near a year ago) - basically adding a simple object to the scene and tada - instant editable terrain:

Awesome. There should also be some sort of vegetation system! I’ve got a simple, but working paging system for grass, trees etc-I’m thinking of integrating it into the terrain system I’m building.

Well… the principle I need to stick to is to not be too… “this is the way you should do it”, and instead provide the abstract tools for the user to create their own implementation of their vision. Vegetation paging is one of those things. Personally in my opinion you should attach the vegetation to the terrain quad itself, so when the terrainquad is removed, the children are removed too. It makes it clean and simple, but there are situations when you might not want that. By forcing a structure like that upon somebody, you’re forcing your way of thinking upon them. That’s not something JME nor I want to do… So… maybe I’ll put an example of how I would go about doing it, but it would only be that, an example, not a forced route.

1 Like

That is very true, I haven’t thought of it like that. Good point.

Had some more time today to work on my terrain engine - Got it working pretty well.
You can specify a distance at which chunks should be removed from the engine. It uses a system which keeps track of all of the chunks and their respective states: Loaded, Unloading, or Unloaded. When a chunk is out of the view bounds, it is set to unloaded and a timer begins until that chunk is set to unloaded, and removed from the node.

Chunks are also loaded at runtime. When a chunk is set changed from unloaded to loaded, it is loaded from the asset folder again.

I put together a Blender script which chops up the terrain into chunks, names them their correct coordinates, and exports each one into separate OBJ files.

Very large terrain using HeightmapBasedTerrain.j3md:

The terrain in Blender, right after running my script:

1 Like

I know it has been a little while since your last presence but… could you share the blender script to chop the terrain and rename it like that?

You have these videos as private. Cannot see them.