Closed Morphexe closed 1 year ago
Yeah this a known issue, probably something to do with chunk region update, haven’t able too figure out the real root cause.
I am observing the same behavior on the latest version, in editor :
ArgumentException: An item with the same key has already been added. Key: int3(-96, -160, -224)
System.Collections.Generic.Dictionary`2[TKey,TValue].TryInsert (TKey key, TValue value, System.Collections.Generic.InsertionBehavior behavior) (at <75633565436c42f0a6426b33f0132ade>:0)
System.Collections.Generic.Dictionary`2[TKey,TValue].Add (TKey key, TValue value) (at <75633565436c42f0a6426b33f0132ade>:0)
CodeBlaze.Vloxy.Engine.Components.ChunkBehaviourPool.Claim (Unity.Mathematics.int3 position) (at Packages/io.codeblaze.vloxyengine/Runtime/Engine/Components/ChunkBehaviourPool.cs:56)
CodeBlaze.Vloxy.Engine.Jobs.Mesh.MeshBuildScheduler.Complete () (at Packages/io.codeblaze.vloxyengine/Runtime/Engine/Jobs/Mesh/MeshBuildScheduler.cs:230)
CodeBlaze.Vloxy.Engine.Jobs.Mesh.MeshBuildScheduler.LateUpdate () (at Packages/io.codeblaze.vloxyengine/Runtime/Engine/Jobs/Mesh/MeshBuildScheduler.cs:98)
CodeBlaze.Vloxy.Engine.Jobs.VloxyScheduler.LateUpdate () (at Packages/io.codeblaze.vloxyengine/Runtime/Engine/Jobs/VloxyScheduler.cs:59)
CodeBlaze.Vloxy.Engine.World.VloxyWorld.LateUpdate () (at Packages/io.codeblaze.vloxyengine/Runtime/Engine/World/VloxyWorld.cs:100)
Yeah I am planning to re-write the schedulers and the logic that decides which chunks to build, also introducing some throttling in chunk updates could help I believe.
Currently the height map (chunk data) generation is also implemented as a job which limits extensibility as you are restricted to burst compatible c#. Maybe data generation can have it's own plain old dotnet thread it maybe slower but data generation isn't going to be that expensive anyway relative to mesh generation although that depends on how complex the user want the generation to be. Still to facilitate extensibility this seems like a better approach we can always make parts of it jobs based (the actual data filling part)
Hello @BLaZeKiLL ,
I have found this other project with a similar goal. It is not for URP, but the load is fast.
https://github.com/bbtarzan12/Unity-Procedural-Voxel-Terrain
You might want to take a look!
Hello @BLaZeKiLL ,
I have found this other project with a similar goal. It is not for URP, but the load is fast.
https://github.com/bbtarzan12/Unity-Procedural-Voxel-Terrain
You might want to take a look!
I'll take look, if you have done some benchmarks with the same amount of chunk counts for both, how much faster do you think it is ?
One difference I see that does impact performance with respect to the implementation mentioned above is using simple arrays to store voxels, while in Vloxy engine we use a compressed data (Run-length encoding/Interval Trees) structure which does lead to O(logn) read time compared to O(1) of naive arrays.
another thing I noticed is the above implementation is generating the initial chunk data in a coroutine while Vloxy engine does it all in Start() for the first set of chunks, that does have a 2-sec freeze in the beginning and could be why it feels the load up Is slow. This is something I wanted to change, using a coroutine would remove the freeze and we can even add a progress reporter which the user of the library can integrate into there loading screens.
I was able to produce the bug mentioned above every time by moving fast (holding shift)
When moving too fast, the error occurs and the chunks never unload.
New scheduler is merged into the develop branch which should fix this issue, please try it out.
I have tested, and I can confirm it works!
Just tried running the demos on my machine, both IL2CPP and Mono versions have the same weird behaviour. Some chunks generate in the wrong positions, and there are empty holes everything on the map that gets generated.
Check the examples below:
I haven`t dug into the code yet, but this happens every time I run the demo ( different holes and errors) - generation settings are the default ones.