VoxelSpace: Terrain rendering algorithm in less than 20 lines of code (2020) | Hacker News Reader

VoxelSpace: Terrain rendering algorithm in less than 20 lines of code (2020)

github.com

339 pointslnyan89 comments

This is very neat. I miss the era when novel and elegant algorithms like this delivered magical experiences.

This could just be from getting old, but I feel like games have lost the magic they had when availability of hardware resources was limited. Back in the 80s, 90s and early 2000s we saw games push the medium forward practically every year, and certainly every generation. Developers squeezed all the performance they could from the hardware, using novel techniques and pure wizardry. Hardware advancements certainly helped, but it was never in abundance as it is today, so developers couldn't get complacent. Necessity is indeed the mother of invention.

These days I find fantasy platforms like the PICO-8 much more interesting than the latest rehashed release from any AAA studio. I don't understand how games that are essentially asset flips can be so successful year after year.

I’ll never forget my disappointment when I discovered that the higher resolution offered by a better GPU meant more display pixels, not more triangles. I thought it would make all the models in Descent 3 smoother. :)

This is mostly rose colored 1/4" thick welding goggles, I think. There are some mind-bendingly good moments in modern AAA video games. Sure there is some repeat sequelitus but there's original stuff too, and the tech definitely enables it.

I can remember a lot of old really, really, really bad videos games too!

That magic is still there, it's just overshadowed by capital. It's hard to find magic in a sea of marketing. Try Noita, it's quite fun.

I enjoy Noita, and interesting games like it, but I wouldn't describe it as "magical". Indies certainly are more enjoyable to play, but very few evoke that same feeling of awe like when you first experienced Doom or Mario 64 in the 90s. In a way I pity newer generations that have grown up in a digitally overstimulated world and missed the era when technology truly felt magical.

The only game that triggered this feeling for me in the past ~decade was Breath of the Wild. Many other games are fun and enjoyable, but very few have that same magic. Whereas in the 90s this was much more common.

I do concede that growing old could be part of the reason for losing that feeling, but I also think that the oversaturated market and lack of technical constraints play a role.

I was using this algorithm to make a 3D Mario Kart for my calculator (which can usually barely handle 2D graphics sometimes) which was pretty fun but I never finished

This was one of the prototypes: https://media.discordapp.net/attachments/953383695908216843/...

That's so cool! Well done.

I was using this algorithm to make a 3D Mario Kart for my calculator (which can usually barely handle 2D graphics sometimes) which was pretty fun but I never finished

This was one of the prototypes: https://youtu.be/9Z8Bm8ZmWKI

Oooh, looks like Raycasting. :)

There is lots of cool innovation happening in game tech still. Look at games like Noita, Dreams and Teardown. Or for an even more recent game, look at Tiny Glade. There’s a recent tech talk about it which is full of wizardry: https://youtu.be/jusWW2pPnA0?si=IE-6W0Z1VCBld0AT

There is also lots of cool tech happening at the more foundational levels in engines and frameworks, for example Epic’s Nanite/Lumen/MegaLights in UE5.

There is still a lot of wizardry going on in modern AAA video games. In fact, the video game industry is one of the few that actually care about performance, often more than safety and correctness.

It is just that it is much more complex and much less obvious. Before, an advance could going from flat triangles to textures, using a clever maths trick. Now an advance is better shading in the corners of a room, using a clever maths trick. The difference is that people will be able to tell immediately how an improvement the textures are, but unless they are in the field, they won't be able to point out the shadows in the corner of the room. These shadows are not useless though, it adds up to better graphics overall, but it is not as impressive.

About the AAA gaming industry, the thing is that this is big business, these games are awfully expensive, financed by investors who want to see a return on their investment. Usually, it means that they study the market, see what sell, and do something along these lines. Not very original, but less risky.

The indie game industry is the opposite. There are thousands of studios, they can't beat AAA on content and polish, and they need to come out of the pack, so they need something else, like original ideas. But overcoming technical limitations is usually not the driving force anymore, as there are not that many limitations anymore. In fact, they usually underperform compared to AAA productions because it would be unaffordable otherwise.

I don't know much about the PICO-8 scene, how much of it is about overcoming the (artificial) technical limitations and how much is about using the platform "as intended" and focus on gameplay.

I would say a little of both. Some of the most important bottlenecks a new game dev will encounter is "number of colors, screen resolution, sound properties" etc.

The CPU speed is also limited but it's a different kind of challenge to try to make a game be so complicated that there's enough math to even do to challenge the available CPU allocation given how few permutations of screen space are available to try to alter.

Depending on your game, RAM limitation and program space limitation might also come into play.

But the artificial limitations are only one element to why the platform is popular, the other element is the tooling.

Much like using Unity, Unreal, Roblox, etc you have loads of primitives and coding features (and music and SFX creation suites) at your fingertips built right into the platform, and how the limitations help here is to cap how subtle and complicated a person's goals are liable to be in order to help refocus the developer's attention back onto the gameplay loop.

The java 4k contest was fun (make a java applet game that is at most a 4096 bytes JAR, including all assets the game needs). Unfortunately I only discovered it shortly before it shut down (when no browsers supported java applets anymore). I did enter one year and it was not by coincidence that was the only time in 40 years of hobby-gamedev that I shared a game I made with people online.

It was a lot of fun to try to squeeze a game into 4 kB but I can definitely also admit that part of it was being able to use the extreme limit as an excuse for making things simpler and not have to worry about the game being ugly or not having sounds or not having a title screen and all the other 90% of stuff that would have been expected to turn it into a complete game.

I play around a bit with TIC-80. Some say it is just an open source PICO-8 and I guess it is to some extent. I paid for both but I have not spent as much time with PICO-8. I like that TIC-80 supports quite many different programming languages, but maybe PICO-8 does as well these days? There is no super obvious reason to use one or the other, so I go with the one with free source code.

Real retro gamedev is tempting, but it is difficult to find a real console that were heavily restricted while also being convenient to develop for. The fantasy consoles cheat a bit in being restricted like some early 1980's hardware while running code like some 2010's game engine. It's like the best of both worlds, but also a bit boring compared to writing something actually limited to what some old console could do.

> In fact, the video game industry is one of the few that actually care about performance, often more than safety and correctness.

If it does, then it doesn't show. It feels as though most major game engines have completely given up on performance-as-a-default in favour of simplifying (sometimes marginally) art workflows, and the frame rendering breakdown articles/videos I consume now and then entail baffling, utterly ridiculous and unnecessary drawcall counts, unoptimized geometry, poorly optimized shaders that give marginal graphical improvements, huge overdraw, etc.

It's gotten bad enough that resolution upscaling is becoming commonplace because of how ridiculous the per-fragment rendering costs are getting. That has no right to happen in games without high-fidelity subsurface scattering, volumetric effects, indirect lighting, raytraced reflections, etc. And yet it does. This is something nobody resorted to even in the 90s.

I recommend videos from the YT channel Threat Interactive, where they break down a lot of the horrifying rendering performance regressions that have become the norm in recent times.

Optimization happens elsewhere these days. Modern GPUs easily chug tons of triangles as long as they are not smaller than a single pixel. That's why stuff like Nanite is possible, where you auto-compute LOD geometry to roughly pixel-level polygon resolution and it will actually be faster than traditional LODs if you have tons of meshes in your view frustum. If you want to see some really fancy modern optimizations, look for example at how Guerilla implemented 3d volumetric clouds in Horizon. Using some clever tricks, they got the render cost down from 20ms to 2ms, thus making it possible to run on a base PS4.

As far as I can tell, Nanite is only faster when you're rendering huge trianglecount, unoptimized meshes, and strictly slower than proper LOD - I've seen convincing evidence that just enabling Nanite for already-optimized meshes results in big performance losses in and of itself. If anything, it's the prototypical example of a "performance regression for the sake of streamlining artist workflows" feature.

And honestly, I'm not very impressed by volumetric clouds when games like Assassin's Creed Unity from 2014 had enormous, sprawling open worlds with high-quality visuals comparable to much more recent games that struggle to run on hardware with several times the juice.

Very often, modern games look straight up worse for much higher resource cost because they stop looking better once you're forced to drop from maximum settings(and you are). There's blurry AA techniques, resolution upscaling(ew), or the fact that lowering texture resolution often degrades graphics way, way harder than in older titles using similar texture fidelity.

> I don't understand how games that are essentially asset flips can be so successful year after year.

We had plenty of shovelware like that ever since the Atari 2600 era too. People point to that (capped off by pacman and ET) as the cause of the console market crash of '83.

If anything, the amount of shovelware sharply decreased over time. In the Atari 2600 and NES days there were hardly any sources which reported on the quality of games. You basically had to decide based on box art or word of mouth. The result were cheap movie tie-ins or the like.

Later there were a lot of specialized game review magazines, though it wasn't easy to get hold of a review for a non-current game if you didn't have past magazine issues laying around. Then there was the Internet with increasingly many free reviews, especially once online advertising took off and game magazines moved to the Web, and finally we got accessible average user ratings from Steam or Metacritic.

If a game is bad today, everyone will know it. There are no bad movie tie-ins anymore. Games are at most bland, similar to an action movie sequel, or exploitative, by using addicting game mechanics. But they are rarely bad in the old sense. I've read that the new Indiana Jones game is better than most of the Indy movies.

> If anything, the amount of shovelware sharply decreased over time.

Seriously? Have you seen the Nintendo and Steam stores? I mean, it's great that game development is so accessible now, but the amount of low quality and half-baked or abandoned Early Access games is staggering.

> Then there was the Internet with increasingly many free reviews, especially once online advertising took off and game magazines moved to the Web, and finally we got accessible average user ratings from Steam or Metacritic.

Reviews don't mean much when publishers enforce embargos, or when they invest in marketing to create hype and drive preorders, only to deliver a broken game at launch with promises to patch it over time. Or when they're gamed by review bombing one way or the other, depending on some internet drama. Or when review sites are given different weights in calculating the overall score, leading to alternatives like OpenCritic. So, yeah, reviews can be helpful, but they're far from reliable.

> If a game is bad today, everyone will know it.

Ehh, highly doubtful, as I mentioned above. And even if there are negative reviews, companies have many different ways of hiding how bad a game is, and still profiting from them despite of it. They can launch a broken/unfinished game, patch it over time, and still end up with good will from consumers because of the work they put into it. See No Man's Sky, Cyberpunk 2077, etc. This way they profit from preorders, take as much time as they want to deliver the experience they advertised (while continuing to sell a half-baked product), and ultimately end up with an unscathed reputation so they can do it again. Then there are outright scams like The Day Before, countless asset flips, lazy ports, etc. Mobile gaming is infested with this garbage.

However you define "bad game", these products are certainly hostile to the consumer and there should be regulation in place to prevent them. This situation is far worse than the one that led to the 1983 crash, yet gaming has never been as popular as it is today.

I never bought that excuse for walled-garden consoles, since home computer games continued to do just fine after 1983 without locking down platforms.

In my game we intentionally constrained ourselves to a low resolution, fixed colour palette, etc. It means we can't fit much text for example and have to keep things as lean as possible. We even simulates a CRT monitor :)

You can check it out here: https://store.steampowered.com/app/3133060/Gnomes/ ;)

I've been reading masters of doom and its a nice feeling to relive some of that second hand.

> I don't understand how games that are essentially asset flips can be so successful year after year.

In my opinion, whether a game is enjoyable or not doesn't really rely on whether or not they were technically challenging to make. I don't know any successful games that are in fact "asset flips", but I do know that a lot of the games that I really enjoy are not technologically "pushing the envelope" at all: caves of qud, cube chaos, kenshi, rift wizard, just to name a few.

> In my opinion, whether a game is enjoyable or not doesn't really rely on whether or not they were technically challenging to make.

I agree, but that's not what I'm saying. I was referring to cookie cutter games released by Ubisoft, the CoD franchise, and most sports games. They essentially use the same formula, sometimes even the same engine, year after year, and just upgrade the assets, and do some minor tweaks. Yet these releases are incredibly popular and people keep buying them every year. Similarly for lazy "remasters" for games released not even a decade ago. Now with AI upscaling it's even easier to just increase the texture resolution and charge half or even full price for it. It's practically a scam.

> I do know that a lot of the games that I really enjoy are not technologically "pushing the envelope" at all: caves of qud, cube chaos, kenshi, rift wizard, just to name a few.

Sure, and I enjoy many of those as well. A game doesn't have to be technically impressive to be enjoyable. But IMO these don't have the "magic"/"wow" factor that was so common back in the 90s. If you played Doom or Mario 64 when they were released, you were _mesmerized_ by what you were seeing. Yes, these were great games, but the technical wizardry was what made them stand out from everything else. The jump from 2D to 3D and hardware accelerated graphics certainly played a role in that, but it was also due to very clever algorithms than ran on the same hardware as other games that weren't as impressive.

Today VR can arguably deliver that "wow" factor, but that's mostly due to the technology rather than the games themselves. Even nearly a decade into the modern VR wave, there are only a handful of games that deliver an experience close to what many games in the 90s did.

I can basically think of only one example of a modern game that delivered that same feeling: Breath of the Wild. We were used to open world games, we were used to Zelda games, but we hadn't seen such design ingenuity and technical polish, especially on a handheld system. Tears of the Kingdom is arguably a better game, but it didn't deliver that same experience for me.

Ah sorry, I misunderstood you! I agree with everything you say in this comment. Although I do wonder how much of that "magic"/"wow" factor was due to me being very young back then, rather than those games actually being good. Looking at you, 1995 Magic Carpet.

I agree that VR tech in general is just "wow" at lot of the time, even if the games are not that great. But I think that "Hello Puppets", "Scanner Sombre" and "Superhot" were all really cool and innovative, even within the VR scene. I think there's still some technological innovations possible that to deliver more "wow" moments.

> Although I do wonder how much of that "magic"/"wow" factor was due to me being very young back then, rather than those games actually being good. Looking at you, 1995 Magic Carpet.

Haha sure, there are also cases where a game is technically impressive but not actually good/enjoyable. The real magic is when both of these come together.

I think it's still too early for VR games to be both (with a few exceptions). We haven't quite solved major problems like locomotion, motion sickness, and comfort, of course. Maybe a few generations from now we'll start to see truly mesmerizing experiences that are both technically brilliant and enjoyable to play.

"when availability of hardware resources was limited"

If you aim for the broad mobile market - then you will have some serious limitations, as the majority of humans do not have flagship smartphones.

And even AAA games for the PC market - the better your game runs, the bigger the audience you can reach. Like the other poster said, bigger textures are far from the only thing that is happening behind the scenes.

In other words, I wish I would have unlimited hardware ressources.

> the majority of humans do not have flagship smartphones.

I always wonder if aliens are interacting with us through the anonymity of the internet. Things like this give me a (facetious) hope that they are. We can take from this that all aliens have flagship smartphones, but the majority of humans don’t.

The joke being flagship as in alien flagship? Otherwise I don't follow ..

It was because you referred to “humans”, as if distinction was required from a larger group. Nothing more than that, sorry for the confusion.

I see .. might have been because english is not my first language, but I thought the way I wrote was clear and common?

It is very clear. Your English is perfect, but I suppose it is unusual (to me) to see references to “humans”, maybe “people” is more common but there is absolutely nothing wrong with what you wrote.

Related. Others?

VoxelSpace – Terrain rendering algorithm in less than 20 lines of code - https://news.ycombinator.com/item?id=38051859 - Oct 2023 (2 comments)

Voxel Space: Comanche's terrain rendering in less than 20 lines of code (2020) - https://news.ycombinator.com/item?id=26631995 - March 2021 (71 comments)

Terrain rendering algorithm in less than 20 lines of code - https://news.ycombinator.com/item?id=21944573 - Jan 2020 (116 comments)

Terrain rendering in fewer than 20 lines of code - https://news.ycombinator.com/item?id=15772065 - Nov 2017 (93 comments)

Show HN: Voxel Space – terrain rendering in less than 20 lines of code - https://news.ycombinator.com/item?id=15339016 - Sept 2017 (2 comments)

I just say mars.com (no, not a domain. A program. A video: https://www.youtube.com/watch?v=_zSjpIyMt0k)

Edit: Pouet has it: https://www.pouet.net/prod.php?which=4662

and to be clear mars.com ran /smoothly/ on an 8Mhz 286.

The readme says, "If you have a 386 or better with VGA graphics, run mars and use the mouse to move around the landscape." Are you sure it will run on a 286?

Yes. It was 16bit code. I ran it on my 8mhz 286, it ran smoothly. On a 386 like my AMD 386/DX-40mhz it ran smoother than butter, with a 486/66 is was essentially too fast.

Wow! I appreciate the report. I never saw anything like this on my 286, but I didn't have a VGA on it either.

It was amazing to see back in the day. Unfortunately it kind of ruins you for the rest of time knowing what can be.

Interesting, I wonder how.

https://pastebin.com/RuVsnCyq

Here's the author describing how it was done. Note the 64K data sizes. So they fit into one 16bit segment.

This is fantastic, thanks!

If I'm understanding this correctly, in 01993, Tim Clarke independently reinvented the painter's-algorithm variant of the VoxelSpace algorithm used in Comanche the year before.

Also found a JavaScript implementation of this demo. Thanks for sharing it! http://web.archive.org/web/20140107070635/http://ppl-pilot.c...

Blast from the past... by the time this made its way to me circa 1998 it was embedded in a Microsoft Word file and controlled by mouse. I thought it was cool but was disappointed that it wasn't a full-fledged game because I was a child that had no awareness of demoscene or programming. In retrospect I've always thought this was just some chintzy DirectX demo that made the rounds via e-mail - I had no idea it was a real thing.

Ouch. I remember running it on my 286 and being blasted. And also disappointed because Wing Commander 3 wouldn't run on the same machine.

Its a neat way to render, but I don't think it qualifies as voxel, it can't render arbitrary volumes, and the data storage can't contain more than a single position for a given x,y. It's just a neat implementation of a heightmap renderer no?

Yes, the name they gave the algorithm is misleading.

I would say it clearly counts as a voxel engine. Heightmaps don't support overhangs like octrees do, but the heights are in the end stacks of voxels. An octree without overhang would look exactly the same.

Afaik, voxel means something like volume element, (cfr pixel as picture elemen, with x for coolness). As every column is a 3D box in this rendering method, I have no issue with describing it as a 2x2 matrix of voxels.

Heighmap renderers like this were definitely called "voxel" at the time.

I have such fond memories of building a terrain viewer like this (first in Pascal, then in C & Assembly) in the 1990's at the same time I was learning the requisite trigonometry in high school.

Back then, all kinds of low-level optimizations were necessary to make it work.

Figuring out how to do it, and optimize it with no books or internet to reference is one of the most personally rewarding things I've ever done.

Hey, I made a game using this technique here

https://eri0o.itch.io/i-rented-a-boat

It's made in Adventure Game Studio. It was made in a previous version of the engine that we hadn't optimized yet and I was too lazy to update it on itch page (but will one day). I have a write up there explaining how I made it but there are more details in the AGS forums.

You can do that in AGS? I'm impressed!

[2020] could go in the title (or even [2017], looking at other comments in the thread in the following discussion link).

There was also a discussion in 2021 of the same repository:

https://news.ycombinator.com/item?id=26631995

(and that thread links to other discussions too)

It's not quite the same, but I remember when I was first learning programming, I wrote a program that would generate a terrain heightmap, and do an isometric-style rendering using similar techniques. It was in QBasic, running on my middle school's 386-era DOS machines, and used graphics memory as its scratch space. Slow as heck, but I was fascinated with the output. It's one of the things that encouraged me to keep going with programming.

I remember reading about this somewhere (could be from an older HN post), but this time I decided to add a comment so that I don’t lose it. Being a flight sim fan, I still remember playing Comanche for the first time and the wow factor. It was something from the future or from the movies, you got the feeling that you were leaving in the computer era :-)

I remember Commanche and how it reminded me of being wowed by "Rescue on Fractalus"[0] (aka Behind Jaggi Lines pre-release) procedural generation on the 8-bit Atari.

[0] https://www.youtube.com/watch?v=FbZ-chrOgGg (landing on planet is at 1:00)

Amazing graphics and movement for the time

Behind Jaggi Lines also gave me the biggest jump-scares of any video game before or after. Shattered my nerves late at night with headphones on.

Novalogic used this technique for terrain rendering for quite a while, my favorite is the first episode of Delta Force. It looks like Comanche 4 and the original Black Hawk Down did away with this method and switched to a polygonal engine: https://en.wikipedia.org/wiki/Comanche_4#Reception

This is so cool.

In most contemporary games, you can occasionally see the mountains are hollow (from weird camera angles, clipping issues, etc).

However, with this method, your mountains are solid >:)

Highly recommend doing software renderer stuff like this for fun. Raytracers are a popular sort of project but this sort of retro realtime rendering code makes for a great weekend project too. I implemented basically the same algorithm ages ago (actually I ported some SDL code as an exercise to learn canvas2d): http://namuol.github.io/earf-html5/

Obviously the linked implementation is way more performant and far simpler than mine, so if you’re looking for a reference I wouldn’t recommend my old coffeescript code…

I’d love to live in an alternative timeline where GPUs are voxel-based.

Despite the name, there's not really much here that has much to do with "voxels" - it's a heightmap and raycasting.

It's kinda similar to Parallax mapping in a way.

I'd also be interested in what a "voxel-based" GPU would look like, they already support sampling 3d volumes in 3d textures, and the issues they have (namely memory use) seem pretty fundamental and I'm not sure how they can be overcome to match the scale of 3d environments expected today.

It has been generalized to stuff like what is linked in https://news.ycombinator.com/item?id=42590154.

Clearly (?) the way the math works out, the polygon-oriented GPUs we have make more sense for 3D graphics. But one can imagine a universe where things would be different.

The issue with voxels is sparseness - to have any hope of storing a world in the ram we have available it pretty much needs to have some variable length encoding, which makes it extremely difficult to use in a parallel manner as required by hardware.

It's why for display pretty much every modern voxel engine processes the sparse voxel world into a dense surface list - which then maps (reasonably) well to triangles.

I'd argue this difficulty in parallelization is a bigger hurdle than "just" engineering effort.

Much of the way a GPU functions isn't because we decided we loved triangles, but we found things that parallelize well and worked backwards. And then on modern GPUs don't actually devote that much area to dealing with "triangles" - so little is gained that it's often not worth redesigning to remove that capability from data centre "GPUs" that will never see a single triangle in their lives.

>The issue with voxels is sparseness - to have any hope of storing a world in the ram we have available it pretty much needs to have some variable length encoding, which makes it extremely difficult to use in a parallel manner as required by hardware.

Signed Voxel Octrees, and SVO Directed Acyclic Graphs in particular solve this pretty well. Most megavoxel engines are an implementation of this paper: https://graphics.tudelft.nl/Publications-new/2020/CBE20/Modi...

GPUs? Are those like VPUs but for geometrexels?

Nice. At least we have VRAM.

The term VPU is already taken though: https://en.wikipedia.org/wiki/Vision_processing_unit

timestream must have been forked before AI slop was pervasively installed on every handheld computer

Voxel rendering is basically raymarching. Current GPUs can implement this easily as pixelshaders.

Plenty of examples on https://www.shadertoy.com/

Probably wouldn't be too much different from modern gpus. The main difference would probably just be that it'd have a hardware method for doing ray-Signed Voxel Octree intersections.

With the flexibility of modern GPUs where some of the fastest rendering is pure compute, in a fashion you can code this up yourself or check out some of the commercial offering like Teardown.

It would just be throwing more hardware resources at filling the screen with pixels. Describing geometry surfaces with triangles and textures is essentially a compression method to save massive amounts of memory and bandwidth. The downside is that you can't do some things that raymarching a voxel volume enables, and that the idea of triangle rasterization doesn't make much sense when triangles approach pixel size.

The principle that image generation methods are dictated by available bandwidth goes all the way back to the first graphical computers (for instance the weird color-attribute encoding in the ZX Spectrum is essentially an image compression method to get more graphical fidelity out of a very limited memory bandwidth).

Very cool project and nice work! While I'm not very experienced with graphics rendering, I use a lot of computational geometry for work. I also implemented the Diamond-Square algorithm in matlab to generate randomized landscape terrains for a grad school project. Combining my generator with this rendering algorithm would be pretty fun to create and explore digital landscapes!

I built a web version based on your post: https://jesterswilde.dev/vertrend.html

This reminds me of how Wolfenstein 3D and to some extents how Doom works

It looks really good for such a simple algorithm. I love this!

>It looks really good for such a simple algorithm. I love this! If you like that, you should check out Inigo Quilez https://www.youtube.com/watch?v=BFld4EBO2RE

Here is the shadertoy link with code https://www.shadertoy.com/view/4ttSWf

Every time I see a voxel landscape it reminds me of this:

https://en.wikipedia.org/wiki/Comanche_(video_game_series)

That's what this GitHub repository is about, as it explains at the top of its README.md. No voxels are involved either in Comanche or in this repo.

Voxels was an interesting technique for about five minutes in the early 90s, but they could never really be rendered at a high enough resolution for them to look good imho.

John Lins https://youtu.be/8ptH79R53c0?si=33yYWMbfNAiJw0X8 Crystal Island looks amazingly detailed and smooth. Wish he would continue or share how.

That was super intriguing, thanks!

It looks good from a distance but as soon as you go near anything it devolves into a pixelated mess.

You should check out the game Teardown and then perhaps you will modify your perspective

Or maybe not, because it looks really bad compared to other, more or less state of the art engines. The most remarkable thing about Teardown is its physics, not its graphics.

Outcast was such a beautiful looking game !

https://news.ycombinator.com/item?id=42590568

Reply on news.ycombinator.com