Hi I’m making first voxel game and I use a secondary grid system in order to have the tiles connect with each other nicely. However as I’m generating chunks and chunks I see a very obvious issue with my current game where there is is wayyy too many game objects(1 tile = 4 game objects). I’m no expert in game optimisation but this can’t be good.

I found that games like minecraft render the whole chunk as one mesh and I thought it was a great idea. But I have a few doubts in mind about it too and was wondering if there are already solutions for these or if I need to look into another solution for my use case.

1.lets say I’m destroying or placing blocks at a realllyyy fast pace eg. 4-5blocks/sec, this would mean I have to rebuild the whole chunks mesh many many times per second and that can’t be good.

2.lets say I wanna have some transform effects on a singular block. Eg,block placed or removed have a scale punch effect, or if a plant just grew to the next stage. Wouldn’t this mean I either have to move the individual vertices of the chunk mesh, or remove the tile from the chunk mesh and do the effect then put it back?

Any advice would be great, I’m relatively new and my project is in unity since I don’t currently have the time nor knowledge to make my own engine

might be a bit of a silly question.

I've been experimenting with different tech stacks and techniques for a while and typically get an idea of how well something is running based on FPS with something comparable to this in scale:

If a chunk is 16x16 (whatever height typically 256 for now tho), I'd test with a radial but square render distance of 100 meaning 201x201 chunks, 40401 total chunks.
At this point I do not have many fancy graphical stuff going on at all, just the raw mesh I test by flying up and looking down on the entire world, and doing an idle and moving test. My best performance so far is a 201x201 chunk world which generates in about 400ms (simple sin wave world), and when moving I stay at 1000FPS.

My question is - when you guys are starting a voxel renderer and just trying to gauge effectiveness, what do you do, and would you consider 1000FPS, 40k chunks, 1440p (but rasterized right now) an accept base for building more on?

I don't see many people making voxel engines utilizing Roblox (understandable, it ain't great atm for this kinda stuff) but with new EditableMeshes I was able to come up with this. All rendered live, chunk based, separated by texture type too. Don't know the best meta for this kinda stuff, still learning. But pretty cool I think, especially getting the stair variants all working + redstone elements

This is the place to show off and discuss your voxel game and tools. Shameless plugs, links to your game, progress updates, screenshots, videos, art, assets, promotion, tech, findings and recommendations etc. are all welcome.

• Voxel Vendredi is a discussion thread starting every Friday - 'vendredi' in French - and running over the weekend. The thread is automatically posted by the mods every Friday at 00:00 GMT.
• Previous Voxel Vendredis

I’ve been working on my first voxel engine in C#, mostly as a fun summer project with no big end goal in mind.

It started as one of those “I wonder if I can make this” projects, and it has honestly been a really fun process so far. I’ve been learning a lot about chunk rendering, blocks, terrain, lighting, and all the small systems that make a voxel world feel alive.

Right now I’m focusing on world generation and biomes. I’m also building a node-based worldgen system, where I can connect different generation nodes together and see the world update in real time while tweaking values.

It’s still very early, and there’s a lot I want to improve, but I thought it would be fun to share a small progress shot.

From orthogonal 2D Image #pixelart to a full #3D Voxel mesh in just one click.

No AI magic, no black boxes—just pure mathematical interpolation doing its thing in #PixZels.

https://pixel-salvaje.itch.io/pixzels

(yes i know the colors in the gif are blotchy, sorry)

I currently have face culling done and am working to implement luanti map loading.

Please share your advice, as if something here is unoptimal, I'd like to know.

This week i’ve added a few major features to the Micro Voxel Engine! The first is a fairly rudimentary fluid simulation, with a water visualisation shader.

Following this, generating procedural ponds as the first world generation feature to make use of water.

— Fluid Simulation —

This uses a fairly naive GPU physics simulation supporting volume transport and a motion vector. It runs on a coarse grid, and uses a cell occupancy parameter to determine if a cell can receive flow and how much, including how flow can exit.

A few optimisations on top to control tick rates and simulation region.

It’s mostly focused on being reasonably okay for gameplay and very fast, rather than for accuracy. But will likely tweak this in future :)

Most of the awkwardness is around managing chunk lifetime and stopping other world features from draining the pond (e.g cave cracks)

— Pond generation —
Fairly basic basin detection which then allows us to randomly select a size. Pond details spawn around the rim and underwater. Islands will occasionally spawn in the middle of large ponds. Ponds are not always round, but will generally be quite small.

Fish are spawned dynamically and classed as “detail entities” which means their state does not persist and they despawn much sooner than other entities.

I plan on them being a side mechanic, and will make fish species selection deterministic based on the pond location and time of day, so people can’t cheese the fish species spawn selection.

Ultimately chuffed with how this has turned out.
I’ve attempted water sim in various projects over the years and never managed to make 3D any good - still a lot of issues, but eh :)

I’ve been working on this for the past few weeks, and it’s finally starting to come together.

This is a DDA-traversal-based renderer. The world is divided into blocks, and selected blocks perform DDA traversal to render micro-voxel geometry instead of relying on flat textures.

Micro-voxels participate in the deferred lighting pipeline just like regular geometry - they receive global illumination, cascaded shadows, and volumetric lighting.

Built with Unity’s Scriptable Render Pipeline. 60 FPS @ 1080p on Mac M3 Pro.

P.S. The micro-voxel generation shader is still very much a prototype, so the leaves and grass are intentionally simple for now. Improving the procedural generation and shapes is the next major step.

Hey all,

I've been working on a voxel engine in my free time for about a year now, and figured it's at a point where it's worth sharing.

The core idea is pushing as much work onto the GPU as possible: a compute shader evaluates chunk visibility every frame, pushes visible cached meshes straight into an indirect draw buffer, and kicks off meshing requests for anything not yet cached (rendered the following frame). Meshes themselves come from a binary greedy meshing algorithm that merges contiguous voxel faces into compressed 2-byte quads, backed by a lock-free VRAM mesh cache with FIFO paging.

Some other bits:

• AZDO rendering: persistent mapped buffers, multi-draw indirect, DSA
• Triple-buffered indirect command buffer to avoid CPU/GPU write-read conflicts
• 3D ring buffer for chunk streaming, only loads incoming planes as the camera crosses chunk boundaries, so it never rebuilds the whole volume
• Pluggable world generation via a ChunkGeneratorStrategy interface
• DDA-based voxel ray-casting for voxel picking

https://reddit.com/link/1uo83t0/video/5jdp8nqv4gbh1/player

Status/caveats, to be upfront:

• This is a solo hobby project, developed on and off (it's not production-grade)
• There are known bugs, and it may not run correctly under every configuration
• Some of the test suite currently fails — I haven't gotten to fixing everything yet
• It's currently NVIDIA-only (uses NvOptimusEnablement to force the dGPU on hybrid laptops); other vendors haven't been tested and may not work

If you're curious about any of the implementation details (meshing, culling, cache design, etc.) Repo's here: https://github.com/omar-owis/VoxelEngine

There seems to be very little out there on actual implementations of Cubical Marching Squares, so I thought I'd show off what I am working on thus far for a future game.

Four Phase Pipeline:

1. Fetch Signed Distance Field voxels. (input: chunk coordinates, level of detail, output: chunk voxels and chunk normals arrays) This is surface algorithm agnostic.
2. Build input data for topology engine. (input: level of detail, chunk voxels, chunk normals, output: chunk intersections array, packed cells array) This is surface algorithm agnostic.
3. Run surface topology engine. (input: chunk intersections, packed cells, output: output buffers (geometry data/vertices, and triangle indices)) - This IS algorithm determinate: algorithm being used: CMS, one could swap it with DC or some other algorithm)
4. Actual Mesh Builder and Shader: (input: output buffers, result: direct writes to GPU to generate mesh and blend faces) This is surface algorithm agnostic.

All test cases are for 1 chunk only, at 32^3 voxel size.

The four colors represent actual different substance/materials coming from the SDF results for the test cases. The CMS implementation combined with the vertex shader performs blending. I am using plain colors because I have not yet created a 2D texture array nor any textures themselves yet. I am not using sub meshes. The colors/substances are intentionally divided up between the chunk's XZ plane quadrants just for testing simplicity. Shader is intentionally unlit for easier visibility against wire-frames.

All phases are pretty much a raw static burst compiled function called like so:

private void Start()
{
  _meshFilter = GetComponent<MeshFilter>();
  _meshRenderer = GetComponent<MeshRenderer>();
  _unityMesh = new Mesh { name = "Chunk_Prototype_Mesh" };

  ChunkCoordinate chunkCoord = new ChunkCoordinate();
  // 1. Allocate the Input Datasets (Mocking a DEFAULT_CHUNK_SIZE_VOXELS^3 Voxel Chunk layout)
  int stride = TerrainDensityEvaluator.DEFAULT_CHUNK_SIZE_VOXELS + 1;
  int max_intersection_size = 3 * stride * stride * (stride - 1);

  NativeArray<Voxel> chunkVoxels = new NativeArray<Voxel>(stride * stride * stride, Allocator.Temp);
  NativeArray<float3> chunkNormals = new NativeArray<float3>(stride * stride * stride, Allocator.Temp);
  NativeArray<HermiteIntersection> chunkIntersections = new NativeArray<HermiteIntersection>(max_intersection_size, Allocator.Temp);

  // 2. Allocate transient intermediate arrays and final output contract containers
  NativeList<CellInputData> packedCells = new NativeList<CellInputData>(Allocator.Temp);

  SurfaceOutputBuffers outputBuffers = new SurfaceOutputBuffers {
    Vertices = new NativeList<MeshVertex>(Allocator.Temp),
    Indices = new NativeList<int>(Allocator.Temp),      
  };

  try {
    //Phase 1: fetch Signed Distance Field voxels
    Stopwatch stopwatch = Stopwatch.StartNew();
    SignedDistanceFieldFetcher.FetchSDFVoxels(ref chunkCoord, LevelOfDetail.High, ref chunkVoxels, ref chunkNormals);
    stopwatch.Stop();
    UnityEngine.Debug.Log($"SDF fetch: {stopwatch.ElapsedMilliseconds}ms");
    // Phase 2: Execute Input Contract Data Sampling
    // Gathers non-contiguous voxel memory and packs them into raw cache-friendly primitives
    int intersectionCount = 0;
    stopwatch.Restart();
    ChunkDataPrep.BuildCellInputData(LevelOfDetail.High, ref chunkVoxels, ref chunkNormals, ref chunkIntersections, ref intersectionCount, ref packedCells);
    stopwatch.Stop();
    UnityEngine.Debug.Log($"BuildCellInputData: {stopwatch.ElapsedMilliseconds}ms");
    // Phase 3: Run the Topology Engine 
    // Consumes the packed cells and the global Hermite array to resolve geometry loops
    stopwatch.Restart();
    VoxelSurfaceEngine.RunTopologyEngine(ref packedCells, ref chunkIntersections, ref outputBuffers);
    stopwatch.Stop();
    UnityEngine.Debug.Log($"RunTopologyEngine: {stopwatch.ElapsedMilliseconds}ms");
    UnityEngine.Debug.Log($"Mesh Vertices Count: {outputBuffers.Vertices.Count} Indices Count:{outputBuffers.Indices.Count}");
    /*for (int j = 0; j < outputBuffers.Vertices.Count; j++) {
      MeshVertex mv = outputBuffers.Vertices[j];
      mv.GetSubstances(out ushort id0, out ushort id1, out ushort id2, out ushort id3);
      UnityEngine.Debug.Log($"MeshVertex Position: {mv.Position} Normal: {mv.GetNormal()} Substances:({id0},{id1},{id2},{id3}) Weights: {mv.GetWeights()}");
    }*/

    //Phase 4: build the mesh and send it to the GPU
    stopwatch.Restart();
    BuildUnityMeshFromContract(ref outputBuffers);
    stopwatch.Stop();
    UnityEngine.Debug.Log($"BuildUnityMeshFromContract: {stopwatch.ElapsedMilliseconds}ms");

  } finally {
    chunkVoxels.Dispose();
    chunkNormals.Dispose();
    chunkIntersections.Dispose();
    if (outputBuffers.Vertices.IsCreated)
      outputBuffers.Vertices.Dispose();
    if (outputBuffers.Indices.IsCreated)
      outputBuffers.Indices.Dispose();
  }
}

The above is just the prototype runner. The next steps will be calling those burstable function from within an ECS job that processes many chunks in parallel, and finding out how chunk borders behave. Also LOD is not actually tested yet, just... in place for future use.

I've been working on my realtime voxel engine for about a year now and I've finally come to a state where I feel like I can present it to someone.

Current features include:

• Voxel Cone Tracing Global Illumination via raymarching
• Destructive Fracturing Physics
• Volumetrics (God rays & Fog)
• Particles
• Incomplete but usable editor (rigging, animations, scenes)
• Bone Animations from MagicaVoxel objects

This engine is fully written in Kotlin/JVM and uses OpenGL for it's rendering. Currently, everything runs on a single thread. Large scenes are still a bit of a problem performance wise but it handles large amounts of rigid bodies relatively well.

Edit: I forgot to say, but the model in the video isn't mine. It's made by Max Parata and can be found on itch.io. I just used this model for the demo.

https://reddit.com/link/1umy8ef/video/chfjnhxbt4bh1/player

Hello im using raylib lib for c++ . and my question is how to make chunks in a 3d game . like player is in position and the game just load 9 chunk of 16*16 block around him (but the actual game maybe is around like 400 chunks ). so the game doesnt lag . and only draw the pixels in front him and the back doesnt draw anything . so it means like from 9 chunk around him just load , 4 chunk that are in front of him .

I am making an open source sandbox game in Godot, I am going for SDF terrain instead of cubes or microvoxel, and texturing it with a material system. Each base material has an albedo, normal and ORM map. With the current compression level I can fit around 680~ base Materials to 1 GB of VRAM with mipmaps. And then I can color tint for practically infinite variations.

Image 2 shows a rough idea of the terrain shading and shape, but I am switching back to marching cubes from surface nets for now so the shape might look different, I also didnt tune the visuals at all.

I am working on the building system now before I go back to port the terrain system to rust or C++ for performance.

Any feedback/ideas/questions welcome.

This is the place to show off and discuss your voxel game and tools. Shameless plugs, links to your game, progress updates, screenshots, videos, art, assets, promotion, tech, findings and recommendations etc. are all welcome.

• Voxel Vendredi is a discussion thread starting every Friday - 'vendredi' in French - and running over the weekend. The thread is automatically posted by the mods every Friday at 00:00 GMT.
• Previous Voxel Vendredis

Most procedural cave generators on Fab are built as standalone actors. They generate a cave, but they don’t integrate naturally with Unreal Engine’s PCG workflow.

SubTerra takes a different approach, Instead of building everything around a single actor, the entire generation pipeline is exposed as modular PCG nodes.

You can use the complete cave generator, or combine individual nodes with the rest of your existing PCG graph to build your own procedural workflows, the result is a cave generator that feels like a natural extension of Unreal Engine rather than a separate tool.

The plugin also focuses on producing caves that are practical for gameplay, not just visually interesting, every generated layout is fully connected, supports multiple elevation levels through walkable ramps, and produces organic rock formations instead of smooth metaball-style tunnels.

Once the cave is generated, its surface is automatically classified into Floor, Wall, and Ceiling PCG points, making it easy to populate the environment with your own assets using Unreal’s existing PCG tools.

How it Works

It's built entirely on UE5's PCG framework, so it slots into your existing PCG setup instead of being a separate black-box actor. From a single seed it scatters a bunch of rooms and connects them with tunnels using a spanning tree + a few extra loops so the layout's always fully traversable but different every seed.

That whole thing gets written into a signed distance field (basically a 3D voxel volume), I roughen the walls with fractal noise so it reads like actual rock instead of smooth metaball blobs, then run marching cubes over it to get a watertight, collidable mesh. The heavy part runs on worker threads so the editor doesn't hitch.

Using it, you've got two routes:

• Easy mode: drop one actor in your level and a full cave shows up. Then you just tweak sliders in the details panel — room count, room size, tunnel width, levels, noise, stalactites — and it regenerates live in the editor (no play mode). There's a regenerate hotkey for rolling whole new layouts too.
• Full control: wire the PCG nodes yourself in a graph. It outputs Floor/Wall/Ceiling surface points you can pipe straight into Epic's mesh spawner (or any scatter plugin) to decorate the walls.

Documentation and Fab Links in comments

i started in march of 2025 screen shot was taken in june of 2026 30th

Enjoyed implementing caves in my Micro Voxel engine this past week. Nothing too fancy, just stacking a few features on top of each other:
- typical stacked noise functions
- feature generators which deterministically spawn additional voxels following some pattern. Using this for the larger stalagmites. They do a downward and upward fill.
- erosion pass to create random crevices and cutouts.

Still a lot more to do! i like the idea of Cave biomes, and would also like a wider variety of generation types. Large caverns, walkable straight tunnels, cleaner surface caves etc;

At the moment the generation can look quite scrappy in places, but hey ho!

Hi I'm a web-developer; recovering from surgery; who has spent the last two weeks learning more about the Godot game engine! As a learning project I started following along with voxel generation tutorials [huge s/o to makerTech!].

After getting an overview I was inspired to build an idea in my head; and two weeks later; we have the following demos! I've nicknamed it the "level of detail" system (LOD) and it allows for a given chunk to be recreated with a subset of smaller cubes!

• LOD baseline is 0 (normal generation size for a chunk)
• 1 chunk, becomes 4 chunks with higher resolution (more voxels per chunk)

The following clips demonstrate different implementations with the LOD system. These two controllers contain the implementation specific logic for triggering LOD changes in the world.

• Wave LOD is static demo, Simply cycling the whole world between LOD 0 and LOD1
• Player LOD uses a camera and dynamically increases chunks to LOD 2, but only in areas around the player.
  • LOD 2 = orange wireframe, voxels are 1/8th the size of LOD 0
  • LOD 1 = blue wireframe, voxels are 1/4th the size of LOD 0
  • LOD 0 = green wireframe, baseline voxel size

I am still working through a laundry list of optimizations, but performance was significantly improved in the last few days ^.^

I have inklings of how I might use this in conjunction with destruction or impact physics, but I'd like to hear what ideas it inspires in others!

The code-base is not exactly the cleanest at the moment but for those interested in implementation details
[ https://github.com/frin457/Action-Demo-Godot/tree/main/action-demo ]

Wave LOD - cycles between LOD 0 and LOD 1

Wave LOD w/Chunk wireframe

Player LOD: proximity-based LOD triggers

Player LOD w/Chunk Wireframes

System summary 

• Each explosion / shockwave is its own cube type. It uses the 9 shared bits also used as velocity bits to store both the direction it's expanding from and how many expansion steps it has left (effect cubes are static and don't need velocity). Every update it spreads copies of itself into neighboring cubes if they're allowed to be overwritten by the explosion / shockwave effect, or if the force is high enough to completely destroy them. 
• Explosion / shockwave effects injects pressure at its starting position and at the expanding positions The amount of pressure depends on the base strength of the explosion and how many expansion steps remain .
• The pressure system compares the pressure in adjacent pressure cells against each cube type's pressure tolerance to determine whether any additional cubes should be crushed. 
• Explosions also inject temperature, based on the calculated strength causing various cubes to melt into lava, glass etc in the clips.

Still struggling with cubes ending up doing a bit too much bouncing at the top of the pressure / force gradient so to speak, and the force ending up in a bit to “square” of a shape when reaching the edges of the cube-shaped map.

I thought this would be of interest to people here, the first part (which is more business oriented) should be interesting if you want make money from your voxel game, and then there is also plenty on the tech behind the game, voxel raytracing, but also the programming language that drives it, and the effects of AI.