[sscott]

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.

[lainga]

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.

[sscott]

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.

[haolez]

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 :)

[tommsy64]

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.

[sscott]

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.