This would allow people to import this only by adding a dependency in the manifest.json file. Unfortunately, currently UPM doesn't seem to support examples, so the scenes would have to go.

I saw you already changed to a byte density model and that's nice, yet the memory usage huge (about 10gb for a view distance of 7).

this seems mostly because of keeping the mesh data arrays after mesh generation for each chunk. i don't think you need this data after updating the mesh renderer.

maybe if you implement the chunk loading over time limit (max x chunks at a time) you could implement a pool of x for this data to reduce the memory without having to allocate new memory space each time

After I switched the terrain to generate using 3D noise, I encountered deformation issues. Some chunks are not deformable. When I try to deform the chunk terrain becomes darker but nothing gets changed. They entire chuck seems like flickers or something. And other chunks works as they should. It's really strange..

Hey! It would be really nice if there would be a solution in the implementation to generate different block types and texture the terrain accordingly.

I stumbled into an issue. I was testing out a project and I noticed that when the player goes really far from the origin (0,0,0) position, like hundred of thousands units away, everything starts to jitter. So much that the game is basically unplayable.. How do you fix that? Do you move the world instead of the player? Wouldn't that be really bad for performance?

I know this is not really the project issue, but more of a feature, but feel like something that the infinite procedural terrain should avoid. 🤷

A panel in the game view, where you can see debugging info, such as how many chunks are currently loaded, the current player coordinate, render distance, etc.

The user should be able to show/hide the panel by pressing a specific key, which should be set in the inspector.

The panel should only be included in the editor and development builds.

I don't know this my promble or is a bug or something else.
This appears in "Heightmap World Example" .
I open with Unity2019.3.2f1.
And I really like this project. I appreciate your work.

Implement level of detail. One level per chunk.

= don't load all chunks at once, but maybe a few chunks per frame to improve memory usage and performance.

with your latest commit of async chunks you also changed some things to be generic and imo its not a good change. in fact the whole thing is in a need of a whole new structure that also allows for better control and faster feature integration such as smooth mesh normals.

a lot of the things should be moved from "Example" into the main engine and settings. also separating some components into replaceable monobehaviours instead of generics should be better.

i sent you a privete message on reddit about discussing it if you are interested

Currently when the player edits the terrain, there are two queries to VoxelDataStore (get & set). This could be reduced to one (increase). That in turn would reduce the number of requests to get the densities of a chunk...

This would simplify the API and increase performance.

Good job with the project, the performance is impressive! However, I have observed that, the more you dig/edit, the more memory gets allocated until the system runs out of it. I am not sure if it is a bug or if we are required to manually free the memory somewhere in the code. It is reproducible on both develop and master branches.

One thing would be really nice to improve is the procedural terrain generation performance. Currently it's pretty bad with really long lags whenever a new chunk is created.
One way I can think of is using Compute Shaders, Although, maybe there are better ways I'm not sure.

If you modify the border of chunk by either lowering or raising the terrain the side chunk that will be generated as you get closer will not connect with the modified one

https://streamable.com/pwgb4r

This happens on the develop branch

The chunks should be generated in a circle rather than a cube, to ensure that the chunks closest to the player will be generated before the ones that are further away.

Something in this commit broke it

Hello!

I watched your video on youtube and checked out your plugin. It works really well! However i have one big gripe with it - the project it very messy. Here's my proposal:

1. Move all assets from Marching-Cubes-Improved up into the root, and delete the rest (Logs, ProjectSettings, .vscode). Your project files aren't needed.
2. Delete Rider plugin as it has nothing to do with the marching cubes implementation.
3. Make an Examples folder and move all files that aren't an absolute neccessary part of core functionality into that folder (SampleScene, FreeCam.cs, TerrainEditor.cs, FastNoise.cs, DensityGenerator.cs etc.)
4. Use namespaces. Especially important when you're using class names such as "World" and "Utils".
5. If "World" is part of the core, don't let it refer to anything in the examples folder. The Examples folder should be optional and deleteable. If you need something to generate a world on awake in the sample scene, do it in a separate script. This also helps to showcase how a user would do it.
6. Is the Prefabs/Chunk used at all? If not, remove it.

Doing like this will help users navigate your project much easier, as well as enabling the ability to clone your repo directly into their project so they can start using it.

If i make changes to a chunk using the deforming tool you have made , and then i fly away from it. the chunk resets to what it was when it was created instead of saving the changes i made from the tools.

Save the densities of all the chunks, so they can later be reloaded and thus save whole worlds

Different biomes / regions could be nice to have :]

Be able to import a heightmap image to create the terrain from. The amplitude can be changed from the editor.

I have feature request for detecting floating islands and if detected add collider and rigidbody to it so it starts falling down.

I tried out the system the other day and it simply didn't work. Basically, there are no vertices and therefore no triangles generated in the example scene.

After I saw, that the terrain generation didn't work I modified the code slightly to generate completely flat chunks. Surprisingly, chunks have been created on top of each other.

So that's it. The system simply doesn't work as expected. Ohh and I tried out the Terrain Editor on a flat chunk and I simply got a KeyNotFoundException.

EDIT #1: Position has to be multiplied by chunkSize in order to avoid overlapping chunks and as of the chunks placed on top of each other, it was my mistake as I didn't notice that the system generates cubical chunks, but the terrain noise still doesn't work.

The camera's rotation should stay the same as in the scene when starting the game

I've been experimenting on this project for a bit now and the feature that I feel like could make a difference is adding the ability to generate a terrain using 3D noise.
This would give much more interesting results, with the things like overhangs, arches and etc..

Happens in the SetCoordinate method of ProceduralChunk

Image

Hello, I am currently writing my own data generator which will generate the marching cubes data based off a pre-made model.

I am planning to accomplish this by first scanning the model in a seperate Unity scene, writing all the float data values to a file, and then at a seperate time, loading the values from the asset file and passing the floats data to the generator.

I am passing the float data as a NativeArray<float>.

So finally, my question: how to dispose of the NativeArray I created after the job is completed?

PS. Yes, I realize I am sort of creating an unnecessary step here by loading the float data to a multi-threaded job, only to return that same data, but at the moment I don't see another way of generating the marching cubes from a model.

This would be a really cool feature! To generate procedural caves like in Minecraft

How would you go about handling , asset generation such as trees and rocks onto the mesh chunks?

Also this code is amazing good work!