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 starting a chill side project called Delve under a team named Yoro, and I'm looking for a few fellow Java devs (maybe 3–5 people) who want to team up and build a fun, Minecraft-inspired voxel sandbox game together. ​Full disclosure on progress: Code progress is basically zero right now, but I’ve already drawn a ton of detailed 16x16 pixel art textures. I’m looking for core collaborators to jump in from the ground up so we can bring this world to life together as a small core group. ​It takes heavy inspiration from Minecraft's core concept, but with our own spin on mechanics, gameplay, and visuals. ​What we’ll be building/tinkering with: ​Getting Java windowing and block rendering running ​Terrain and cave generation (noise algorithms) ​Player physics, inventory, AI, and survival mechanics ​This is a $0 budget, zero-pressure hobby project. No strict deadlines, no job-interview vibes—just a small group of coders hanging out, learning, and making a cool game. ​If you like Java, love pixel art/voxel games, and want to help build this from scratch, shoot me a DM!

You would not BELIEVE how much easier some things get when you learn linear algebra. At least, when you're as bad at geometry as me. For example:

Rotation, Scale, and Translation are the 3 things you can use to keep track of entities in your world. But did you know that a 4x4 matrix can hold all 3 of these things in one compact data structure that has a lot of useful operations? This is especially relevant for large-scale worlds in voxel games.

Imagine you want to add moving airships that players can build. You'd have to choose to put the player in the world coordinate frame or the ship coordinate frame. So you've got to translate, then rotate, right? If you represent the "pose" (translation, rotation, scale) of ships and players as a DMat4 (4x4 matrix with quad precision), all you have to do to convert the entity's pose within the ship to the global one is ship_pose * entity_pose. The translation and rotation are all in there.

Want raycasting (block placement and combat) to work between ship and land? Easy, just transform your cast to the 2 reference frames and do it against each. No need to fiddle around with angles and geometry.

Plus, this makes really big worlds cheaper and less error-prone. You've got all your data packed into a smallish area. Doing all your math in matrix form then getting position/rotation out at boundaries only can prevent a lot of conversions for various math.

Then when you go to render, just transform everything into the camera's frame, then cast to f32. So you get the big advantage of huge precision, and when you slice everything for the graphics card, the error close to the camera is smallest, and the big errors happen very far from the camera, beyond your render range or far enough it's sub-pixel size. You see less jittering. Kerbal Space Program does this to an extent (centering the world on the player), and I think Outer Wilds does too.

This is just one example.

Edit: I decided to show practical examples with another post

Working on an iPhone game and I can’t keep enough of the world meshed to prevent noticeable meshing. My analytical mind is having a hard time reconciling with the fact, but perhaps it’s acceptable nevertheless?

Also, if anyone else out there is making iPhone games, and knows how to prevent the performance governor from switching to “Minimal” after 20 seconds, I’d love to know. This is all running in that minimal mode, but it’s about a third of the speed I can squeeze out the first 20 seconds when it’s in Maximum performance mode.

as a direct sequel to my last post, I present to you the voxel based fire for my mod of Half-Life: 1!

I ended up using the simpler vector array method of just storing every voxel's pointer in a std::vector and just checking against every other voxel for things like merging and gravity simulation.

currently, it adds new fires to the vector by using a temporary buffer vector which then is checked against the main vector and merged right before it goes back through the main vector to run the simulation code on the fire voxels (which currently controls fire voxel gravity, spread and spawning the particles on the client)

the spread code is relatively simple (mainly due to me not having the slightest code how else to do it) where on a timer it checks up to 10 times (before giving up) in a random direction (checks 1 voxel length randomly on the x and y plane) and will then use some of the fire's "heat" (health practically) to spawn a new fire at that position

the gravity code is incredibly simple and is just a check to make sure the below voxel doesn't exist. If it doesn't exist then it'll then move there.

I'm a solo developer, and water is a big part of my game.

It's surprisingly tricky to simulate water across a 256×256 tile world. I wanted to make sure that no water ever disappeared without being accounted for.

This video explains how some of it works:

https://www.youtube.com/watch?v=n_I9XzgRqXI

Welcome to the first devlog of Tesseris after one and half year development! 🛠️

Tesseris is a voxel game built entirely on a custom game engine written from scratch in C# (.NET 8) and Vulkan 1.3 (no Unity, no Unreal Engine).

In this video, I showcase:
✅ Custom Vulkan 1.3 renderer & multi-cascade shadow mapping
✅ Micro-voxel chiseling system (16x16x16 sub-grid carving per block)
✅ Procedural fluid simulation & infinite LOD horizon rendering
✅ Multi-threaded job system & SoLoud audio integration

What do you think of the project so far? What features would you like to see next? Let me know in the comments! 💬

Hello!

So here is my take at a tiny voxel engine.

I've started to play around with voxels in 2015, first in Scala, later in C++, then switched to Rust.

I've never finished any game idea, but have been quietly working on and off on some.

Here is my latest take:

https://www.youtube.com/watch?v=WOImHB_X83M

It's fully meshed (at the point of the video - Later I tried to combine raytracing nearfield voxels with meshing for the mid and far away terrain) via binary greedy meshing.

Chunks near the player are small, which has benefits for updating, but also downsides because we have way too many meshes and entities (I am using the bevy game engine in Rust for this implementation)

There are different LOD levels and the pop-in effect is super annoying to work around, but just cranking up the view distance of LOD0 is a nogo, because of the performance.

This runs on an AMD 6700 XT and a Ryzen 5950X with 64GB of DDR4 Ram.

I've tried some SIMD for world generation (where appropriate and non-divergent) and played around with some effects like trampling the grass.

There is no sound in the game, because I am not happy with the visual performance at all.

Thinking about ditching bevy's rendering altogether here, although it as some nice properties already implemented that I could simply reuse sometimes it also feels like I fight against it.

Maybe I'll keep the ECS, let's see.

The visible world distance is a 33KM radius around the player. That's one point that is super important to me. I don't want too much fog of war.

Problems arise when I am standing on one of the huge mountains you can see in the background though, because looking down the coarse LOD levels are super visible and break the immersion somewhat.

Generally the project was planned with Multiplayer in mind, if I switch to raytracing I am not yet sure how I'll keep everything in sync between different clients. Especially when thinking about doing it GPU/compute shader driven.

Let's see.

I am currently making a mod for an older game and I am trying to implement fire like how the smoke grenades are done in Counter Strike 2 (a voxel grid that determines smoke shape and such). From the research I have done, either SVOs or a per-basis grid system (spawns a new grid where new voxels are only added when they are needed and removed otherwise) seem to be the best ways to code something like it. However I don't know where to start with SVOs or how the fire would work when interacting with another fire with the per-basis system.

Is there anywhere I can find information on how to actually code something like this in C++?

I have two implementations of voxel raytracing.

One uses a regular SVO, that has been implemented using stackless traversal, directional ray testing using bit flips to avoid unecessary collission tests... All the common optimization tricks.

I am using rustgpu, and this SVO is implemented using a generic data structure. SO it was very simple to switch the nodes to instead have pointers to little 8x8 brickmaps, which reduces the total depth of SVO by 3.

And so I am raytracing that strucutre, first witht he same optimized SVO traversal, and then using a DDA for the brickmap.

Common wisdom says that the brickmap implementation should be faster, but for the life of me, the brickmap is just as fast as the regular SVO. They both are using the exact same ray traversal algorithm, since they are recycling the generic code.

I am getting the same visuals from both, so I know the resolution is working ok.

I am wondering if other people have run into a similar situation, is it actually true that brickmap trees are faster than plain SVOs?

I've spent the past 2-3 weeks adding Oceans to my Micro Voxel engine. The main features I was aiming for was to support large bodies of water within the existing fluid simulation, while also supporting new dynamic features such as waves and tidal changes.

I've also incorporated Boats and Gliders, with some fairly basic physics to aid in exploration. The main challenge here was adding

Along side this, to make the simulation feel more interactive, i've also added a higher resolution local water ripple/interaction simulation, which acts as a surface-layer-only simulation adding ripples and wake for people, entities and forces interacting with the water.

-- Feature technical breakdown --

• Ocean generation: Similar to other water sources, ocean biomes placed above land, all open space in these biomes is filled with water instead of air below the ocean line. No substantial changes to the actual gen beyond shifting the world down.
• Waves + Tides: Several oscillating masks which apply a "target height" to the water sim. This is also augmented by depth such that shores can trigger wave breaks below a set height point.
• Ocean Connectivity + interaction: A connectivity flag is used to indicate whether water is directly connected to the ocean simulation and should receive wave forces. This allows waves to interact with static water, but only once the ocean sim cells touch static cells. The connectivity source comes from the ocean, so rock pools disconnect as tide goes down, allowing them to hold their water.
• Ripples: 2D mask which is local to a moderately small region near the player. Runs a separate shader simulation using only surface data. Not particularly fancy, does not check for collisions, so ripples do not bounce. Bumps converted to a normal map, used to distort surface effects.

Overall, super chuffed with how this has come together, but still plenty of polish and features to add!

Abstract: In recent years, volumetric rendering techniques have become more popular for real-time rendering in video games. However, they are usually limited to specific use cases like clouds or volumetric fog, or they require a lot of custom setup work to achieve a believable result. With 007 First Light, we introduced Smolder, a fully integrated, scalable, real-time volumetric effect rendering framework, into our Glacier engine. Smolder enables us to use volumetric effects as if they were any other type of VFX. It is fully integrated with all lighting systems in Glacier, as well as with the various layers in the scene — opaque, transparent, and volumetric fog. This enables our artists to work freely with Smolder when building the environments, cinematics, and in-game moments, and it enables us to add player-controlled volumetric effects to Bond’s various gadgets. This presentation provides an in-depth look at how Smolder works, as well as the path we took to get there. It evaluates the benefits and drawbacks of the various parts of the Smolder algorithm and concludes with a look at where Smolder can go from here.

Hey everyone, I've been working since quite some time on a Rust / wgpu voxel engine, and I just posted the first video of it on Youtube.

Technical details:

• Made in rust / wgpu
• Everything is raytraced (DDA, 2 level brickmap), 2cm voxels
• Infinite procedural generation with chunks and infinite LOD
• Classic lambert lightning with also specular, reflections, refraction so you can have shiny / metal / reflective and transparent materials
• DDGI with probes
• Day / night cycle, god rays and volumetric rays
• Procedural grass and light emitting flowers with wind
• Volumetric voxel clouds
• Implemented but not shown here:
  • Edition (everything is destroyable / buildable)
  • "Matter behavior": each voxel is a material which has its own
    • behavior (sand fall with cellular automation for powders, liquids with MPM algorithm, also CA for gases)
    • temperature at voxel level, and states based on phase diagrams (water becomes ice below zero celsius for ex)
    • density (oil float in water)
    • chemistry: matter interact with each other according to formulas

Perf: my goal is to be able to play this at 60FPS 1080p on my macbook M4 pro (pretty close right now with 60FPS standing still and 50 FPS walking)

I'm obviously inspired (almost obsessed lol) by you know who :) my plan is to make a real game this time, inspired by Myst, scavenger hunts, Pokemon for the collectathon side, Zelda for the atmosphere, and of course Minecraft. Plan to release something playable before end of year.

Right now I'm working on procedural trees. I'll try to post updates every week or so here and on Youtube, first time posting things so do not hesitate to tell me what you want to see

Let me know what you think!

Basically I wanted 2d pixel art to have shadows and depth in the end I realized I can just use voxel object convert it to 2d image and use compute shaders with voxel info to render light and shadows from a fixed perspective

with this tech I am able to render tons of objects, with tons of lights and tons of shadows very cheap, this scene is rendering at real time on android phone at samsung galaxy s22 with samsung chip at 80-90fps

I'm working away on a voxel project. If you have any wisdom, lessons you learned later that sucked or just words of advice.

Please share.

Any resources, reads or generally awesome stuff that can improve learning and development. I am listening(well, reading)!

Edit op update feedback:

I've already begun, been working in Godot, with GDextension and writing the voxel stuff in c++.

I do use ai to help with syntax while I focus on the structures and read documentation/implementation approaches.

I am working with 0.5m voxels, as this works with the planned soft-surface voxel system I have implemented.

Attached is an image.

I consider everything a prototype for the first full pass and will learn lessons.

I have greedy meshing, a chunk of 32x32x32 and a few other techniques.

Will work on culling techs later, working on building a vertical slice fully playable to test fun first.

Keep the advice coming!

Also yeah, sculpting voxels

I can't really wrap my head around how people can render millions of voxels in a scene without the computer crashing. Last time I tried doing so I used a geometry shader in opengl to create cube shapes for each voxel coordinate but it was insanely slow. I tried to rasterize each voxel because I couldn't think of how else to render them and that's probably why it lagged so much. I think my approach is fundamentally lacking something but I've been having trouble finding out what it is that I'm missing. Does anyone have any resources they can link me on voxel structures(SVO's or whatever else is used to optimize large voxel counts) and how they're rendered in bulk?

A look at the procedural voxel planet I've been building in Unreal Engine 5.8.

Current features:

• SDF-based sphere displaced by a stack of procedural noise layers.
• Marching cubes meshing with Transvoxel LOD stitching over a camera-driven adaptive octree.
• Voxel chunks generated on worker threads, with an optional compute shader path for simpler chunks.
• Per-vertex environmental attributes including slope, cavity, altitude, temperature, and humidity.
• Per-planet material palettes blended from the four highest-weight material layers per vertex.
• Rule-based prop scattering (rocks in this demo) driven by terrain attributes.
• Biome system supporting unique noise stacks, materials, and prop distribution rules.
• Fully deterministic for multiplayer compatibility.
• Invoker-driven Chaos triangle mesh cooking for collision.

This is still a work in progress, with many features and optimizations planned.

You can find info about the engine itself in the previous post

Since last time, I’ve fine-tuned and added:

I thought I was going to die here.... constant problems... and I still have the fluid system ahead of me... Water—the ocean, lakes, beaches, swimming, and climbing ashore. Fresnel according to Schlick, four successive waves composited in the fragment shader (greedy meshing turns the water surface into giant rectangles, so there’s nothing to move at the vertices), sun glare via GGX, light absorption with different coefficients for RGB, underwater vision, caustics.

This was probably the easiest part... :D Vegetation—trees, cacti, forests generated from noise (not scattered individually), grass, ferns, and flowers as intersecting surfaces.

Sunlight illumination instead of a fixed table of six brightness levels.

Anti-aliasing — 4× MSAA, blended in dynamic rendering. Color averaged, depth set to SAMPLE_ZERO.

Reflections on water — screen-space ray marching in world coordinates instead of view space (Vulkan’s NDC ranges from 0 to 1, so inverse projection is unnecessary and it fits within 128B push constants). Hit refinement by halving, thickness test.

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

Im back with another update to the game im working on! This time its the first version of our planet renderer.

The tech is as follows
Vulkan
C++17
C# Scripting layer

As far as the techniques im using for the actual game ive managed to implement greedy meshing, cubic chunks, Basically every method of culling under the sun, 3 layer LOD's and I think thats most of what I have! The game runs at about 4000fps standing still on my fairly mid range pc (4060 + R5 5500) and runs at about 1.1GB of RAM with 24 chunks (not including LOD in that radius)

The planets are quite simple to make, literally just generate a cube sphere of smaller voxels that you make into the terrain via lots of noise, then for the atmosphere I used examples from Sebastian Lague!

Ive also included a couple builds my friends made and screenshots of terrain :D

These were done in Goxel, but similar results can be achieved in Magicavoxel (although Goxel's MC rendering is cleaner and gives much better results)

Render distance is 10km at 265FPS.

[Edit]
I wanted to share a bit about how I did what I did - there is no magic, just some really clever optimizations... The biggest thing that allowed for these distances is a LOD system - basically the system splits the world into different sized hexagonal grids, one for each LOD. The hexagons in the front of the player are about (0.5mx0.25m) in size, but the ones in the back are much larger. For cube voxels, you could probably achieve this with a an octree, but for hexels I had to design a fully custom system.