Posts by paulevs

Just some more suggestions

19. Export furniture objects together with blueprint geometry (OBJ export)

Right now export works only for construction elements geometry and will ignore all furniture, light sources and so on. Sometimes they can be important parts of buildings and without them buildings can be incomplete

20. Make groups for different materials (OBJ export)

All meshes are merged together into single group, as a result it will be problematic to texture object for rendering or other purposes. If object will be splitted into material groups with names of materials it can help a lot

Just a small test pillar render, original pillar have 4 modern lights on all 4 sides and contains 2 materials - emissive and bricks

Quote from red51

Thanks for the report! There was no specific error so it could be indeed related to the storage issue... we're currently preparing a hotfix for that, if you still experience the issue after the hotfix, please let me know

In the latest hotfix chests and barrels works fine, they don't crash game on exit and save content fine, thank you

Quote from red51

Oh, that's strange Which material tab do you refer to exactly? You mean the "Build" section in the crafting menu? Did this already happen in the previous version (where crafting was introduced)?

Yes, I mean build section. The delay is not too large, but noticeable as it always exits. I think it can be related to huge amount of content inside the panel

Quote from red51

That's not supposed to happen It could be indeed related to the chests... however, if this happens again, please restart the game (until you get to the main menu), then open the console and type "report" to send a report to us

Done

I saw some more bugs:

- The chest will be opened on next world load and it will be impossible to interract with it

- Sometimes visual glitches like stripes of broken pixels can appear, for some milliseconds

- Material tab will take more time to load than all other tabs. It will load slow each time.

- Game can crash on exit, probably it is related to chests (I'm not sure, but chest with items on map will always result with crash)

Some more suggestions:

14. Use single click to pick up stack on cursor instead of holding mouse constantly

I think this can be a small "quality of life change" that will reduce hand fatigue during inventory management.

15. Allow stacks to be splitted inside chests

I don't know is this a bug or not, but you can't split stack in chest, but can in inventory. Splitting them in chest can help a lot when you need to pick up a certain amount of items from chest.

16. Split stack into cursor if it is empty

It will be much easier to operate stack splitting if items will be given to your mouse cursor instead of empty hotbar/inventory cell. If this will be combined with suggestion 14 inventory management will become much better.

17. Display chest content when it is opened

It will just look cool if we can really see items inside chest during animation. It will also allow us create cool decorations like pirate chests or just show our cool loot in multiplayer.

18. Add buttons for quick chest inventory management

Buttons like "sorting", "merge stacks", "put similar items from inventory into chest" will make management much easier

Well, not only stump

Thank you for the new update

Small report - the first thing that I saw was purple tree stump on loading screen

Quote from red51

Oh, this sounds interesting! Could you elaborate on that? Is this supposed to move the currently equipped item to a particular hotbar slot (e.g. when pressing numpad 1, the currently equipped is moved to the 1st slot, pressing numpad 2 moves it to the 2nd slot etc)?

Yes, when cursor is over certain item in inventory pressing numerical key will swap selected item with hotbar item. For example if there is a pickaxe in inventory hovering cursor on it and pressing "1" will move it into first hotbar cell. The content of hotbar cell under "1" will be moved into the original inventory cell where pickaxe was

Some more suggestions:

12. Hide world loading from player

Sometimes chunk loading can take some time before player will join the game, and this process is visible to player and can ruin game atmosphere. I think it will be good if the process of chunk loading and meshing will be hidden with world loading screen

13. Add possibility to move item on hotbar by pressing numerical key

I saw that feature in some other games and it is much faster than drag-and-drop item on hotbar, probably some players will like this more than cursor item movement

Commands are fine for creative, but for survival radial menu is an optimal solution. In Java survival you have much less control on planks shape than in Unity with radial menu (that's actually why plugins for planks exists). I think if someone will make some sort of macros plugin for Unity (when API will appear) you will be able to make a command set that will give you wooden blocks stack with same parameters as Java planks have. Actually, having different macros for creative mode is not a bad idea, but not related to this topic

Personally I never used planks in Java Risen World, construction with only elements is much better than having two separate objects - for planks and blocks. Radial menu is much more comfortable to use than sets of command, shape copy is also very useful to construct elements from different materials in same sizes. I think that planks is a part that is not needed in modern Risen World

Quote from red51

Oh, that's not supposed to happen If blocks are slightly below ground (i.e. if their upper surface is still almost barely visible), they're supposed to spawn above the ground if removed via sledgehammer... this may not work properly on slopes though (if most part of the upper surface is covered by terrain, and if the distance between the center of the surface to the ground is too great)... this definitely needs some improvements. Or did you also experience that on flat ground?

This bug happens on both flat ground and slope, I tested this on large construction elements (with height > 2), this happened on both mountain and gravel plain around it

Some more suggestions that I have:

8. Hide grass if it is under construction element

I think it will look better if grass under construction element will be not visible, this can help with building thin floors or other structures

9. Move items up if they are below terrain

Sometimes when you break element its center will be below terrain, and as a result - summoned item will be dropped below terrain into the void. Suggestion is to moved it to the nearest point of terrain above it, and the player will not lose any resources anymore.

10. Change size of construction elements on icons

Construction elements can have different sizes, but this is not shown on their icon which sometimes makes their identification difficult. If the icon will have same outlook as an element in the world it will be much easier to define what elements you have in inventory

11. Make some construction elements possible to attach with snapping tool

Some elements (Wall Torch) are not possible to place with snapping tools which makes them much harder to place (compared to modern lights)

And if you will enable grid snapping instead Wall torch will be inside the wall until you make the grid really small

My suggestion is to give it same snapping as for modern lights.

Quote from red51

Is there a specific light you where you've experienced any bleeding or artifacts, or could you maybe share a screenshot of a situation where this happens?

Seems like one of old artifacts - "shadow acne" - is not present anymore (probably related to Unity version), or it require specific conditions that I can't recreate anymore. But another bug - light bleeding - can be recreated. Conditions are many modern light sources on large walls and reflective material under them.

Another suggestions that I forgot to mention:

6. Increase maximum lights count in settings

Sometimes maximum number in 50 lights is not enough for large buildings, probably if user have powerful PC it will be good to have more light in the scene.

7. Handling of distant lights

At this moment distant lights are not visible (or cutted due to light amount limit). It will be great it will be possible to bake their light (for example into large-scale voxel grid) or have lights without shadows

Here is my small list of suggestions that I came up during tests of the RisingWorld Unity version. Most of them are visual only and will not affect gameplay, but some of them can be "Quality Of Life" enhancements.

1. Normal & Texture Blending for objects on natural terrain

This technique can be applied to construction elements and objects that have contact with terrain. The reason is to make objects more "natural looking" like they are really interacting with terrain.

This effect can be done only with shaders and it can be toggleable to improve performance on low PCs.

2. Stochastic textures for natural terrain (and probably some materials)

This thing is about creating large no-repeatable texture patterns from one image (in shader), so they don't look tileable anymore. It can be applied not to any material, but many natural substances like stone, sand, gravel, soil, grass and so on can use it. This can make large scale terrain (like mountains) look better.

Unity blogpost about these textures.

3. No-intractable debris from object

Looks like right now "physical debris" from all objects can completely break player interaction with world, for example if you will use pickaxe in front of debris - it will destroy debris piece and not object behind it. I think this is a bit unbalanced behaviour as right now debris is a visual option. So, my suggestion is to make it ignorable by all raycasts and interactions so it will be more like 3D particles than real objects.

4. Mouse scroll enhancements.

Mouse wheel can change cells on the hotbar, but the problem is that it probably doesn't always behave as you expect from it. For example it will not switch hotbar cell if you will spin it too fast. And if it will change - it will change only one cell. My suggestion is to make it similar to other games (like Minecraft, for example) where you can smoothly change all hotbar cells with one spin instead of constantly pausing between them or moving wheel very slow.

5. Increase shadow bias (or make it configurable)

There are some cases of shadow bleeding of some surfaces. If shadow bias will be a bit larger - light will have less artifacts. It probably can be configurable inside graphic settings as different shadow resolution probably require different values.

Small bug at the end of list - shader distance will be reset on every game re-launch to default value. I didn't test other values but this bug can probably have same effect on other graphic settings.

Large scale lighting. I discovered that maximum amount of 50 lights is not enough for such constructions

Edis: same building during the day

Building lighting with new RW modern lights. Sometimes light can leak through walls, but this will be not noticeable if there will be enough light on both sides

Quote from red51

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.

Quote from red51

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

Quote from red51

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

Quote from red51

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.

Quote from red51

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)

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