I've had this exact same project idea on my mind for a year or so, largely driven by a desire to see beautiful, to-scale mountain ranges in game (Thousands of blocks of render distance rather than a measly ~256). I wouldn't consider myself a computer graphics guy either; however, I recently started to dive into the world of computer graphics to at least figure out what it would take to implement something like this.

As a sibling commenter mentioned, using a marching cube algorithm is one approach. 0fps [1] has a good blog post about using Progressively Ordered Primitive buffers to implement Level of Detail in Minecraft-like games. (There is an interesting comment on that blog replying to that post.) Another blog [2] shows a similar implementation in a Minecraft-like game call "SeaOfMemes".

On a side note, I've never heard of Terasology—and it's been around for 9 years(!) it seems. I'll definitely check it out.

[1] - https://0fps.net/2018/03/03/a-level-of-detail-method-for-blo... [2] - http://www.sea-of-memes.com/LetsCode64/LetsCode64.html and http://www.sea-of-memes.com/LetsCode67/LetsCode67.html

I think Terasology managed to participate in GSoC at some time :)

I set up a Minecraft server for some friends a few weeks ago, and I learned firsthand how huge of a performance improvement one can get by dropping the render distance.

My basic understanding of the problem is that it's less of a graphics problem and more of a CPU one. Loading another chunk requires the game to actively simulate everything happening in that chunk, and, since the game is single-threaded, increasing the number of chunks loaded quickly causes the amount of work needing to be done per tick to explode.

I know nothing about the codebase and haven’t done any projects related to game engines/physics rendering, but I’ve seen a lot of games that seem to have “high level” and “low level” simulations. I’ve walked too far too quickly on older systems in open world games and have often noticed lower resolution models that are designed to be seen from far away.

Am I right in thinking that Minecraft doesn’t do that? And that everything rendered uses the same resolution models for things far away as for things close up?

What you are thinking of is called Level of Detail (LOD). The principle being that 3D models further away can be rendered with fewer vertices/polygons, i.e., at a lower LOD. 3D models in Minecraft are almost all simple cubes or a collection of rectangles (e.g., torches, levers, slabs). There aren't really any extra polygons in these models that can be removed to create a less detailed representation, unlike, say in this [1] model of a rabbit.

Thus, you are right in thinking that Minecraft doesn't implement a LOD by changing the resolution of the models; however, it does use progressively lower resolution textures for texturing models that are farther away. This is a common technique called mipmapping [2].

[1] - https://cathyatseneca.gitbooks.io/3d-modelling-for-programme... [2] - https://en.wikipedia.org/wiki/Mipmap

Thanks for the info. That book looks great intro into this kind of stuff, just bookmarked it.

I am a computer graphics guy and I reckon it'd largely be a memory issue.

Essentially Minecraft is a voxel system which grows at a cubic rate.

This will quickly fill your GPU's memory and shortly there after system memory and shortly after that storage memory.

Rendering it on the other hand would be relatively trivial with a marching cube algorithm using one or more rays per pixel.

I thought you might render a snapshot of each few chunks from maybe 16 angles and compose them together like backdrop pieces on a stage. Update the snapshot every time a player moves over that chunk. Just patch into the render function: are we within the (basegame settings) chunk draw distance? (yes) - render the chunk - (no) - retrieve the "backdrop piece" for that chunk from this view angle, and draw it behind everything else rendered so far.

You could even add atmospheric effects to cheat and only save a monochrome image, then tint it progressively bluer and bluer (but not invisible) with distance.

But you've still got to load the chunks from some massive dataset stored somewhere and you can still look/run around in a full sphere at 60fps?

The backdrop pieces are effectively where the rays hit as far as I can tell from your description.

One memory optimisation I can think of is to store a bvh of the empty space and traverse that. Using a signed distance field might also help in the ray marching.

Maybe we could use something similar to PostGIS' spatial indexes to fetch only the cubes that we need.

I thought about something like this as well. You could use "low resolution ray-tracing", i.e. using very thick light rays to create layers of 2D snapshots of what's suppose to be beyond the range of view. And then evolve the system from there :)

I'm just starting to learn computer graphics and I've come across the Marching Cubes algorithm; however, I don't understand in this instance what you mean by "using one or more rays per pixel" and how that fits in with Marching Cubes. Could you point me in a direction to learn more about this? Thank you.

Yes sorry that last paragraph is a bit of a munge it should read:

Rendering it on the other hand would be relatively trivial with a marching cube algorithm AND using one or more rays per pixel [to ray trace against the hull constructed by the simplified marching cube algo - for DXR]

Having thought about it a bit more since (in the other answers) you may be better off with a signed distance field or constructing a specialised BVH yourself as this is a simplified case.

I'm guessing you can get pretty far by compiling the chunks into meshes at multiple levels of detail (2x2, 4x4, 8x8, etc.), each with the same (or similar) number of vertices.

https://en.m.wikipedia.org/wiki/Draw_distance