• 3D

  • Creating terrain in Blender

I'm looking into open world 3D games and was planning on making large terrains in blender but was unsure whether importing large terrains into Godot would crash the game engine as I haven't used the engine yet. Would appreciate some advice before i start.

Define "large terrain". You'll probably want to divide your terrain mesh into chunks. Or might even want to bake them into height and then make a generator in godot that generates the terrain tile from the heightmap.

@Megalomaniak said: Define "large terrain". You'll probably want to divide your terrain mesh into chunks. Or might even want to bake them into height and then make a generator in godot that generates the terrain tile from the heightmap.

Well I was hoping to find out what the biggest chunk of terrain is I can import at a time so I can work out how many chunks I would have to break a map down to. I take it you mean import small parts at a time and place them together? Im not sure how large I could make the playable area with Godot. I just saw a video of someone making a terrain with blender for Godot but I couldn't tell how big it actually was.

@Kalex07 said:

@Megalomaniak said: Define "large terrain". You'll probably want to divide your terrain mesh into chunks. Or might even want to bake them into height and then make a generator in godot that generates the terrain tile from the heightmap.

Well I was hoping to find out what the biggest chunk of terrain is I can import at a time so I can work out how many chunks I would have to break a map down to. I take it you mean import small parts at a time and place them together? Im not sure how large I could make the playable area with Godot. I just saw a video of someone making a terrain with blender for Godot but I couldn't tell how big it actually was.

I'll look up making height maps for Godot but I have no idea how to do it at the moment.

Well, both can work. It's probably easier to start with imported meshes. For the size there's 2 things the word size could mean. Scale, and mesh resolution(vertex/poly count).

The poly count will be dependent more on the minimum hardware requirement you are targeting/requiring players have.

For the map/world scale it's floating point precision that will come into play as the limit. Off the top of my head, about 16 km squared scene/map scale might be doable, but that's the extreme end of it.

@Megalomaniak said: Well, both can work. It's probably easier to start with imported meshes. For the size there's 2 things the word size could mean. Scale, and mesh resolution(vertex/poly count).

The poly count will be dependent more on the minimum hardware requirement you are targeting/requiring players have.

For the map/world scale it's floating point precision that will come into play as the limit. Off the top of my head, about 16 km squared scene/map scale might be doable, but that's the extreme end of it.

So a bit bigger than fallout 4s map? I don't want people to have to have rediculous pcs. I see big games like fallout 76 running on console's and assume something about smaller will run ok.

Lets say, about fallout 4s map, because you don't actually want to reach the edges of the limit or wonky things can start happening.

The size of a mesh doesn't actually matter unless you get float precision errors, this just means some vertices far from world center might not be in exactly the right place. The size doesn't matter, it's just the detail of the mesh that will cost more. In blender, you can see the number of triangles in the top right corner(or bottom right if you're using the latest version), this number will affect performance.

However, a large map can slow your game down, just because it means much more tris than a small map. I don't know if you've heard of this, but open world games use a system called level of detail(LOD). This just means using lower poly meshes as that part of the terrain gets farther from the camera. You can do this if you have your terrain mesh in multiple square "chunks", then duplicate the files, decimate the mesh(for lower detail), and when the camera gets beyond a certain distance away from a chunk, switch to a lower LOD.

You can make your life a little easier if you use a heightmap, there's a good plugin for that, but it's had a lot of collision problems before. This give more details: https://www.reddit.com/r/godot/comments/elwxg9/a_simple_comparison_between_zylanns_terrain/

If you don't use zylann's plugin, you can use meshes with a splatmap shader for texturing.

Edit: I'm sure there's ways you can get around floating point precision errors, I've heard of people moving everything so that the player stays at/near world center.

@Dschoonmaker said: The size of a mesh doesn't actually matter unless you get float precision errors, this just means some vertices far from world center might not be in exactly the right place.

While true it is not the complete story, the precision of physics calculation would also be affected, the precision in motion of animation, many things that can be affected by it.

I hadn't thought about physics, but in this case it would probably just be physics & rendering affected by it.

I'm planing on using the Decimate to lower the polys on the base terrain then smoothing it out. Then I'll do what you both said and split the map into sections and add LOD to Decimate the LOD versions as well as the base model. I'm wondering if I could use the base decimated model as a mold to sculp a separate plane as sculpting seems to have less poly's. then delete the higher poly original? Also would scaling my characters, camera view and objects down in size like ants give the illusion of the map being bigger creating more playable area?

Sculpting doesn't inherently have and more or less geometry, it may or it may not. Whether you use it just depends on how you want to make your terrain. As for scaling objects down, you don't want to do this, just make your terrain mesh big. That won't cause any problems, but scaling things down will screw up rendering, physics, and probably cause more floating point precision errors. It's standard to make 1 unit = 1 meter.

Ok so just keep adding small sections at a time? Is there anyway of finding out the specs of pc/laptop needed to run the game as I make it? Or would I need a finished product to run some sort of test?

The scaling issues can be avoiding by moving all the other nodes in relation to the player while sifting the player over closer to the world origin again. Alas there is no easy, pre-made solution for this in godot so you'll likely have to create your own.

If you are looking to develop a game that large, which unless you are part of a huge team with a lot of resources I generally wouldn't recommend anyways. Exception being a more procedural game such as minecraft or a game initially unpopulated where you expect the players to fill it in themselves.

@Megalomaniak said: The scaling issues can be avoiding by moving all the other nodes in relation to the player while sifting the player over closer to the world origin again. Alas there is no easy, pre-made solution for this in godot so you'll likely have to create your own.

If you are looking to develop a game that large, which unless you are part of a huge team with a lot of resources I generally wouldn't recommend anyways. Exception being a more procedural game such as minecraft or a game initially unpopulated where you expect the players to fill it in themselves.

By scaling, I ment making my characters and objects like walls and buildings smaller when I make them in blender before I add them into Godot making say 1 meter in Godot seem like 4 meters for example. I was aiming to make a survival crafting game where you can build a base with a mission system possibly added in.

"By scaling, I ment making my characters and objects like walls and buildings smaller when I make them in blender " but keeping the terrain mesh normal size*

Yes, I understood that, basically it emulates shifting the decimal point: instead of the world edge being at say 999.9999 it would be 9999.999 a mm being 1/1000 m it would be fine but as @Dschoonmaker said, physics engine wouldn't be taking that into account and the depth pass in rendering(though certain camera settings might help with the latter) would be affected and so on and so forth.

Instead you'll probably want to look into and make use of a shifting world. Basically you are already looking to dice the world up into chunks, create a node derived from Position3D or Spatial and give it a script that manages loading chunks as instanced scenes that are parented to it and shifting them around appropriately when player is getting too far away from the world center.

I'm guessing the shifting world wouldn't work if it was multiplayer. So making for example a remote controlled recon drone and switching the players camera to the drone while controlling the drone wouldn't be as simple as I thought then?

You shift the world in relation to whatever is the active camera essentially. If you need you can implement some extra logic to track the player position in relation to the world as it would be if it wasn't shifting, if you will.

I'm sure there's a way to make this work for multiplayer too, but I'm inclined to assume it would be a bit more complex for it, sure. On that note, each game client would be shifting things relative to the respective player so in that sense it would probably be no different, actually. Unless your talking split-screen on the same system.

And your server client, depending on how you program it, might not need to deal with any world shifting at all.

Also note that when I say shift the world, I actually mean you move everything, player too, but if the player is moving one way and everything else gets moved the opposite way, you have to be careful to not introduce issues such as the player suddenly seemingly moving too fast or instead stuttering or such.

Easiest might be to have things to interact with in your world while player is essentially not moving, picking something up, opening a door, etc. A good moment to shift then. Or if it's a racing game, have a pit-stop of some kind, a gas station for an example.