chailotl / osuve Goto Github PK

Necessary for massive performance boost; here's an article that talks about this.

https://docs.unity3d.com/Manual/SpriteAtlas.html

There is a distinct lack of biomedical generation.

This can be remedied using a few layers of perlin/simplex noise across the x/z plane to determine biomes. Temperature and humidity are two that Minecraft uses, but it need not be limited to only these; height is another that can be used as well, among others.

Bonus points for y-based underground biomes.

As a temporary solution, World.GetBlock() simply routes to World.GenerateBlock(), as such it isn't optimal. More investigation is due.

The chunk system seems to destabilize at high (+6) view ranges, where a large portion of chunks do not render. Forceable rendering of them sometimes causes an error in Unity:

Chunks are currently loaded in a 3D loop fashion from one corner to the other.

This is inefficient as focused should be put around the player and their point-of-view of the world.

Somehow I had missed that Unity already has a Vector3Int (and Vector2Int), so things will be changed to use those instead of my own Int3 implementation.

There are some givens about how the terrain generates, thus certain assumptions can be made that can drastically improve perlin/simplex generation; e.g. the surface always generates above y=0.

Perhaps some of these values may be stored in their corresponding columns?

This seems like a pretty interesting project. I would like to see it be developed a bit more.

The default textures are ugly as I never spent any real time on them.

Currently empty chunks use up the same amount of memory as a chunk with any configuration of blocks.

This is wasteful as there are many many chunks that contain only air from the ground level up.

The current terrain generation is very modest, with only the caves sufficient, if albeit too spacious and extensive.

More terrain features such as mountains, hills, plains, cliffs, overarches, and valleys should be considered and implemented.

Textures are currently unrandomized which causes it to look repetitive.

By using randomly rotated (and flipped?) UV’s for some textures, as well as alternate textures, terrain will look more natural.

A lighting system is due, even if a simple lit/unlit sunlight.

A propagation-based cached lighting system is proposed, where light propagates from light sources and around objects, and is cached for performance. Blocks that are exposed to sky are given special sunlight lighting.

Bonus points for dynamic light sources that will likely be a second lighting layer on top of the static lighting layer.

The current system is realtime screenspace ambient occlusion—on top of it being the stock Unity SSAO—which has a rather large hit on performance.

Consideration of cached vertex-based ambient occlusion may improve performance and quality.

Only perlin/simplex noise functions are used to generate the world.

A proposed pseudo-random metadata system to generate small structures that may span at most a few chunks, such as trees and small houses. In short, a loaded but non-rendered chunk may be selected to generate a structure, such that when any relevant nearby chunks begin to generate, they properly generate the blocks of the structures inter-chunks.

Hi, I'm updating chunk meshes, when I'm destroying a block. But block in border chunk won't update, but border chunk are calling the GenerateMesh function.

Do you have any idea why is this not working ?

Due to the decision of using a cubic chunk system over Minecraft's columnar chunk system, a new set of pros and cons have been presented. Among those include determining whether a block is exposed to the sun given the infiniteness in height.

A proposed "column system" similar to the chunk system where each x/z grid is given a column that store important data, such as the y position of the highest block in each local x/z coordinate so as to assist with sunlight lighting. Each column will encompass all chunks along the y axis per x/z grid.

Currently no worlds are saveable to and loadable from disk.

Similar to the column system, there may be useful data that may be applied to a larger cube of chunks, such as Minecraft's regional difficulty. Perhaps entities may be stored per region as well, rather than per chunk.

Additionally it may be useful to store chunks in regions to optimize disk storage in a tree-esque way.

The current atlas system hardcodes the blocks.

A dynamic atlas would be able to load blocks and textures from disk easily, and be able to load worlds flawlessly. Because of the fluidity of this system, each world will need to have a text file that contains the link between byte/int ID and block name.