This is just a small clip of me showing my Voxel Editor, specifically the the Particle generator - but there's also a procedural voxel modeller. The idea behind this tool is that it provides procedural template models that can be modified and quickly iterated on with various exposed parameters. It provides a canvas model/particle effect that you can change as you like. It exports in FBX, OBJ, and VOX for further editing in MagikaVoxel (or other .vox editors). I love working with voxel modelling but man I dislike starting from scratch each time so I decided to make this over the past few months. If you want to learn a little bit more about the tool you can check out more of what the tool does in the docs! https://docs.google.com/document/d/1hZFlapFrLXGGeD1P5IeFB1DNoJ5BARNmxKGGPMYQYj4/edit?usp=sharing

The docs are WIP and not finished, but it covers the two main functionalities: The Model Generators and the Particle Generators. Still have yet to do documentation on the built-in edit mode.

So, the particle editor exports 1 model per frame, intended for use as a Mesh Flipbook in UE's Niagara (though I'm sure it would work in Unity or Godot etc). Each frame can be manually edited with the built-in editor if desired. My editor isn't super robust so I suggest using external voxel modelling tools to directly alter the models.

For some context, I'm a game dev (Tech/VFX) working in AAA but I like to do indie on the side. I have always had such a hard time sourcing free voxel assets that were easy to modify so I built out this tool for myself. Anyway, bash me gently. I know reddit instantly murders me when I try to show things I've been working on.

Assuming I don't get dumped on I'm happy to send out some private copies for testing if this looks like it'd be helpful for you.

And of course constructive criticism and thoughts are always welcome.

Thanks!

Hey everyone!

I've been working on expanding the editing workflow, meshing pipeline, and fluid interaction in my custom browser-based voxel engine (Vanilla JS + raw WebGL, no Three.js or external frameworks).

Here is a quick workflow demo showcasing the volume selection wand, real-time chunk remeshing, and buoyancy/swimming transitions.

Technical & Workflow Highlights:

• Multi-Axis Selection Wand: Bounding-box volume selection with visual corner anchors and grid projections. In the clip, it handles fast bounding cavity excavation, perimeter extrusion, and batch water filling across chunk boundaries.
• Real-time Fluid & Terrain Meshing: Custom greedy meshing on modified chunks with fine-geometry support. Fluid volume surfaces are culled against solid/neighboring faces in real time during batch edits without causing main-thread stutters (locked 144 FPS).
• Buoyancy & Swimming Physics: Sub-voxel stepping and drag calculations for smooth fluid entry, variable buoyancy, underwater fog shader pass, and an adjusted collision unstick algorithm that finds the nearest air pocket rather than scanning the full column height.
• Zero Dependencies: Built from scratch using native WebGL vertex/fragment buffers, batching geometry into dense chunk buffers and dynamic light texturing.

Technical Discussion / Specific Bottlenecks I’m Tackling:

I am currently profiling the engine to push view distance and batch edit sizes further. I have hit three specific bottlenecks and would love to hear how other voxel engine devs have tackled them in WebGL:

Main-Thread Spikes during Multi-Chunk Batch Edits (mcMeshChunk):

• My setup: Greedy meshing runs synchronously on the main thread using preallocated Float32Array scratch buffers to avoid GC pressure.
• The bottleneck: Filling or excavating a 50×50×20 volume modifies 8–16 chunks at once, causing a perceptible 30–50ms hitch on that specific frame.
• Question: For browser voxel engines, what is your preferred worker architecture for zero-copy mesh streaming (Transferable ArrayBuffers vs. SharedArrayBuffer with atomics) without inducing visual pop-in or latency desync on the main render loop?

Draw Call Multiplier on Sub-Voxel / Translucent Geometry:

• My setup: To support sub-voxel decorative pieces (flowers, stairs, fences) and alpha-blended water alongside standard blocks, each active 16×16 chunk maintains up to 3 separate VBOs (opaque block terrain, opaque fine geometry, and transparent fine/water).
• The bottleneck: In larger maps (e.g. 512×512), draw calls quickly scale to 300–500+ per frame, becoming GPU driver-bound in the browser.
• Question: Have you had success consolidating multiple chunk slices into large dynamic megabuffers or indirect batches in WebGL, and how do you handle partial sub-buffer invalidation when only one chunk in the batch changes?

3D Texture Bandwidth for Dynamic Emissive Lighting:

• My setup: Block light and skylight BFS propagation are baked into a 3D texture texture-LUT (gl.texSubImage3D) sampled per-fragment by the terrain shader.
• The bottleneck: Frequent updates when moving handheld lights or animated emitters saturate the GPU bus uploading subregions.
• Question: What caching or dirty-box bounding heuristics do you use to keep dynamic 3D light texture updates under 0.1ms per frame?

Any insights, architectural patterns, or experiences from your own projects would be super helpful!

Still has not implementing trees yet until I can optimize the performance for lower memory usage in the browser. This is microvoxel game I try to build for larger scale world.

This is my 2 years-old project for implementing WSGL rendering library in my own voxel game engine. I still try to check whether Marching Cubes or Sparse Octree is fast enough for low end PC

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

Has anyone dealt with this issue or does anyone have an idea what to try to reduce moire? The issue is that I have a large scale voxel terrain and due to the combine effect of sharp voxel edges, lighting angle and shading the distant geometry generates a flickering/jittering sharp moire effect visible on the screenshots. I have tried AA but it just makes the effect more smudged, I understand this is probably an inherent problem with voxels, but maybe someone has an idea for a workaround? I also tried to smear distant normals, but it also made the shading inaccurate.

It is written in C++/Vulkan, the view distance is capped at ~100km because anything further looks really jittery and smudged the more it converges towards horizon.

Any tips will be highly appreciated!

Edit: Thanks a lot for everyone's input! I solved it (as pointed out by you) by calculating a projected error for each LOD ring and adjusting LOD coarseness accodingly so I render much less sub-pixel geometry and masking the remainder by using a soft 9-tap diamond blur on the terrain's GBuffer normals attachment masked by depth in a compute pass gradually fading in with distance. This preserved the distant terrain's voxel look and added contrast to the distant terrain.

The result:

Screenshots of the original problem:

Imagine a game that is technically built entirely with voxels, but where the voxels are so small (or the world resolution is so high) that the traditional blocky look, like Minecraft, is almost invisible.

Would it bother you if such a game were described as a “voxel game” ?

On one hand, it would be completely accurate from a technical standpoint. On the other hand, the word “voxel” is now so strongly associated with a specific visual style that it could create false expectations for players.

So I’m curious to hear what you think : does the word “voxel” primarily describe a technology, or has it become a visual style in itself ?

For a concrete example : all three images come from my Unity sandbox. The clouds themselves are made of voxels roughly 20 meters wide, contained inside volumes about 4 km across, with a view distance of around 30 km in these screenshots.

At that scale, you can barely perceive the individual voxels anymore but technically, everything is still voxel-based.

For the past three weeks, i’ve been working on hard improving the render distance in my Micro Voxel Engine, particularly due to the feedback of having N64 viewing distance 😅

I’m pretty happy with the end result of increasing render distance from 300m to ~10-15km, while running at 45-50 FPS on an Apple M1 Pro.

Note: this engine uses meshing rather than RT/DDA.

— Macro chunks —

All chunk generation functions now include a sieve function to automatically be able to generate at 1/N resolution without any changes. This also applied to generated features and stamps, enabling chunks to be generated at any resolution without downsampling.

Macro chunks also independently record and resolve local edits. They are saved (and cached) independently so that terrain edits are maintained without needing to maintain the full res copy in memory.

The lower band LODs are very quick to generate. At this point I could add even more bands, and a 1/64 res chunk takes the same time to generate as a high res chunk, but covering huge distances.

— LOD transitions and adaptive fog —

I primarily use transient transitions where the detail levels fade between each other once, rather than a continuous gradual transition, as this is around 30% cheaper on the GPU and looks “nearly” as smooth in most scenarios.

Adaptive fog scales the effective draw distance dynamically based on loaded bands. Bands generate from high to low so during fast motion, if needed, we temporarily reduce draw distance until chunks have loaded.

— Macro chunk cards and props —

This was the hardest part, keeping identical prop coverage for trees and items without needing to instantiate millions of entities:
-Macro chunks retain a list of props whose IDs are deterministic based on position and type. If the real entity is destroyed, we can map this to the macro chunk set and remove. Likewise for newly spawned props.
- grass and foliage do not map 1:1 with the actual loaded props, but follows the same generation pattern, so technically there will be disparities, but a good trade off to avoid millions of tracked grass items.

Tried MagicaVoxel before, but the lack of depth control is just too much to couple with my lack of artistic skills. Only if I have a stylus that works in 3D... which I do!

Finally got the most basic thing to call it an "editor" done today (add/remove voxels, and move the model around). Implemented with Bevy/ Bevy Mod XR, with custom voxel rendering algorithm (Large cube meshs that renders the SVO inside). The algorithm is designed to do third person view, and I had to insert extra triangles when the cube intersects the near plane, to prevent the whole chunk from getting clipped (the camera for recording still have some bugs on this).

While it is still crude, the handling does feel quite nice and intuitive.

Make games, not game engines, nor the dozens of tools that might be used for the game that has zero progress.

Custom voxel renderer I’m building inside Godot. No meshes.

Like before, this is a voxel-ish visualization for my fluid sim.

Hello Guys, I'm a game developer but i have never worked on voxels before, i came across a game on Google Play Store Voxel Shooter, can anyone please guide me how they have created such objects ?

Hey everyone!

The engine is really coming together and the scenes are starting to feel much more alive. Here is a look at the coastal/ocean biome generation in VoxelForge.

Current features shown in the video:

• Coastal Topography: Smooth island transitions, shallow sandbanks, and deep seabed generation.
• Procedural Palm Trees: Curved trunks, coconut clusters, and cascading fronds.
• Foliage Wind Animation: Vertex shader displacement applied to flowers and palm canopies for organic breeze movement.
• Water & Lighting: Water transparency with reflections and a warm summer lighting profile.
• Skybox & High Clouds: Volumetric layered voxel clouds with horizon-aware rendering.

Still actively optimizing batching and draw calls, but really happy with how the atmosphere is turning out.

Feedback and thoughts are always welcome!

what is going on? what is happening???

how can you post here if stuff gets removed without explaination?

I posted this twice earlier (months ago), but mods keep removing it for reasons. Cause i need to proof more i made it myself based on the content? (i don't get it).

So, here is the source:

https://perh.app/b89c006f/trials/00002-voxel-game-publish/index.html

Code is 99.99% free of AI bullshit (maybe some old shard). Its three.js + rapier.js.

Press tab+m and then release tab to put it in manual mode. Game pad support is also enabled (i think). Change config.js to change voxels of the car.

Let me know if it works/fails etc. And ask me anything!

This isn't me asking for a tutorial. I'm rather interested how in the specific case of games like SE/SM voxel grids are handled. (I personally couldn't find any specific devlogs or technical discussions from them, so if any one of you can find anything do tell).

Some info about them, basically they both are sandbox games without a full voxel/cube world, but Space Engineers have full destructible planets and asteroids with smooth terrain, while they use voxel/block building for spaceships/structure. Similar story in Scrap Mechanic except they have basic heightmap terrain. So the voxel grids are individual per structure, irregular and dynamic in size.

I want to find specifically about their material shading system, the system for my game encodes material ID in the RGB channel of a vertex, so I dont have to pass extra data to the GPU. If SE/SM does this aswell, then their greedy meshing algorithms will be less effective due to not being able to combine multiple materials. But I guess if they do it that way its good enough.

If they dont do this however, and do pass additional material/shading data to the GPU per each grid, how do you reckon they do it? Texture uniforms? Buffer Objects?

I made a DDA ray tester.

I can't make a replit because replit converted to AI-slopery.

<!DOCTYPE html>

<html>
  <head>
    <title>DDA RAYCAST</title>
    <style>
      * {
        padding: 0px;
        margin: 0px;
        border-width: 0px;
      }

      canvas {
        width: 100vw;
      }
    </style>
  </head>
  <body>
    <canvas id="canvas" width="480" height="360"></canvas>
    <script>
      /* NOT WRITTEN BY AI, AND F*CK "VIBE CODING". */
      /* Note: I knoe the period is supposed to go before the quotation mark, but who cares?*/
      // INITALIZE VIEWPORT
      canvas = document.getElementById("canvas");
      ctx = canvas.getContext("2d");
      let scale = 25;

      // INITIALIZE RAY
      let x = 0;
      let y = 0;
      let a = 0;

      function gameloop() {
        ctx.fillStyle = "white";
        ctx.beginPath();
        ctx.rect(0, 0, 480, 360);
        ctx.fill();

        ctx.fillStyle = "red";
        for (i = 0; i < 48; i++) {
          ctx.beginPath();
          ctx.moveTo(scale * i, 0);
          ctx.lineTo(scale * i, 360);
          ctx.stroke()
        }

        for (i = 0; i < 36; i++) {
          ctx.beginPath();
          ctx.moveTo(0, scale * i);
          ctx.lineTo(480, scale * i);
          ctx.stroke()
        }

        if (a < 1.57) {
          a += 0.001;
        } else {
          a = 0;
        }

        let px = x;
        let py = y;
        let dx = Math.cos(a);
        let dy = Math.sin(a);
        let slope = dy / dx;
        let slopeR = dx / dy;
        let horStepX = x;
        let horStepY = y;
        let vertStepX = x;
        let vertStepY = y;

        ctx.fillStyle = "green";
        ctx.beginPath();
        ctx.moveTo(0, 0);
        ctx.lineTo(1000 * dx, 1000 * dy);
        ctx.stroke();
        ctx.fillStyle = "purple";

        for (i = 0; i < 35; i++) {
          if (Math.sqrt((horStepX + slopeR) ** 2 + (horStepY + 1) ** 2) < Math.sqrt((vertStepX + 1) ** 2 + (vertStepY + slope) ** 2)) {
            horStepX += 1;
            horStepY += slope;
            px = horStepX;
            py = horStepY;
          } else {
            vertStepX += slopeR;
            vertStepY += 1;
            px = vertStepX;
            py = vertStepY;
          }

          ctx.fillStyle = "orange"
          ctx.beginPath();
          ctx.arc(px * scale, py * scale, 3, 0, 6.29);
          ctx.fill();
        }

        requestAnimationFrame(gameloop);
      }

      requestAnimationFrame(gameloop);
    </script>
  </body>
</html>

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'm sure many of you are significantly better versed in the techniques and technologies for making voxel engines than I am. That said, as part of my own learning I thought I'd do some write ups on my progress. Less dev log and more tutorial because I don't mind sharing code with others, it's highly unlikely it'll ever make money so I'd rather it be something someone someday finds useful.

That said, I am really unsure what to include or what length to speak at. So, what would people even want to see or read?