Very large (~infinite) procedural world

With the new ProceduralMeshComponent in 4.8, I managed to create a simple (as in dumb and unoptimized yet) Voxel Terrain. Screenshot :

My question is : I created a “Cell” actor that stores the voxel’s data in a TMap, how would I create a 3D grid of this Actor that the size on the 3 axis is very large (close to infinity)? Is it a good idea to use the ChildActorComponent in a TMap? Or is there a way to use something like World Composition + Origin Shifting to achieve this?

Thanks in advance!

EDIT : Right now, I’m doing everything in Construction Scripts and in OnConstruction Actor event to be able to modify values in Editor and see real-time the changes. Would I be able to visualize the large grid in editor?

Still can’t get it to work…anyone?

Please? Anyone?

I’ll be opening a forum thread in the next few days with more details. I will comment the link here.

About origin shifting, I don’t think it would be easy : no cloth sims, the only moving meshes would be players and mobs but I want multiplayer and that’s gonna be hard to implement. And I’m not very interested in designing my own custom server but I think I have no other choice.

Your question is pretty big (boom boom) but I’m interested in finding out how to get live updates to procedural content on changes to data in the editor.

Couldn’t get anything consistent myself, but didn’t get as at as looking at the text render actor to see how it does it.

Haven’t come across any origin shifting tech yet but it might exist - you can probably wrap your own relatively easily but I can imagine a bunch of issues that may or may not matter (cloth sims, physics behavior etc) depending on your use case.

I’m using OnConstruction (Actor event) or Construction Script (in Blueprint) to generate the Mesh so when you change data in editor, it updates immediately. But, a problem I ran into with this method is that looping in a TMap containing 64 X 64 X 64 (262144) elements 4 times takes a loonnnggg time (close to 30 seconds).
So I changed to OnBeginPlay event and I’m trying to wrap my head around multi-threading in UE.

As for origin shifting, I don’t plan to use cloth simulation and physics should be as simple as pawns walking (no movable meshes, no destructibles). But I want to be able to play in multiplayer and that’s a problem in regards to origin shifting (the builtin version in UE doesn’t support it…).

And yes it is a big question, might be easier in the forums (gonna post there in the next few days).

are you trying to create a planet to walk around all on? The engines haven’t reached that stage yet,don’t have the tools to allow you to walk all around planets (big massive 100 mille spheres) without falling off them yet, i’m doing a multi planet system game and hoping I can start walking around on them soon.

No planets, just a nearly infinite “flat” world (a la minecraft)

It isn’t very straightforward, but also not very hard. By calling UWorld::RequestNewWorldOrigin, correctly handling world shifts (overriding AActor::ApplyWorldOffset), loading terrain as players comes and unloading as she leaves you can get to coordinates with magnitude 2^31 + 2^20 on current (4.10) engine. Even further if you’ll handle world origin overflow and use some big integers. But still you’ll have to replace real terrain with some approximation at some distance.

I’ve implemented something like this (with world wrapping as additional feature) and can write out a tutorial if anyone would care.

Rememeber that if you are planning to add multiplayer this won’t work. Origin shifting is not supported in MP.

Yes, already heard about it, but without details. I personally not interested in multiplayer, but official documentation propose “Implement some layer between clients and unreal dedicated servers which will transform shifted absolute positions” and i can’t see why is it so impossible.

Cant the near infinite solution be fixed with world shift if you use relative points?
Bassically the relative points are new temporary origins which are parents for sections of worlds. And to fix multiplayer the relative point will communicate players relative location relative to the point (the temporary origin).
And if the point gets towards the maximum value you could unload the level. And reload the level if it is within the range.