Posts by paulevs

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

Hi, there is a small bug with certain shapes (cones, cylinders and pyramids) - if their dimensions are different from 1 their UVs are stretched (looks like they are same on one of shape axis)

Quote from red51

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)

Just some additional tests with more light sources (up to some thousands) placed procedurally, there are no any lights in the scene, only geometry with emissive materials

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)

Thank you for the explanation

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 Planets³ (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.

Quote from kluge60

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:

Insert actually works fine for size copy, this is also usable tool

Some illustrations:

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

@kluge60 all building walls have different angle as the building itself have an egg shape, so sloping windows are only a view illusion, each window is correct

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

Some small progress with building - design of the first floor and start of the second floor

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

Quote from red51

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

The current Java version seems like have some king of culling, but the new Unity version - don't. If I guessed correctly the reason is higher complexity of geometry - different shapes, rotations, scales and so on. But without culling meshes will exponentially grow in size especially for large builds. Merging meshes into one (current approach) helps a bit, but only until amount of pieces will become really large.

What are benefits of culling? Here is a small example - if you have a cube made of smaller cubes (for example 8 * 8 * 8 or 512 cubes) it will have all faces for each cube by default (6 * 512 = 3072 faces)

But if we will remove (cull) all inner faces between cubes (as they are invisible) we will get only surface squares, for this cube this will be 8 * 8 * 6 = 384 faces, it is only 12,5% from original cube faces

So, this is simple for cubes oriented by grid, but what about more complex geometry? Well, it's more difficult than for cubes. I tried to find solution for this problem in general and found this topic. There was suggested interesting and simple method - culling by normals. The problem itself is to define when object face is inside another object, and the easiest solution is to compare points of this object with nearest face of another object and comape with its normal. If the normal have the same direction as the distance to face - point is outside the object, but if not - it is inside.

Solution for attached square faces can simpler - if both faces have oppositely directed normals than if they have same points (with distance between < 0.01 or other small value) - both faces should be culled, otherwise only small face should be culled.

Culling will also be a good solution for transparent faces problem that was discussed here.

If someone knows more successful and universal algorithms - feel free to suggest them. Let's help Red51 together

Images source article (about greedy meshing, another optimisation algorithm)

Quote from Silverspeedy

Avanar Here is the 2 pictures which shows what I am talking about. First picture show the lines in the glass block...made sure I was not holding anything. The second picture shows the glass block blocking the stain glass block. Makes look clear but no light can pass through it.

The rounds blocks still need to try that out.

These lines are result of missing face culling in Unity Rising World. As new Rising World uses more different shapes with rotations & scaling it will be hard to implement face culling (but it will be good for performance). So, at this moment the best solution is just to scale element to size that you need instead of making many small-sized elements

If someone interested here is wether definition table. If you want to add this weather you can do this by manually edit definition.db (be careful and make backups of your worlds & database)