The founder, Wouter, has created or helped design 10 programming languages. Voxile is built in his newest language: Lobster. Wouter has been a major contributor to WASM and LLVM while also inventing flatbuffers. He’s worked at Crytek, Gearbox and Google among many other places. I’ve never seen anything like Voxile.
Cube 2: Sauerbraten too! Definitely spent some evenings playing that with my roomies back in the day before we invariably went back to Q3. What an insane resume.
I have fond memories of porting Cube, Sauerbraten and AssaultCube to the Mac back in the day. Given what i've seen from Wouter back in the day i am not surprised he is still on it full steam…
About the Lobster language used: The first thing I do when encountering a new language is look at the memory management, since what I want to do with a piece of code is usually build and manipulate data in a safe and efficient manner, so this is central. I am happy to see Lobster seems to be trying to take a new(ish) and pragmatical approach to memory management and that there is a whole document describing it in detail (https://aardappel.github.io/lobster/memory_management.html) which means the language creator agrees that this is important. Also happy to see the language seems to support fast memory management in a multi threaded environment, which is absolutely not self evident in many languages.
Thanks for sharing, it's indeed a great way to quickly see what a language has to offer.
From what I understand, the main innovation of Lobster here is that `class Foo` is a boxed type, while `struct Bar` will be inlined. I'm not sure I see how that's an improvement over using either `Foo` or `Box<Foo>` on instantiation. It also does reference counting by default, and tries to optimise it out at compile time by assigning a single owner and borrow.
We often see complains that Rust's ownership puts a lot of burden on the programmer, but there is really a point at which it clicks and we stop having to fight the borrow checker almost entirely.
Lobster is meant to be a more high level language than Rust, so encoding what you want 99% of the time in the type made sense. It also makes it easier for people to read, knowing that common types like int2 are always by value.
That said, it be easy to have annotations to force the other use case, just so far that has not been needed :)
I'm a long time Unity developer that in the past year picked up Godot. The speed at which Godot loads compared to Unity is staggering, it's just so much faster. When I returned to Unity I raised that my flow state was constantly being broken in a way that it wasn't when using Godot.
Entering flow is one of the beautiful things I love about programming. And being knocked out of it often feels like a physical jolt.
Lobster seems to take the idea of optimisation and speed to new levels. Entering and remaining in flow must be even easier. First though, I'll need to put the time into learning enough to be able to do it!
Thanks for mentioning Lobster. This guy seems to have learned many lessons of language simplification and design. Looks like a promising language and I wish it success.
Lobster doesn’t seem that different from Lua in that regard? I won’t say it isn’t impressive, but I’m having a hard time believing the hard part of this thing was calling from an interpreted to a static language.
Edit: I was mistaken about what Lobster is (potentially compiled instead of jit), but the main point stands.
I'm working on an indie game project and just got frustrated with Unity, I'm porting everything over to Godot.
I even learned about using Kotlin with Godot today [0] and I am really hopeful this is stable (it seems so), because I favor a more functional style of programming and C# ends up making everything 5 times more verbose than Kotlin.
I find Kotlin way easier to read back than C#, and for the cases where I would have reached for GDScript for its simplicity, I can use Kotlin and have still a lot of simplicity, while also having type-safety.
Sorry, I mean that writing functional code in C# is way more verbose than in Kotlin.
C# is already more verbose because it lacks things like union types (and so you need to have a fallback branch in every switch) and for example everything needs to be nested in a class.
Then you also have the fact that there is no "val" keyword (which makes things clearer imo) and the fact that it's generics type inferencing is only based on method arguments, which really adds a lot of noise to almost all generic functions.
I was using LanguageExt [0] in C# and I am now using Arrow [1] in Kotlin, and while LanguageExt is really nice for addressing some C# shortcomings, for me this is night and day.
This, I was really impressed recently when I met a C# dev who was also a programmer (as opposed to your standard C# SaaS dev who just copy pasted from the framework docs and stack overflow and was fully automated by Claude in 2025) and he showed me how nice the language has gotten since I last used it over a decade ago when it was just Microslop Java. They've really put in work and it has a lot of great functional constructs now.
If the flow is just typing prompt after prompt into AI, I guess just ignore that it's running and keep typing? Or open a new tab and keep typing. Why does Claude even break the typewriter flow thing that's going for you?
Very cool - the post made me want to play the game, and check out lobster, but didn't link to it - lobster is open source: https://github.com/aardappel/lobster. It doesn't look like the voxel engine is, though, which is a bummer. On reflection, I'm guessing that game is built for mods, so that would be a path to getting to play with the engine side.
Any ideas how to increase the render distance way further?
Because that's where I always get stuck. There are so many cool algorithms and ideas that I have like combining ray tracing with meshing and even like imposters for the distant chunks.
But this is getting very complicated with contrees and raytracing/marching etc.
With raytracing having a far render distance is actually fairly cheap and simple compared to polygonal worlds (good looking LOD is hard).
Some reasons why we don't have a super far render distance, in order of importance:
The biggest is GPU memory. The octree that holds the world gets gigantic at large sizes. We'd have to swap parts out as the camera moves. We can do that but haven't gotten there.
Noise: raytracing looks incredibly noisy if you simply cast rays far into small geometry. Hence we even have LOD for blocks, even though they're not needed for efficiency, they're needed for visual stability.
If you're unlucky and a ray has a lot of near misses with geometry, it does more work than other rays and it causes GPU performance degradation. It's rare but to raytrace far you have to optimize for a certain amount of ray steps, we actually put a bound on this.
We find having fog gives some visual unity and sense of scale. With far away fog, the world looks VERY busy visually.
Is there any way to have something like a distance blur? e.g. as rays travel further you reduce the number, subsample then apply a gaussian(or algo of choice) blur across those that return, increasing in intensity as the rays angle gets coarser?
It'd be really neat to have some way of enabling really long-distance raytraced voxels so you can make planet-scale worlds look good, but as far as I'm aware noone's really nailed the technical implementation yet. A few companies and engines seem to have come up with pieces of what might end up being a final puzzle, but not seen anything close to a complete solution yet.
Yup you could blur, but it is not cheap, and it doesn't feel very satisfying to look at blurry stuff in the distance.
We have a "depth of field" implementation for when you're in dialog with an NPC. There it looks nice, because you're focused on one thing. But when looking around its not that great.
Ideally you want it close to native res in the distance, but without any wobble produced by noise as you move. This is really hard.
Having just played it, you seem to have worked around the destruction problem by removing voxels one chunk at a time. But I’m still baffled by the sheer number on screen at the same time :)
I appreciate when games load fast (this one does). Its one of the signs I use to see if a game is worth my time. Most of the games I play, I am playing the game within 20-30 seconds of opening the game from my desktop. I'm naively assuming that in order for a game to load fast you have to have a good plan of what order to load things in. It feels like an attention to detail thing to me.
One issue with Voxel-based physics destruction games is that the physics happens in continuous space (as opposed to voxel space). This means that the moment you break off a chunk of geometry, it has to be converted into a mesh and simulated like any other mesh-based model will. This makes voxels seem like more complicated Voronoi-noise based fractures. If you want the modelling workflow or the looks of voxels, it's fine. But assuming that voxels will somehow help with the destruction physics seems not to be a valid assumption.
Ideally, we would be able to do physics in voxel space itself (sort of like a cellular automata based classical mechanics), but that doesn't seem to be possible.
This isn’t actually true if you use GPU raytracing, as everyone involved with voxel destruction seems to realize at one point or another. Meshing in a performant way after every destruction event is simply not possible.
Kind of looks like like Minecraft if it was built out of Voxatron. (millions of Little destructible cubes) seems like a very very difficult thing to do at that scale. On top of that making a engine and a language. This guy must have interesting things to say.
I guess if I'd done all that work on lobster and then bipolar built a ray traced voxel engine on top of that, end game would be to licence the engine. You have something here that the other game engines don't have, and something Minecraft is not likely to have (they are pretty stagnant development wise). This is easily 100 times better than Roblox. If you focus on making the world building tools easy to use and modding/game design you could easily be the next big thing.
Don't get too bogged down in game design other than to use it as a proof of concept to help you understand what game designers will need.
The game currently has a Mixed (65%) rating on Steam. Granted, some negative reviews are shallow, but some mention important issues. Regardless, a Minecraft clone is not exactly groundbreaking in terms of gameplay.
This is to say that technical merits are rarely good indicators of a good game. As a gamer, I don't really care about the game engine, and even less about the language it's written in. Good programmers often obsess about these details, but it's easy to miss the forest for the trees, which is what I think happened here. Game design is a separate skill from game development, and not many people excel at both.
Still, it's great seeing this here, as the technical achievements are quite remarkable.
It's not intended to be a Minecraft clone.. if you look a bit closer than the initial visual impression, you'll see there are many differences in gameplay.
As for the rating, yes we had a rough initial launch, but we're fixing all these things. Note that it is 65% out of only 63 user reviews, so statistically not set in stone yet.
65% positive reviews doesn’t tell you much about whether the game is good or not. At most it tells you that the game wasn’t great at communicating what people should expect.
This is just being intentionally obtuse. Everyone knows that 65% generally means the game doesn't even run on most devices, crashes constantly, or has some other serious flaw. Ridiculous.
> I played this game for 3 hours and i can confirm it is not in a playable state, there were several bugs within the first few maps that deleted needed items causing us to reset the entire world. several times. Don't waste your time...
Cool, finally something from Aardappel again (maybe I missed many other things). I like the programming languages since E and I am happy something we can buy comes from it. Well done.
Building your own language to build your own engine to build your own game is what most orgs would flag as scope creep. But that's exactly what lets Wouter push things nobody else can lol he controls every constraint all the way down. Genuinely wild stuff.
I have been running across that repo for years and wondered if anything was happening with it - great to see an impressive game project built on it now.
It always mildly annoys me when a game says that it is all voxels, but clearly isn't, since the little cubes easily move off the voxel grid. Its just geometry moving around, like normal games, but modelled in little cubes, instead of being fully restricted to voxels. I would really like to see a fully voxel game, where all geometry is "rendered" to voxel space before being rendered to the screen, so that everything is just cubes that don't move, just change colour
While Voxile has off-grid blocks of voxels for monsters etc, it is much more serious about being on-grid for everything else. The entire world is entirely on-grid, single size voxels, you can only place aligned objects, and rotate in 4 directions. These voxels only every exist as voxels, never as polygons.
In contrast with most voxel-looking games, which are actually meshes converted from voxel inputs, placed at arbitrary locations with arbitrary scale.
When I started this project, I actually prototyped what it would take to have moving objects in-world as aligned voxels, but the animation was too jerky and it was too limited. Would have been an interesting "style" suitable for some games (strategy games?) but none with fast paced realtime combat.
The founder, Wouter, has created or helped design 10 programming languages. Voxile is built in his newest language: Lobster. Wouter has been a major contributor to WASM and LLVM while also inventing flatbuffers. He’s worked at Crytek, Gearbox and Google among many other places. I’ve never seen anything like Voxile.
Cube 2: Sauerbraten too! Definitely spent some evenings playing that with my roomies back in the day before we invariably went back to Q3. What an insane resume.
I have fond memories of porting Cube, Sauerbraten and AssaultCube to the Mac back in the day. Given what i've seen from Wouter back in the day i am not surprised he is still on it full steam…
Indeed! Thanks for also linking my discussion with Wouter His early work on Cube engine and Amiga-E are still awesome to look at.
I remember learning about Bla, a functional programming language for Amiga wrote for his master's thesis.
About the Lobster language used: The first thing I do when encountering a new language is look at the memory management, since what I want to do with a piece of code is usually build and manipulate data in a safe and efficient manner, so this is central. I am happy to see Lobster seems to be trying to take a new(ish) and pragmatical approach to memory management and that there is a whole document describing it in detail (https://aardappel.github.io/lobster/memory_management.html) which means the language creator agrees that this is important. Also happy to see the language seems to support fast memory management in a multi threaded environment, which is absolutely not self evident in many languages.
Thanks for sharing, it's indeed a great way to quickly see what a language has to offer.
From what I understand, the main innovation of Lobster here is that `class Foo` is a boxed type, while `struct Bar` will be inlined. I'm not sure I see how that's an improvement over using either `Foo` or `Box<Foo>` on instantiation. It also does reference counting by default, and tries to optimise it out at compile time by assigning a single owner and borrow.
We often see complains that Rust's ownership puts a lot of burden on the programmer, but there is really a point at which it clicks and we stop having to fight the borrow checker almost entirely.
Lobster is meant to be a more high level language than Rust, so encoding what you want 99% of the time in the type made sense. It also makes it easier for people to read, knowing that common types like int2 are always by value.
That said, it be easy to have annotations to force the other use case, just so far that has not been needed :)
I'm a long time Unity developer that in the past year picked up Godot. The speed at which Godot loads compared to Unity is staggering, it's just so much faster. When I returned to Unity I raised that my flow state was constantly being broken in a way that it wasn't when using Godot.
Entering flow is one of the beautiful things I love about programming. And being knocked out of it often feels like a physical jolt.
Lobster seems to take the idea of optimisation and speed to new levels. Entering and remaining in flow must be even easier. First though, I'll need to put the time into learning enough to be able to do it!
Thanks for mentioning Lobster. This guy seems to have learned many lessons of language simplification and design. Looks like a promising language and I wish it success.
Ref: https://aardappel.github.io/lobster/language_reference.html
Lobster doesn’t seem that different from Lua in that regard? I won’t say it isn’t impressive, but I’m having a hard time believing the hard part of this thing was calling from an interpreted to a static language.
Edit: I was mistaken about what Lobster is (potentially compiled instead of jit), but the main point stands.
Yeah,
I'm working on an indie game project and just got frustrated with Unity, I'm porting everything over to Godot.
I even learned about using Kotlin with Godot today [0] and I am really hopeful this is stable (it seems so), because I favor a more functional style of programming and C# ends up making everything 5 times more verbose than Kotlin.
[0] https://godot-kotl.in/en/stable/
I do wonder whether Kotlin is sufficiently different from C# to make it worth developing in Godot in a non-standard way.
For me, it does.
I find Kotlin way easier to read back than C#, and for the cases where I would have reached for GDScript for its simplicity, I can use Kotlin and have still a lot of simplicity, while also having type-safety.
> I favor a more functional style of programming and C# ends up making everything 5 times more verbose than Kotlin.
As if you can't program C# functional style.
Sorry, I mean that writing functional code in C# is way more verbose than in Kotlin.
C# is already more verbose because it lacks things like union types (and so you need to have a fallback branch in every switch) and for example everything needs to be nested in a class.
Then you also have the fact that there is no "val" keyword (which makes things clearer imo) and the fact that it's generics type inferencing is only based on method arguments, which really adds a lot of noise to almost all generic functions.
I was using LanguageExt [0] in C# and I am now using Arrow [1] in Kotlin, and while LanguageExt is really nice for addressing some C# shortcomings, for me this is night and day.
[0] https://github.com/louthy/language-ext
[1] https://arrow-kt.io/
> As if you can't program C# functional style.
This, I was really impressed recently when I met a C# dev who was also a programmer (as opposed to your standard C# SaaS dev who just copy pasted from the framework docs and stack overflow and was fully automated by Claude in 2025) and he showed me how nice the language has gotten since I last used it over a decade ago when it was just Microslop Java. They've really put in work and it has a lot of great functional constructs now.
So true.
Recent changes to Xcode have meant that on device debugging now launches WAY slower for me every time.
Once it’s going it’s fine. But an extra 20 seconds every time you start the app just kills things for me. It was never instant but now it’s trash.
I get taken out of flow every time I submit my prompt to Claude. How’d you work around that?
Not every conversation is about AI. This one isn't.
Are we just assuming nobody is programming commando anymore?
If the flow is just typing prompt after prompt into AI, I guess just ignore that it's running and keep typing? Or open a new tab and keep typing. Why does Claude even break the typewriter flow thing that's going for you?
You can try not using Claude
Very cool - the post made me want to play the game, and check out lobster, but didn't link to it - lobster is open source: https://github.com/aardappel/lobster. It doesn't look like the voxel engine is, though, which is a bummer. On reflection, I'm guessing that game is built for mods, so that would be a path to getting to play with the engine side.
Yes, only the lower layers are open source right now. We will eventually expose more, when modding will more stable, etc.
Right now the editor has a UI driven minimalistic language for specifying quests and other gameplay actions.
Any ideas how to increase the render distance way further?
Because that's where I always get stuck. There are so many cool algorithms and ideas that I have like combining ray tracing with meshing and even like imposters for the distant chunks.
But this is getting very complicated with contrees and raytracing/marching etc.
With raytracing having a far render distance is actually fairly cheap and simple compared to polygonal worlds (good looking LOD is hard).
Some reasons why we don't have a super far render distance, in order of importance:
The biggest is GPU memory. The octree that holds the world gets gigantic at large sizes. We'd have to swap parts out as the camera moves. We can do that but haven't gotten there.
Noise: raytracing looks incredibly noisy if you simply cast rays far into small geometry. Hence we even have LOD for blocks, even though they're not needed for efficiency, they're needed for visual stability.
If you're unlucky and a ray has a lot of near misses with geometry, it does more work than other rays and it causes GPU performance degradation. It's rare but to raytrace far you have to optimize for a certain amount of ray steps, we actually put a bound on this.
We find having fog gives some visual unity and sense of scale. With far away fog, the world looks VERY busy visually.
Is there any way to have something like a distance blur? e.g. as rays travel further you reduce the number, subsample then apply a gaussian(or algo of choice) blur across those that return, increasing in intensity as the rays angle gets coarser?
It'd be really neat to have some way of enabling really long-distance raytraced voxels so you can make planet-scale worlds look good, but as far as I'm aware noone's really nailed the technical implementation yet. A few companies and engines seem to have come up with pieces of what might end up being a final puzzle, but not seen anything close to a complete solution yet.
Yup you could blur, but it is not cheap, and it doesn't feel very satisfying to look at blurry stuff in the distance.
We have a "depth of field" implementation for when you're in dialog with an NPC. There it looks nice, because you're focused on one thing. But when looking around its not that great.
Ideally you want it close to native res in the distance, but without any wobble produced by noise as you move. This is really hard.
What is the voxel resolution Voxile works at?
Also, does it have a single world grid? (I saw you say octree somewhere) or many separate elements?
A voxel is about 2 inches / 5cm in size.
Yes there is a single world grid, so all world objects are axis aligned and same size.
On top of that it can have floating "sprites" which are used for monsters, particles and such.
Having just played it, you seem to have worked around the destruction problem by removing voxels one chunk at a time. But I’m still baffled by the sheer number on screen at the same time :)
Gorgeous. These are the graphics I wish Veloren[1] had. Maybe my machine is lacking the specs to dial up the graphics all the way…
[1]: https://veloren.net/
Heh. I thought I remembered the name. I used to use Wouter's E programming language on the Amiga. It was pretty good, as I recall.
I appreciate when games load fast (this one does). Its one of the signs I use to see if a game is worth my time. Most of the games I play, I am playing the game within 20-30 seconds of opening the game from my desktop. I'm naively assuming that in order for a game to load fast you have to have a good plan of what order to load things in. It feels like an attention to detail thing to me.
One issue with Voxel-based physics destruction games is that the physics happens in continuous space (as opposed to voxel space). This means that the moment you break off a chunk of geometry, it has to be converted into a mesh and simulated like any other mesh-based model will. This makes voxels seem like more complicated Voronoi-noise based fractures. If you want the modelling workflow or the looks of voxels, it's fine. But assuming that voxels will somehow help with the destruction physics seems not to be a valid assumption.
Ideally, we would be able to do physics in voxel space itself (sort of like a cellular automata based classical mechanics), but that doesn't seem to be possible.
This isn’t actually true if you use GPU raytracing, as everyone involved with voxel destruction seems to realize at one point or another. Meshing in a performant way after every destruction event is simply not possible.
So how would you do destruction physics on voxels without meshing? This is how even Teardown does it, and it uses raymarching.
Have you tried Teardown? Has incredibly good voxel physics. Definitely possible.
Teardown calculates collision meshes and does physics on those. Not on voxels directly, and definitely on in voxel space.
Kind of looks like like Minecraft if it was built out of Voxatron. (millions of Little destructible cubes) seems like a very very difficult thing to do at that scale. On top of that making a engine and a language. This guy must have interesting things to say.
I guess if I'd done all that work on lobster and then bipolar built a ray traced voxel engine on top of that, end game would be to licence the engine. You have something here that the other game engines don't have, and something Minecraft is not likely to have (they are pretty stagnant development wise). This is easily 100 times better than Roblox. If you focus on making the world building tools easy to use and modding/game design you could easily be the next big thing. Don't get too bogged down in game design other than to use it as a proof of concept to help you understand what game designers will need.
The game currently has a Mixed (65%) rating on Steam. Granted, some negative reviews are shallow, but some mention important issues. Regardless, a Minecraft clone is not exactly groundbreaking in terms of gameplay.
This is to say that technical merits are rarely good indicators of a good game. As a gamer, I don't really care about the game engine, and even less about the language it's written in. Good programmers often obsess about these details, but it's easy to miss the forest for the trees, which is what I think happened here. Game design is a separate skill from game development, and not many people excel at both.
Still, it's great seeing this here, as the technical achievements are quite remarkable.
It's not intended to be a Minecraft clone.. if you look a bit closer than the initial visual impression, you'll see there are many differences in gameplay.
As for the rating, yes we had a rough initial launch, but we're fixing all these things. Note that it is 65% out of only 63 user reviews, so statistically not set in stone yet.
65% positive reviews doesn’t tell you much about whether the game is good or not. At most it tells you that the game wasn’t great at communicating what people should expect.
This is just being intentionally obtuse. Everyone knows that 65% generally means the game doesn't even run on most devices, crashes constantly, or has some other serious flaw. Ridiculous.
Explain how a game that doesn’t run on most devices or crashes constantly is recommended by 65% of reviewers.
But also if that is true, that just solidifies my point which is that a 65% doesn’t necessarily have anything to do with game design.
Steam review marked as most helpful states:
> I played this game for 3 hours and i can confirm it is not in a playable state, there were several bugs within the first few maps that deleted needed items causing us to reset the entire world. several times. Don't waste your time...
That review is a year old. Just maybe it’s improved since then?
Now this is the kind of thing I expect people to bring to show and tell when they post about how they are 100x as productive thanks to AI.
Haha.. yeah entirely coded without AI so far, lets see how long we keep that up :P
If you use Google in any capacity, you already have.
and this is why i, personally, use searxng these days instead of google or duckduckgo
Cool, finally something from Aardappel again (maybe I missed many other things). I like the programming languages since E and I am happy something we can buy comes from it. Well done.
Building your own language to build your own engine to build your own game is what most orgs would flag as scope creep. But that's exactly what lets Wouter push things nobody else can lol he controls every constraint all the way down. Genuinely wild stuff.
I wasn't prepared to see how good the game looks visually. It's super cool.
Congrats on your release, Aardappel! Bought a copy to support the dream!
Much appreciated :)
Ah, the Lobster guy!
I have been running across that repo for years and wondered if anything was happening with it - great to see an impressive game project built on it now.
This looks so cool! Love the build to fight angle.
Gonna try it as soon as... I have time
Does anyone know if this uses Microvoxels or an Octree? As someone who has built an Octree engine I am curious. I will say it is gorgeous!
Both! It uses an octree, and at the leaves are bricks of small voxels.
Love Voxile! It's a beautiful little game. Actually didn't known it was still receiving updates.
Really looking forward to playing Voxile with my friends! I feel like merging real quests with a Minecraft-like will be compelling.
naming something tech related without referencing crabs or lobsters challenge [impossible difficulty]
It always mildly annoys me when a game says that it is all voxels, but clearly isn't, since the little cubes easily move off the voxel grid. Its just geometry moving around, like normal games, but modelled in little cubes, instead of being fully restricted to voxels. I would really like to see a fully voxel game, where all geometry is "rendered" to voxel space before being rendered to the screen, so that everything is just cubes that don't move, just change colour
While Voxile has off-grid blocks of voxels for monsters etc, it is much more serious about being on-grid for everything else. The entire world is entirely on-grid, single size voxels, you can only place aligned objects, and rotate in 4 directions. These voxels only every exist as voxels, never as polygons.
In contrast with most voxel-looking games, which are actually meshes converted from voxel inputs, placed at arbitrary locations with arbitrary scale.
When I started this project, I actually prototyped what it would take to have moving objects in-world as aligned voxels, but the animation was too jerky and it was too limited. Would have been an interesting "style" suitable for some games (strategy games?) but none with fast paced realtime combat.
John Lin used to work on such an engine where all voxels stay axis and grid aligned, even in animations:
https://x.com/ProgrammerLin/status/1342786223811698688 https://voxely.net/blog/
But I think the project was abandoned in 2021.
Lexaloffle's Voxatron is what you're describing: https://www.lexaloffle.com/voxatron.php
IMO the effect is less compelling than you might think.
looks great to me, if that little gif is anything to go by
Are you suggesting the voxel grid is attached to the camera, or that the camera moves through the grid?
Either could work, but world space voxels would probably be easier to understand than camera space
This is the kind of cool article that makes me visit HN regularly.
Instead of the usual BS "AI will kill us all" or "AI wrote Linux in 5 secs!" style articles.
lobster: Like rust, python and ruby all mixed together
Very cool
[dead]