Posts by paulevs

    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)... :|

    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.


    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).

    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.


    There are 2 important notes about such trees:

    • Not all voxels and levels need to exists, missing data will safe a lot of memory;
    • It can have dynamic LOD based on distance for free, its just its nature.

    This technique can be also applied to marching cubes. Some games already use it (blockscape, for example), especially for big/infinity worlds. And when generator need to generate distant land - it will generate only required level of octree instead of full grid generation, this is why this generator have semi-equal generation speed - with twice larger area we will require same amount of voxels as for the small one, they will just be bigger. This actually means very large possible distance (up to some kilometers and more, blockscape for example had 8 kilometers with similar technique)

    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

    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...

    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). 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. Current generator will work mostly similar and custom generators can define function for terrain density. The same function will be called for LODs, but for larger and larger distances for higher and higher LODs, in this case generator speed will be identical for any area

    You mean a concept like different "dimensions" (so an arbitrary number of independent worlds can be loaded simultaneously)?

    Yes, some sort of. 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.


    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) :D

    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

    Hellow to everyone, I have three questions for the new API and game version.


    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)


    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)?


    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


    All these questions are mostly about custom world building, the current RW systems have mostly limitless potential (especially in building), so I hope that something like custom worlds will be possible as this will expand creativity to entirely new level :)

    However, unfortunately this doesn't seem to be compatible with Unitys scriptable render pipelines, more specifically with the HDRP. Shaders work different there, and most parts of the old Unity Graphics API (which are used by SEGI) are no longer compatible with HDRP - so there would be quite some work involved to port this to HDRP...

    Yes, original SEGI is not compatible with scriptable render, but there is a project with same approach that is compatible - VXGI (GitHub), it was designed to be compatible with scriptable render pipelines, was inspired by SEGI and have same license (MIT)

    red51, hi again, can I suggest one interesting thing that I found?


    There is a thing called SEGI, a realtime GI from Sonic Ether, developer of SEUS (Minecraft shaders), this GI technique he used in his shaders and published as a package for Unity. It allows create realtime GI with scene voxelisation, and this GI works fine with emissive materials, procedural geometry and moving objects. It is also highly configurable, which means that it can be used on all PC levels (from disabled at all to ultra settings). And it also don't need any GPU raytracing, you can use it on regular videocards.


    I tested this myself in Unity 2020.3.18, and looks like it is working fine, after some tweaks I get really great results


    SEGI is under MIT license, so it is possible to use it in Rising World, I guess, it is also an open-source project.


    SEGI GitHub (with releases, I tested version from it)

    SEGI on Unity forums


    It was on unity store some years ago, but looks like it is now completely open source. Asset package contains good manual how to configure it.


    This technology can bring almost infinity light sources (voxelisation is not bounded by amount of light), and this thing can be used with many different things - from soft-light sources to emissive textures. I think this can bring rendering to a really new level ;)


    There is also another benefit - realistic light in scene, as this can also simulate light reflections from materials (as GI was originally created for this), this can make realistic forest light or really good atmosphere in player buildings with windows (as there will be more soft daylight)

    Hi to everyone. I'm just curious - how the emissive materials will work when they will be fully implemented? Will they have glow or they will just have a constant color? Will they produce actual light or they will be decorative only? And if they will - this light will be with Unity lights or with some kind of GI? Thanks for your answers :)

    This suggestion is based on really good realisation of such idea in another (and already dead) game Planets3 (aka Stellar Overload). Idea itself is to make some kind of construction from ordinal RW elements, but attached to some kind of "core" block that can move with certain conditions (for example some kind of engine for land vehicles, rail platform for trains, flying engine for flying vehicles, etc)


    Here is an example gow this looked like in Stellar Overload - ordinal game blocks and constructions were attached to core block and can move using energy and controls


    This approach allows to create any vehicles that players want, and actually each vehicle can have its own save file (with similar structure to single world chunk) that will also allow share them and probably integrate it with Steam Workshop later. This idea can be also expanded to reach more realistic vehicles, for example vehicles with engines will require fuel to operate or some important parts for engine to functionate.

    paulevs , 1. Bild, auf dem Boden liegt ein langer Block mit Ziegeltextur. Du hast in der Hand auch einen Block mit Ziegeltextur und hältst ihn an den anderen.

    2. Bild, jetzt ist der vorher kleine Block genau so groß wie der auf dem Boden liegende.

    Ich bin davon ausgegangen das du dass mit Einfg gemacht hast. Wenn nicht sag mir mal wie dann. Denn der 2. Block hat ja jetzt die selbe Form und Größe.

    I just switched screenshots order - I placed block with correct shape and size first, made screenshot, than reset to default shape and size and make another one (first screenshot). Both shapes were cubes, but I can make a new illustrations with another shape:

    Not quite, I mean copying from the world (from the object the player is looking at). And this can include not only object shape, but also an object size

    Sometimes when you build a large scale structure, or you want to change material without changing shape, or you have stopped building for some time, or you don't want to overfill your inventory with dozens of stacks with different shapes - you will need to recreate shapes of already existed elements in the world. The easiest solution will be shape copy from the world object to stack in the hand with hotkey (middle mouse button, for example). This will allow transfer shapes to different materials easily and continue building when all your stacks are reset

    Voxelisation itself is simple and can be applied to any geometry. Here is small old example of my voxeliser. It uses mesh triangles as a source for voxelisation. Interior can be filled with simple flood fill algorithm. For suggested approach voxels can be large, so this stage will be very fast

    But in addition to this, it's also a lot slower to find neighbour elements in the new version: In the Java version, each block was stored in a flattened 3d array, so we could simply calculate the actual array index from the block position (which was always an integer position) - this way it was very easy and blazingly fast to find all neighbour blocks. In the new version, there is no way to find an element depending on its position, so we still have to go through the whole list until we find the appropriate element. This results in lots of comparisons.

    You can use a very simple, but effective approach - temporal voxelisation. For example you have a grid of "temporal voxels", each voxel is a list of elements. When you need to calculate a mesh you firstly iterate all shapes and check what voxels they occupies (with adding this shapes to list). Then when you need to check face overlapping - you need to test only some voxel lists instead of full object list. This task can be also easily be paralleled as all lists will not change during this operation. After operation is complete you can empty lists and use in another mesh building