You’re totally right, a voxel size of 25 is too low for a multiplayer game. For tesselation, I guess the best would be to do it on the GPU, however I have absolutely no idea on how to do that with UE4 procedural meshes. Landscape Architect seems to have done it: https://www.youtube.com/watch?v=P4R_2FQ-BJ0
Done, it’s with the PerlinNoise world generator. You may have to increase deletion time in the Voxel World settings to avoid holes.
That’s indeed going to be a problem, as the number of threads is critical for performance here, which means 8 core CPU is really twice as fast as a 4 core one.
Voxel size of 25 looks really good on my system and renders fine as long as the world is not having to update. 120fps at a stand still but dropping to single digit fps just moving around a bit. Even pacing back and forth from one point to the next still gave single digit framerates even though that part of the terrain had already been updated the first time I passed through that area. Using the voxel tool on the default setting it has when you start the game dropped fps to around 90.
Voxel sizes 125-150 offered far more acceptable frame rates that would put the terrain I think in the playable area. Never dipping below 20fps. But the voxels are far easier to see and make out but maybe there could be a visual solution there which wouldn’t increase the complexity of the actual voxel terrain itself.
Do you know of Space Engineers and Emperion? Both seem to use a larger voxel size with Emperion being what looks like around 150 - 180 voxel size and Space engineers around 100 - 120. Emperion being the most stable one of those two by a long shot. So comparatively speaking here, your plugin for UE4 is already approaching what I have seen in commercial games already in my opinion. Just needs some more tweaks to the presentation and generation.
I am on a quad core system here btw. I hope to have a Threadripper system running by this time next week so it would be interesting to see how this plugin performs with 16 cores instead of just the 4.
I have seen this some time ago but I was under the impression that the tessalation done there was a solution in the landscape material. Maybe I’m wrong.
Default settings are for an 8 core CPU. There are 3 settings for threads: MeshThreadCount: Number of thread to render far chunks HighPriorityMeshThreadCount: Number of threads to render nearest chunks. Those threads have an higher priority FoliageThreadCount: Number of threads for foliage
By default, *MeshThreadCount *= *HighPriorityThreadCount *= 4, so on a 4 core CPU, all core are used, including the one used by the main UE thread, leading to bad FPS. You should have way better results with *MeshThreadCount *= HighPriorityThreadCount = 2 (or *HighPriorityThreadCount *= 1) .
The main factor affecting performance is the WorldGenerator. The PerlinNoiseWorldGenerator is quite heavy as I’m not caching any values, so there may be space for optimization here. To see how performant the marching cubes implementation is by itself, you should try the FlatWorldGenerator.
Material tesselation doesn’t work for procedural meshes, as explained here.
Adjusting the thread settings for the voxel world did improve the responsiveness of the game. Still seen single digits when moving around but not as bad as it was earlier.
@Phyronnaz it looks now really impressively! it’s really cool that Ali helped a competing system.
I’m planning to add it to my RTS project, but I would like to know how good its performance comparing to landscape? In my case the full terrain should be max. 1kmx1km (game area is 500x500m), and I need to do rare and small area changes, like smoothing terrain on building placement, digging moats around castle walls, or making craters after explosions. this game genre is quite a performance eater, so I have to optimize all the sub-systems as much as possible to keep the playable units quantity around 400-500…
The main advantage of marching cubes over a heightmap based landscape is the possibility to have 3D shapes. I don’t think it would be that useful in a top-down game. Moreover it has a lot of disadvantages compared to Landscape:
Collision only works in near chunks
Resolution is lower
Uses lots of CPU to build chunks on the fly
Materials are a lot slower (no texture arrays in UE :() as Landscape generates a custom material for each landscape component based on the layers used
I’d say this plugin is for first/third person games that requires one of the following:
Infinite world
Realtime edit
Shapes that can’t be done with a heightmap: Planets, caves …
If you really need realtime edit, you should go with a procedural mesh based on a heightmap.
@Rareden Yes, the size of the world is 2 ** Depth * 16 * VoxelSize and Depth <= 20 (uint64 limit). For a VoxelSize of 100cm, world max size is 16 777 216 m.
SphereWorldGenerator with a radius of 600 000 00 cm:
You just have to convert cartesian coordinates to spherical ones:
I’m going to add an interface to easily create world generators, were you will be able to choose between flat/spherical/… worlds, and add layers to them.
Just found out about this plugin, amazing work with clean source code!
You’ve done a lot of improvements since the beginning already, but the limitation of marching cubes algorithm is showing in some areas. Instead of just trying to crank up the voxel density, consider perhaps using dual contouring (http://www.frankpetterson.com/publications/dualcontour/dualcontour.pdf and Contouring Implicit Surfaces) which voxel farm uses (Procedural World: From Voxels to Polygons). The general concept is that you add surface normal information in voxels to determine surface topology, which allows you to faithfully recreate sharp features.
I’ve been also thinking about the galactic scale world problem. While ue4 may be able to render up to a certain landscape like distance, if we want to support something like star citizen scale it seems like the easiest solution is to have a separate system which calculates distances and points in uint64 relative to solar system + uint64 relative to galactic offsets and then have your geometry mesh scale with the distance from the viewer in some logarithmic scale to place the actual mesh triangles within the ~20km of your float safe playspace. If done right the viewport would look identical to the real thing. For implementation I was originally thinking mesh component scaling + vertex shader to handle cases where partial geometries are within your play area but larger than ~10km where logarithmic scale could take over. Just spit balling ideas, it’s a wishlist feature to support galactic scales in ue4, but I’m sure it can be done.
Awesome work!
Question, are the voxel tools exposed enough so that instead of giving the player direct access to editing, we could just tie the voxel tools to say an explosive projectile in blueprints?
