[SCENE] Terra Nova - Dynamic in-game environment builder

[Synnoid]

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:

You can play around with the packaged build here: https://gumroad.com/l/AyxH
or grab the entire project here: https://gumroad.com/l/xyTc

If anyone has any questions on how I tackled specific elements of this project, I would love to hear them!~

Have a nice day!

[HeadClot]

This is really cool!

[Synnoid]

This is really cool!

Hey thanks man!

[Adeptus]

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? https://forums.unrealengine.com/show...e-Eden-Project Your two projects combined would make for some awesome results im sure!

Really good work man, keep it rolling.

[Synnoid]

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? https://forums.unrealengine.com/show...e-Eden-Project Your two projects combined would make for some awesome results im sure!

Really good work man, keep it rolling.

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.

Thanks for checking out the project man

[n00854180t]

This is really cool - I've been needing to tackle runtime editing for my game for a while but was avoiding it since it's a decent chunk of project myself. Picked it up in a heartbeat

[ClavosTech]

Impressive! The reassurance about world size is good to hear....

[mid_gen]

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.

[Synnoid]

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.

Interesting. Do you swap them out based on camera distance? How does that impact performance?

[mid_gen]

Interesting. Do you swap them out based on camera distance? How does that impact performance?

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

https://github.com/midgen/cashgenUE/...Source/CashGen

[ambershee]

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.

[Synnoid]

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!

[ClavosTech]

I've not done any serious profiling, it was just learning project/POC and I'm not really actively developing it anymore.

Pity! Sounds obvious, but there is plenty of room in the marketplace for a polished product.
Lots of innovative solo work is being done on landscapes, procedural planets, foliage etc.
But if any author disappears, then the plug-in is toast or locked to an old engine version.
Better to pay more to get a more complete product. Just the price of quality collaboration...

[Synnoid]

Pity! Sounds obvious, but there is plenty of room in the marketplace for a polished product.
Lots of innovative solo work is being done on landscapes, procedural planets, foliage etc.
But if any author disappears, then the plug-in is toast or locked to an old engine version.
Better to pay more to get a more complete product. Just the price of quality collaboration...

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.

[wilberolive]

[MENTION=115910]Synnoid[/MENTION] Just found this. Very interesting. Are you still working on it? Have you done anymore since release?