Custom Worlds

Quote from paulevs

The first one - is it technically possible for new Unity version to support more than one world at runtime with ability for players to travel between them? Like, for example, 2 worlds with different structure and some sort of ability for players to travel between them? This is not for the vanilla game, mostly for the API, so someone can make a plugin with some sort of additional world/worlds, this can be used for many different aspects (custom RPG, player-only base worlds and others)

You mean a concept like different "dimensions" (so an arbitrary number of independent worlds can be loaded simultaneously)? This would be a nice feature and we have been thinking about adding that to the Java version back then, but unfortunately there would be quite some work involved to implement it - and considering this would be a feature that's only useful for the Plugin API (which unfortunately wasn't used by many people in the past), we put that feature on the back burner...

However, once the new version is more fleshed out and if there is some demand for such a feature (or at least if the game gets more active users), we will take such a feature into consideration again

Quote from paulevs

Second question (mostly related to my older questions) - how far it will be possible to control generation with API? Will it be possible to define custom voxel data or heightmaps for the terrain, scatter custom objects/plants/materials over the world with more advanced way then in Java version (with game handing their storage in database per chunks, saving/loading them and multiplayer object management)?

It is definitely our intention to give more freedom to the API when it comes to the world generation. We're still not 100% certain about how the API will look like exactly, but probably you will be able to create a custom world generator class. It may then contain methods which provide terrain data (as 3D array), plant information (i.e. a list of all plants inside a chunk), object information etc. These methods are then called per chunk. Alternatively we may offer a way to register custom "world parts" (which provide these information for a larger area of the world).

We still appreciate any feedback in this area, but irrespective of how the API will look like exactly, you will basically have full control over the world generation

When it comes to custom objects, I can't say much about them yet unfortunately... but custom plants (or custom npcs, for example) will be useable by a custom world generator. Unfortunately we have no ETA for custom objects, plants or npcs yet...

Quote from paulevs

Third question is about terrain, will it be always bounded to heightmaps for the distant LOD or it will be possible, for example, to use low-res meshes for it? Heightmaps can improve performance a lot, but they have many restrictions, probably it can be possible to switch lod type somehow? Like different graphics/world settings

Currently we have no plans to change the LOD chunk handling unfortunately The current approach (heigthmaps for LOD chunks) is indeed very limited, but the main benefit is that the game can generate these chunks blazingly fast at the moment (compared to regular chunks which rely on marching cubes). Considering the much higher view distances compared to the Java version, it would be quite slow if the game has to generate more complex chunks instead of the rather basic LOD chunks... in addition to that, the game would have to store a lot more data per chunk: Currently LOD chunks indeed just hold the heightmap information, while regular chunks (i.e. within the "detail view distance") hold the full 3D terrain data. This only applies to chunks which have any data other than "air" though, but since the new version is capable of having tall mountains, this could still result in a lot more data (and RAM consumption accordingly)...

Having that said, we're actually not 100% happy with the current LOD chunk generation. Maybe we will look for ways to improve it in the future, but right now we first want to focus on other parts of the game (which are urgently needed, like proper survival and exploration features)

Quote from paulevs

Actually Dimensions is probably not the correct name for them, as they are technically not dimensions of space, but another worlds with same euclidean metric . This feature can be really powerful, I hope that one day we will have it.

Thinking about "dimensions" as "parallel universe" (or perhaps the concept of "dimensions" in Minecraft), that term does not look too wrong to me

But we will definitely keep that feature in mind

Quote from paulevs

I have a small suggestion - it is possible to use voxel octrees to build distant LOD, octree will not increase data too much, but marching cubes will run faster on less data resulting with fast and volumetric LOD

Unfortunately that wouldn't really help This would mean the client still needs to generate the full terrain data for LOD chunks (right now this is only done for regular chunks, while there is only a fast rough 2d representation generated for LOD chunks). And on max view distance, the game has to process up to 50k LOD chunks (and chunks are 4 times bigger compared to the Java version) - marching cubes would be considerably slower than our current LOD generator, so world generation would become too slow in that case...

There are ways to speed that up though. While our current marching cubes algorithm (and also our LOD generator) is implemented in C++ (which is already many times faster than Unitys IL2CPP), it would be even faster if we use compute shaders for that. We will certainly give that a try in the long run, but right now there are unfortunately so many other pressing features on our to-do list

Quote from paulevs

Same method can be used to generate high level of LOD, but instead of heightmap it will generate voxels of high octree levels (with filling all voxels below heightmap value)

Not exactly, if you want to benefit from having a more detailed LOD representation with caves and overhangs, LOD chunks need to rely on the same generator which is responsible for generating the regular 3D terrain data (instead of relying on the 2D generator, which just outputs a heightmap)...

Quote from paulevs

As there are not a lot of voxels (probably the lowest voxel level can be a single voxel for a full chunk) it will be fast

If the resolution for LOD chunks is too low, it looks bad unfortunately. Currently it uses half the resolution of regular chunks (16x16 voxels horizontally instead of 32x32), which looks quite good (in terms of details). However, using lower resolutions (especially very low resolutions like 4x4, 2x2 or just 1 voxel per chunk) works on flat terrain, but looks bad on mountains or cliffs. Here is a comparison of LOD chunks with a low resolution (2x2) and LOD chunks with the current default resolution (16x16). The chunks close to the camera are regular chunks btw.

It would work for distant LOD chunks, but currently there is no way to have different LOD levels per chunk (handling that for so many chunks would increase memory overhead and degrade performance even further).

While the current approach is indeed very limited, it provides the best balance between quality and performance in most scenarios (there are a few bugs though which cause some visual issues right now - they will be fixed in the near future). But as mentioned, it fails at overhangs and cliffs (and also fails if a user wants to create a floating island, for example), so there is definitely room for improvements - but first we have to focus on other features (which are more urgent) before we can rework the LOD handling

Quote from paulevs

I mean that this can be only some sort of adaptation for the current RW generator (a kind of optimisation - if current generator uses heightmaps it can generate LOD faster), the LOD itself and volumetric generators (and caves) will require some sort of density function to generate LOD.

That does not work without degrading performance: Having a heightmap representation of the terrain available is not only helpful for LOD chunks, the game uses this information for other things as well (e.g. to decide which parts of the terrain will be affected by snow, or to handle ambient sounds properly etc).

If we want to keep it, but also have to generate additional data with higher resolution at the same time, this definitely has performance implications.

Quote from paulevs

This is one of things sparse voxel octrees are created for - different LOD for chunks on different distance (and faster LOD generation for distant chunks). Voxels are stored hierarchically inside a tree, with 8 leafs per node, so for chunk with 32 blocks there will be 6 hierarchical levels, but these levels don't need a full grid of voxels.

This does not cover the actual problem: Octrees still have overhead we don't have to deal with at the moment. Irrespective of how much optimization will be put into their implementation, they will be slower than the current LOD implementation (unless we want to fundamentally change the way how the world and terrain is generated).

And when talking about memory, the terrain data isn't necessarily the main issue (only when it comes to serialization/deserialization or network traffic, but that's a different story), the main issue are the different meshes that need to be generated for this - and there is no way to save much memory on them. Currently the game only generates LOD chunks (both the data and their meshes) once and then never touches them again (unless the world at that location was modified). The game only has to distinguish between LOD chunks and regular chunks (although regular chunks are based on LOD chunks), so this handling is rather cheap (in terms of performance). If we want to implement dynamic LOD handling (i.e. only generate the different LOD levels when they're needed), this will be more complex and will definitely degrade performance compared to our current approach.

Quote from paulevs

Blockscape appeared in 2012, and this method worked fine these days, it will not cost too much performance, and probably will be even faster that the current one

IIRC the old Blockscape version back then had some issues regarding performance (and there was probably a good reason why the dev switched to a different style the last years), however, I'm not sure if you can really compare Blockscape with RW. The game has a different style, and while the mountain looks great in Blockscape, the same mountain wouldn't look that great in RW.

You also have to keep in mind that terrain generation is only a small fraction of the things the game has to generate - so we can't spend too much of our frame budget on it. In Blockscape, for example, or in block based games like Minecraft, terrain and blocks are typically the same mesh. This approach doesn't work for RW, so plants and constructions still need to be generated separately (especially generating the latter can be quite time consuming).

At the end of the day, implementing a better algorithm for LOD chunks would only slightly improve the final visual result in most cases (on natural terrain, our LOD chunks typically fit quite well to regular chunks), but at the same time, this would result in a slower world generation (and probably a higher memory overhead).

As mentioned before, while there is certainly room for improvements, we can't spend any time on reworking the LOD chunk handling at this stage.