#voxel engine
median briar
I'm making my own one.
median briar
Chunk loading and offloading. It generally takes time, including mesh generation, and I just want it to compute on another CPU core so that it doesn't slow down the main thread and FPS.
Reducing the time it takes is for later. It will read database entries later on too, so asynchronous execution from the main thread is a certain must.
pseudo wyvern
is mean u want how to optimize voxel engine on other thread?
median briar
Not the whole voxel engine, just a piece of code that executes every frame in Update(). I want it to instead execute asynchronously from the main thread and Update().
median briar
For example
Haven't checked, I'm not at my main rig rn. It's certainly around 70ms for empty chunks and 800ms for fuller chunks. It needs optimization, but that's not my main goal right now. I just want this code to run asynchronously on another thread/Core and not slow down the FPS fo the game. The chunks can take their time to load, but I don't want the player to lag during it.
pseudo wyvern
ok
i suggest you should optimize gen mesh first
what your chunk size?
16 or 32
median briar
That's not my main goal right now. I just want to offload the voxel engine to work asynchronously on another thread.
pseudo wyvern
i will say you should learn optimize gen mesh with thread, async
if u can do it
is simple for do everything
my gen mesh it use 20ms
per chunk size 16
try optimize with simple to hard
median briar
My chunks are of size 128x128x128 (for large chunks), and I have 1.000 of them, although I plan on having 10.000. They aren't meshed with blocks, they use Dual Contouring for smooth surfaces without the need of large resolutions. This meshing is done on the GPU for ultra-fast generation, however something is restricting its speed, maybe the communication overhead between GPU and CPU.
I will be looking into it another time, right now I just want to have the chunks be loaded not on the main thread. It would also fix a few bugs I suspect to arise because of the long execution time.
median briar
The noise generator is not implemented yet, it just generates a sphere with a certain radius rn xd
The size is 128 because the generation will be super-optimized and I plan on having a huge chunk of the world always be visible for a true effect of a large world
It also plays well with the LOD optimization later on, which simply reduces the resolution. Having more initial resolution allows for more LOD stages.
pseudo wyvern
read here
chunk size should be
only 16, 32
use bitwise for multiply
and design chunk block with flyweight
use chunk culling
most best way optimize
is just use profiler
small lagoon
My chunks are of size 128x128x128 (for large chunks), and I have 1.000 of them, ...
Are you combining your mesh in one ? I never done Voxel, but I was under the impression that you only need a finite amount of mesh to generate a terrain which you do not combine.
median briar
Are you combining your mesh in one ? I never done Voxel, but I was under the imp...
Nope. Each chunk has their own mesh. If this hadn't been the case, I could strip every chunk from any references to GameObjects or whatsoever and put every chunk into true multithreading through the Job system, but it doesn't accept reference types.
The reason why every chunk absolutely needs to contain its own mesh is because unloading (and also reloading) it is much faster then, as you don't have to do computations on a large mesh with millions of triangles and vertices as to combine or split them
small lagoon
Nope. Each chunk has their own mesh. If this hadn't been the case, I could strip...
I mean, each block.
median briar
Oh, nonono.
small lagoon
That must be another method then
median briar
Voxels are (for now) just imaginary points by which the algorithm constructs a mesh for each chunk.
small lagoon
Maybe that was cube marching I was referring
median briar
Could be. Cube marching is very similar to Dual Contouring.
The only difference in the result is that Dual Contouring retains sharp edges, which, if you ask me, is pretty significant.
Nobody wants a weird blobby fat cube, sharp edges are attractive.
Check out how, independent of rotation, position or scale, the objects are meshed in fidelity of their true form
Although we still work with a cubic grid of voxels
small lagoon
Nobody wants a weird blobby fat cube, sharp edges are attractive.
I mean, this is what a lot of people are trying to do.
Cubic aesthetic
median briar
xD
hybrid fog
Not sure if you care to chat about it, but I also recently began work on a voxel engine. I just got block breaking and building implemented today, but I have noise and world generation offloaded to the GPU and chunk loading multithreaded. I'm curious to see how far you've progressed? I'm just using plain 1m bloxels, but I'm going to add a few more block model types soon.
hybrid fog
Also, Христос Воскресе
hybrid fog
@median briar
median briar
Not sure if you care to chat about it, but I also recently began work on a voxel...
How did you multithread the chunk loading?
Without having to rely on the Unity API?
I suppose you're not using GameObjects to split the mesh? Tell me more ^^
And Воистину воскересе :)
@hybrid fog
hybrid fog
How did you multithread the chunk loading?
My pipeline is as such, with a compute shader I generate density data from a noise shader library, and another compute shader converts the density data into an array of block IDs, and then I have a job to create the mesh. Although, I think I could probably do more to optimize, I really just want to move on to more interesting aspects of development, so I'm leaving it as-is.
So
Compute shader noise density -> compute shader block IDs -> mesh generation job
And when I generate a chunk I obviously pass the chunk position to orient the noise sampling and stuff
hybrid fog
Without having to rely on the Unity API?
So I never have to split a mesh, I'm not sure why I'd ever need to
Were you trying to generate massive samples/meshes in one go? Mine takes small bites
median briar
I see!
I'm using a single compute to calculate the meshing algorithm, the density data comes from the compute too through the inbuilt HLSL "noise()" func and a uniform grid for manipulation. However, a part of the algorithm has to be execute serially, which I have to improve somehow. That then is sent to the corresponding calling chunk and set to the mesh data.
The reason why you'd want to split your meshes into chunk is to load and unload them easily without having to cut and combine meshes whenever the player moves further away for example
I don't want to release too much of my design (yet xd), but I think I'm pretty unique in deciding to go for a two-engine model: there is a DC model and a grid model. The Dual Contouring model uses mathematical data to construct a smooth and beautiful landscape, while the grid model is used to manipulate this landscape. You have the best out of both worlds then: easy and fun building with a uniform grid and complex and beautiful features with a mathematical model and some prop gameobject procedurally placed here and there.
By the way, I allowed myself to check out your wordpress. I'm really impressed by the concept of Stardeep, it sounds definitely fun and full of potential! I myself enjoy KSP a lot and am bugged by the many times you just.. don't know what to do. There's very little "mission" in the game
Btw, how scalable is your current voxel engine?
As in, how many voxels/how small voxels can you get before it starts to lag?
hybrid fog
As in, how many voxels/how small voxels can you get before it starts to lag?
Let me check rq. Specs are Ryzen 5, Radeon RX 570, 2 x 8gb RAM.
Each chunk is 10 x 10 currently.
- 8000 chunks 46-50 fps
- 27,000 chunks 39-50 fps
- 125,000 chunks 3-20 fps ( hovers around 12 on average)
Honestly, that stress test makes me even more confident that what I want can be achieved, which is octree LOD terrain with a virtually infinite render distance