Discussion
The EGG Blog
HexDecOctBin: 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.
Aardappel: Have you tried Teardown? Has incredibly good voxel physics. Definitely possible.
suncore: 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.
simgt: 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.
Aardappel: 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 :)
shubhamintech: 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.
vessenes: 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.
Aardappel: 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.
Aeolun: 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?
Aardappel: 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.
Aeolun: 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 :)
barcoder: 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!
LelouBil: 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/
nmeofthestate: I do wonder whether Kotlin is sufficiently different from C# to make it worth developing in Godot in a non-standard way.
LelouBil: [delayed]
deterministic: 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.
voidUpdate: 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
xyzzy_plugh: Lexaloffle's Voxatron is what you're describing: https://www.lexaloffle.com/voxatron.phpIMO the effect is less compelling than you might think.
voidUpdate: looks great to me, if that little gif is anything to go by
OtomotO: 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.
Aardappel: 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.
gazook89: Is it possible to fake a world curvature so that using a fog isn’t as necessary, as far items sink below the horizon?
