Hey guys, I want to share with you my latest project.
It is an in game world creation tool that allows players to create and modify their own worlds.
I did this as part of a graduation work.
Everything is done using procedural meshes and dynamically instanced meshes for the foliage.
Feel free to check out the video:
If anyone has any questions on how I tackled specific elements of this project, I would love to hear them!~
Ive seen this some time ago, one of your teachers showed it to me - very nice work man!
I have a few questions for you:
-How big can you make the world, technically speaking. Would the performance and data storage overhead support worlds with several km length width?
-Can worlds be saved and used as actual playable level for a game then?
-Does the thing support close-ups? How detailed are assets and would the thing hold up if you have a first person player walking around down there?
-Are you planning on expanding on this? Maybe add an algorithm similar to minecraft that also produces different weather zones like deserts, canyons, jungles, grasslands (like you already have), seas, lakes, oceans, rivers, forests etc. ?
-Have you considered teaming with people like this dude? The Eden Project - Work in Progress - Unreal Engine Forums Your two projects combined would make for some awesome results im sure!
Cool, mind telling me who showed it? I am curious.
-Theoretically the only thing that limits the size is the rendering. All functionality like sculpting, conforming to roads and such is calculated on isolated tiles. Unaffected tiles stay dormant and do not add any overhead. Currently there isn’t any sort of CLOD system built into the terrain because that is simply not supported by the procedural mesh components. A system like the one no man’s sky uses would actually be quite feasable. You could generate extra chunks on the fly and store them, this would mean you can keep running in an infinite terrain and just keep loading the chunks that are in view.
-There is no straight forward way to convert this to a native unreal terrain object. The game would have to run on the generated terrain. Saving is really just a matter of saving all the points of the mesh and locations of foliage. I have been meaning to add a save/load functionality. This is definately first on my todo list.
-For this I am really waiting on 2 technologies to come to procedural meshes. The CLOD and Tessellation. Combining these two with some solid height maps would really allow me to crank up the realism even more, even at closer ranges.
-I am going to expand this, it is part of a larger project (a city builder) that I am working on. I have taken a bit of a break from the project however since I have been working on it non stop for school.
-Not really no.
Saw this the other day, really nice work! Think I will retire development on my terrain generator as yours is much better I do have LODs but I had to implement with a separate PMC instance for each LOD/tile, which isn’t terribly efficient.
So I have a worldmanager actor that tracks a pawn, once every X ms it checks the player distance to each tile and then calls a generate function on any tile with LOD changes (also checks when the pawn crosses a tile boundary and flips a row/column of tiles across to the other side of the world so it effectively builds the terrain constantly around the pawn).
I have a PMC for each LOD level on the tile component (ZoneManager). When a LOD is called for the first time on a tile it allocates all the data structures, then spawns a thread to calculate the geometry, and when it’s finished it flips the visibility of the PMCs to the appropriate LOD. I don’t aggressively clean up the data structures, so there’s a lot of memory wasted, but you could flush them all once a LOD isn’t active. I’ve not done any serious profiling, it was just learning project/POC and I’m not really actively developing it anymore. Feel free to poke through the code
It’s not bad, I had a tinker with it last night to compare it with my own experiments.
The biggest issue you have right now is performance - framerates are way, way lower than they should be and I don’t think this is just a lack of LoDs. It might extend from the fact you seem to be doing an awful lot inside tick, which is generally not adviseable.
There are two major overhauls I would recommend before going any further and implementing new features:
A) Stop doing all your logic inside of a pawn class. Pawns are representations of player objects and are optimised as such - you should really be using a custom actor. Your player controller class is what should be handling input, though for the sake of your demo it’s not too bad to do this in your pawn. You want to split your input handling (i.e where is my cursor), your terrain editing modes (which tool am I using) and your actual terrain into three different classes. This will make the project easier to manage, and allow for variations without having to pick apart an entire class for that purpose. The more you break it down, the more flexible it will be; for example foliage handling could be a discrete class that you can swap in and out to create different biomes.
B) Stop doing things in tick except things like polling the mouse cursor location. If you’re doing a lot of things every tick, you’re slowing your whole game down. Break up your logic into multiple discrete functions and call them on an event-driven basis. This should help you sort out performance problems, and also makes the implementation cleaner, easier to manage and more flexible in future.
Doing this work now will save you enormous hassle later.
Edit: I forgot, but there’s a nitpick that’s an easier fix and will help you clean your spaghetti up a bit:
C) Learn to use structs and enumerators - there’s a few places where you’re using strings or piping lots of single, but related variables through functions. Turning these into structs and enumerators will help clean up your blueprints.
This is super interesting stuff, I will definitely look up some documentation on how to tackle these things.
In researching this my focus was mainly on getting a working project, I am not that well versed on the ins and outs of unreal editor performance so I really appreciate your taking the time to suggest these things.
I will definitely update the project with yours suggestions, thanks!
Have a well maintained and frequently updated product in the marketplace requires quite a big time investment.
Especially when you provide active support. I am not sure you would be able to recoup this cost on such a specific product.
@Synnoid That’s pretty cool. I was going to buy it to learn from, but was hoping it had LODing in it already. If I buy it now, will I get your LODing work when you are finished too? Also, is this all in C++ or Blueprint. I do all my work in C++ so am looking to build some custom terrain for my game in C++.
The project is made with blueprints. And no LODing is not in yet. It is not really supported by the procedural mesh component and I haven’t really figured out an elegant way to approach it.
If you buy it you get all updates, but honestly if you are looking to create a C++ version I doubt you will learn much from the blueprint project
IMHO, the biggest barrier to learning anything from the project would be it’s organisation; the blueprints are frequently heavily spaghettified, functions have names that don’t necessarily describe what those functions do, and variables that are passed around between functions don’t retain their names.
You can definitely learn something from it, but I suspect you’ll end up re-organising a lot of it in the process.