Jump to content
  • Advertisement
BenS1

Best Engine for Massive Terrains

Recommended Posts

Hi all,

I've been in the process of creating a RTS game in the style of Supreme Commander (But with much bigger levels) for a while now, and whilst I've made good progress writing my own engine from scratch it has become clear that the scale of the project is way too big for one person to do in their spare time (Especially as I work fairly long hours in my day job and I like to spend as much time with my family as possible.).

So, my plan B is to look at possibly using one of the existing Game Engines out there such as the Unreal Engine, Unity etc.

I've done a couple of Udemy tutorials for Unreal, which have been quite useful, however I see that there appears to be a lot more tutorials and information out there for Unity, so I was wondering if I've backed the wrong horse.

The key feature that I need from the engine is the ability to show massive terrains, and by massive I'm not talking 5km x 5km, I'm talking more like 1000+km x 1000+km square! And unlike an FPS type game that can load in terrain segments in tiles based on your current location I need the ability to zoom the camera right out so that I can see the entire 1000km x 1000km map all at once (Although the level of detail can obviously be much lower as you zoom out). If you've played Supreme Commander then you'll be familiar with this style of "strategic zoom".

I already have this working in my own game engine by generating the terrain in realtime on the GPU using multiple octaves of Perlin noise, which has the added bonus of allowing me to smoothly tessellate the level of detail as I zoom in and out (In my engine the terrain is 4000km x 4000km). 

So the question is, what sort of terrain capabilities do the big game engines support? I'm guessing none will support realtime generated terrains?

If not then whats the maximum size pre-generated terrains that they can support? And what LOD capabilities do they have for when you zoom in/out?

Thanks in advance
Ben

P.S. I've tried doing some of my own research but all I seem to find is old forum threads that say things like "there are expected to be big improvements coming to the terrain capabilities in Unreal 4.8", which is now old and I've not seen any confirmation or details about if big improvements did indeed happen.

 

Share this post


Link to post
Share on other sites
Advertisement

Generally handling anything specific (like massive terrain, which will most likely require also other specific features for the game), might be one of the things that call for custom engine.

Not for game, but when creating simulator software I had similar problem (requirement of massive terrain scale with quite large detail) - currently it is completely custom software, as no existing engine gave us the capability for such scale and precision we required. Also, as simulators tend to be custom code (in major part) - an engine was not really a prerequisite.

 

As for existing game engines (that are publicly available), I can speak for Unity - where while terrain system is quite capable, I tend to hit its limitations way too often (in the end, the actual terrain does look ugly), see this (which is probably most RTS-close and quite recent, which I've used in real game):

70ea.png

While it was for my Ludum Dare entry (programmer's art credits go to me), where time management is more critical than anything - hence a lot of noise and patterns on terrain. Nevertheless it can clearly be seen that the terrain mask does not fit the scene in terms of resolution and quality. The mask resolution is way too small (yet increasing it was not really possible).

 

So far the best solution that worked for me was clip mapping and virtual texture approach - in my own engine few years back. I will probably choose the same way for updated version of that engine, and at least try that out.

 

Unity also has some plugins enabling virtual texturing, but be extremely careful - with my own engine I've found out that virtual textures tend to be quite pain to create & edit. They can be generated though (or to be precise - they have to be generated to some extent), which might play into your situation. I can't say for UE, but I believe some virtual texturing (through plug-in?) might also be available.

Share this post


Link to post
Share on other sites

Unity is a very-very bad engine for large world games, out of the box. There is stuff you can buy for it to improve it but in the end you will be reworking a lot of the engine.

Unity:

Spoiler

 

- Unity's terrain tools are out of date. It has nothing that helps setup your scene.

- The coordinates get shaky. It gets to the point where the LOD's of your objects jump around as they are loaded in. It appears to be a problem with there math library. This is a real deal breaker but can be avoided by making your own coordinate projector.

- It's hard to make levels in Unity because without exporters you struggle to get an effective workflow. 

- It has none of the modern terrain materials and still uses the same terrain shaders as old PlayStation 2 games.

- The materials suck in general. No tools to make fine tweaks so you need a new shader just to make small changes.

- No hair or subsurface shaders.

- The instancing improved a bit with 2018 , still not better than batching. Batching works better for small unique terrains.

- Even if the animation system improved it is still very ineffective for open world games. Animation re-targeting is still limited.

- Because it's a batch engine you can have only 64 000 vertices per terrain foliage. (Also for auto animation batching, UI) Unless you know how to assign more vertices to the auto batch tool you get very little foliage.

- Grass and trees don't align to the terrain if you use the Unity tools.

- Reflections are broken. This means you are dependent on light to tint the terrain.

- Shadow baking causes artifacts in the normal map. Not a problem with real-time light.

- Limited amounts of real time lights. Changing the lights for day and night effects is costly.

- Doesn't cull lights.

- No default tessellation options and difficult shader system. Post processing is annoying.

- No proper height map editor. You will have to do it outside the engine. The tools it has is integrated is difficult to see the scale your working on.

- The way the terrain manages it'self is slow.

- The compound collisions have problems, to fix it you need to make very inaccurate collisions. Physics are messy with compound unless all collisions are on the same axis.

- Ray casting actually fails at times, could be because of the coordinate problem.

- Difficult to get your object into the engine. Scaling problems, Axis problems, bones must be connected, the old T-pose thing.

- Out of date UI tools.

- NavMesh should not be used with large scenes. This makes Unity's AI tools limited a bit.

- Very bad memory management with level streaming, as a work around keep player in it's own scene.

- Slow editor.

 

+ Prefabs with scripts are a very nice and light way to manage a single objects. Just don't nest too many.

+ Easy to use level streaming.

+ Unity services is actually affordable and good. Important if you want multiplayer.

+ Unity store has what you need.

In short if you want to use Unity for large terrains you will be stuck with millions of problems. Lucky it has a place where you can by all these microtransactions  tools to round off the engine.

Or you could spend years grinding learning how to make these tools yourself.

Unreal:

Spoiler

 

- Level streaming is hard to get use to. Level streaming makes large worlds easier. In fact anything is a bit harder to use in Unreal.

- Large and bloated file sizes.

- Will need Visual Studio and C++ to make custom terrain tools; if you want them.

- High resolution(8K) Height maps can freeze and kill the engine while editing. Auto save is a must.

- You must inform Unreal when you publish a game with there engine, you don't have to wait for a response but you must inform them.

+ Has every thing I gave a "-" to Unity for.

+ Although it is hard to use it builds momentum, the more you do the easier things get.

+ Good UI tools. Amazing particle tools. Fantastic terrain tools, Brilliant Material tools

+ Hierarchical Instancing and material instancing, Besides providing great performance it allows for procedural materials and meshes.

+ Physics is amazing. You can use it for particles, cloth, and break things to pieces and have performance over for ragdolls.

+ Blueprints: Both the visual coder and the object system. It takes the place of Unity prefabs and does it better.

+ NavMesh works with large terrains.

+ Has materials just for terrains, allows all the fancy tricks.

 

Unreal was build for large terrains. Everything you need is there, you don't have to buy anything extra.

 

A simple comparison can be done, using google image search: "Unity open world" and in a new window "Unreal open world".

This will allow you to see the average open-world of Unity VS Unreal.

 

Making large terrains isn't easy. A environment artist trains for around 3 years to only work on large terrains on a graphics level. If your doing everything it's going to be a pain regardless of your engine.

Edited by Scouting Ninja

Share this post


Link to post
Share on other sites

Thanks both for your replies,

So it looks like I'll continue to explore the limits of Unreal Engine and see if it can deliver what I need or whether I need to revert back to plan A of creating my own engine.

Thanks
Ben

Share this post


Link to post
Share on other sites
On 2/2/2018 at 2:47 PM, BenS1 said:

In my engine the terrain is 4000km x 4000km

That's 16 million km^2, or about 2x the total land area of the USA. That's... a really big playing field.

I'm not aware of any off-the-shelf solution to render flat terrains of that size. There are a variety of specialised vendors of spherical planetary terrains of that magnitude, for example Outerra.

Share this post


Link to post
Share on other sites
7 hours ago, swiftcoder said:

That's 16 million km^2, or about 2x the total land area of the USA. That's... a really big playing field.

I'm not aware of any off-the-shelf solution to render flat terrains of that size. There are a variety of specialised vendors of spherical planetary terrains of that magnitude, for example Outerra.

Indeed, it's meant to be kind of small planet size.

In my engine the terrain is generated in realtime on the GPU so in theory the terrain could be any size and it doesn't have any impact on performance. In fact it'd probably be quite easy to make it infinite in size. The only complications would be around float precision issues, but these can be overcome.

I've looked at Outerra a few years ago. It looks very impressive, but I'm not sure how actively it's being worked on. The website looks exactly the same as when I last looked a few years ago and it still says everything is in Alpha. As far as I can see there's no option to download or buy the engine for your own use.

Do you know of any other specialised planetary engines?

Thanks
Ben

Share this post


Link to post
Share on other sites
10 hours ago, BenS1 said:

Do you know of any other specialised planetary engines?

They tend to be pretty one-off and hand built. In terms of things you can license off-the-shelf, VoxelFarm might still render entire planets, but that's not entirely clear from their recent materials.

After that, Ysaneya has a pretty advanced one, that's currently being in use in their multiplayer space shooter. John Whigham hasn't published much the last couple of years, but his looked very solidSean O'Neil has gone dark for a while now, but he had various implementations floating around. I put mine on ice a few years back (lack of time, and/or need for the thing)...

Share this post


Link to post
Share on other sites

Thanks for info Swiftcoder

It seems like there are a few engines around but they seem to be mostly hobbyist projects that eventually run out of stream, just like my original attempt. I was hoping that there would be a mature major commercial game engine (Including editors and tools etc) that supported massive terrains.

I'll see how far I can get with the Unreal Engine. 

Thanks again
Ben

Share this post


Link to post
Share on other sites
4 hours ago, BenS1 said:

I was hoping that there would be a mature major commercial game engine (Including editors and tools etc) that supported massive terrains.

VoxelFarm and Outerra are the only licensable commercial products under active development I know of in this space.

Share this post


Link to post
Share on other sites

Unreal 4 is the best right now for large terrain.  As part of Heroes & Legends I am developing a plugin and procedural terrain system compatible with Geographical Information Systems using a 2D Vector Database that also enables producing 2D Maps with detailed information and allowing selection and loading of a specific location.  The level streaming is very good.  Right now, if you want something for terrain, Unreal 4 is by far the most mature right now in the way of meeting every need of game development including large world terrains.

Just follow Heroes and Legends project and when "World Max" is out on the market, pick up a copy from Unreal 4 market and use it for your world.

Edited by i3di

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
  • Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By SickTwistGames
      Ok, firstly, Hi.
       
      This is my first post on this forum. I am an Indie Dev making my first game so bear with me when I say dumb stuff, I'm on a huge learning curve.
       
      My first question is about inventory systems for unity. I am trying to make a survival type game with crafting. I have purchased Inventory manager pro by devdog from the unity asset store and it seems like a pretty powerful assett but for an intermediate coder its a little tough to use.  I'm beginning to wonder if it was the right purchase.
      So my question is.... does anyone have any experience of inventory plugins / systems for unity and can anyone reccomend a system to me?
      It needs to have the following: Loot system, crafting system, character sheet, blueprint system,  character stats system. Ideally with as little coding as possible.
       
      Thanks
    • By Stalefish
      Automated builds are a pretty important tool in a game developer's toolbox. If you're only testing your Unreal-based game in the editor (even in standalone mode), you're in for a rude awakening when new bugs pop up in a shipping build that you've never encountered before. You also don't want to manually package your game from the editor every time you want to test said shipping build, or to distribute it to your testers (or Steam for that matter).
      Unreal already provides a pretty robust build system, and it's very easy to use it in combination with build automation tools. My build system of choice is  Gradle , since I use it pretty extensively in my backend Java and Scala work. It's pretty easy to learn, runs everywhere, and gives you a lot of powerful functionality right out of the gate. This won't be a Gradle tutorial necessarily, so you can familiarize yourself with how Gradle works via the documentation on their site.
      Primarily, I use Gradle to manage a version file in my game's Git repository, which is compiled into the game so that I have version information in Blueprint and C++ logic. I use that version to prevent out-of-date clients from connecting to newer servers, and having the version compiled in makes it a little more difficult for malicious clients to spoof that build number, as opposed to having it stored in one of the INI files. I also use Gradle to automate uploading my client build to Steam via the use of steamcmd.
      Unreal's command line build tool is known as the Unreal Automation Tool. Any time you package from the editor, or use the Unreal Frontend Tool, you're using UAT on the back end. Epic provides handy scripts in the Engine/Build/BatchFiles directory to make use of UAT from the command line, namely RunUAT.bat. Since it's just a batch file, I can call it from a Gradle build script very easily.
      Here's the Gradle task snippet I use to package and archive my client:
      task packageClientUAT(type: Exec) { workingDir = "[UnrealEngineDir]\\Engine\\Build\\BatchFiles" def projectDirSafe = project.projectDir.toString().replaceAll(/[\\]/) { m -> "\\\\" } def archiveDir = projectDirSafe + "\\\\Archive\\\\Client" def archiveDirFile = new File(archiveDir) if(!archiveDirFile.exists() && !archiveDirFile.mkdirs()) { throw new Exception("Could not create client archive directory.") } if(!new File(archiveDir + "\\\\WindowsClient").deleteDir()) { throw new Exception("Could not delete final client directory.") } commandLine "cmd", "/c", "RunUAT", "BuildCookRun", "-project=\"" + projectDirSafe + "\\\\[ProjectName].uproject\"", "-noP4", "-platform=Win64", "-clientconfig=Development", "-serverconfig=Development", "-cook", "-allmaps", "-build", "-stage", "-pak", "-archive", "-noeditor", "-archivedirectory=\"" + archiveDir + "\"" } My build.gradle file is in my project's directory, alongside the uproject file. This snippet will spit the packaged client out into [ProjectDir]\Archive\Client.
      For the versioning, I have two files that Gradle directly modifies. The first, a simple text file, just has a number in it. In my [ProjectName]\Source\[ProjectName] folder, I have a [ProjectName]Build.txt file with the current build number in it. Additionally, in that same folder, I have a C++ header file with the following in it:
      #pragma once #define [PROJECT]_MAJOR_VERSION 0 #define [PROJECT]_MINOR_VERSION 1 #define [PROJECT]_BUILD_NUMBER ### #define [PROJECT]_BUILD_STAGE "Pre-Alpha" Here's my Gradle task that increments the build number in that text file, and then replaces the value in the header file:
      task incrementVersion { doLast { def version = 0 def ProjectName = "[ProjectName]" def vfile = new File("Source\\" + ProjectName + "\\" + ProjectName + "Build.txt") if(vfile.exists()) { String versionContents = vfile.text version = Integer.parseInt(versionContents) } version += 1 vfile.text = version vfile = new File("Source\\" + ProjectName + "\\" + ProjectName + "Version.h") if(vfile.exists()) { String pname = ProjectName.toUpperCase() String versionContents = vfile.text versionContents = versionContents.replaceAll(/_BUILD_NUMBER ([0-9]+)/) { m -> "_BUILD_NUMBER " + version } vfile.text = versionContents } } } I manually edit the major and minor versions and the build stage as needed, since they don't need to update with every build. You can include that header into any C++ file that needs to know the build number, and I also have a few static methods in my game's Blueprint static library that wrap them so I can get the version numbers in Blueprint.
      I also have some tasks for automatically checking those files into the Git repository and committing them:
      task prepareVersion(type: Exec) { workingDir = project.projectDir.toString() commandLine "cmd", "/c", "git", "reset" } task stageVersion(type: Exec, dependsOn: prepareVersion) { workingDir = project.projectDir.toString() commandLine "cmd", "/c", "git", "add", project.projectDir.toString() + "\\Source\\[ProjectName]\\[ProjectName]Build.txt", project.projectDir.toString() + "\\Source\\[ProjectName]\\[ProjectName]Version.h" } task commitVersion(type: Exec, dependsOn: stageVersion) { workingDir = project.projectDir.toString() commandLine "cmd", "/c", "git", "commit", "-m", "\"Incrementing [ProjectName] version\"" } And here's the task I use to actually push it to Steam:
      task pushBuildSteam(type: Exec) { doFirst { println "Pushing build to Steam..." } workingDir = "[SteamworksDir]\\sdk\\tools\\ContentBuilder" commandLine "cmd", "/c", "builder\\steamcmd.exe", "+set_steam_guard_code", "[steam_guard_code]", "+login", "\"[username]\"", "\"[password]\"", "+run_app_build", "..\\scripts\\[CorrectVDFFile].vdf", "+quit" } You can also spit out a generated VDF file with the build number in the build's description so that it'll show up in SteamPipe. I have a single Gradle task I run that increments the build number, checks in those version files, packages both the client and server, and then uploads the packaged client to Steam. Another great thing about Gradle is that Jenkins has a solid plugin for it, so you can use Jenkins to set up a nice continuous integration pipeline for your game to push builds out regularly, which you absolutely should do if you're working with a team.
    • By ethancodes
      I've got a bug with my brick breaker style game. The bricks move down one line at a time ever 1.5 seconds. What appears to be happening is occasionally the ball will be just about to hit the brick when the brick moves down a line, and now the ball is behind it. I'm not sure how to fix this. I have two ideas but I'm not sure of implementation. 1 solution would be to check where they were and where they are going to be before rendering the frame. Then if they crossed paths, then register the brick as hit. Solution 2 would be change how the bricks move. I could maybe slide them down line by line, instead of a jump down. I'm not sure of this will fix the issue or not. Any ideas?
    • By MoreLion
      Hey all! we are a team of 7 looking for a game designer, im a game designer but need help as i am doing multiple things at once, the game is being developed in UE4.
      the game is a futuristic action adventure game where you play as a 21 year old female who has woken up in a simulation not knowing who or where she is, but when all is unfolding the simulation gets hacked leaving eveline with no choice but to escape before she is killed inside the simulation.
      we are also looking for other members aswell wether you be a animator a ue4 game developer or that just email me below.
      if interested email liondude12@gmail.com
    • By Pixeye
      I wrote an extension for unity inspector that allows to group/fold variables. 
      Available on github  , cheers!

       
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!