News for hackers. Stuff that matters.
Re:Matheminecraft: Where math and Minecraft meet by sscott on Tuesday April 21, 2020 @05:53PM (#22939723)
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.

Re:Matheminecraft: Where math and Minecraft meet by lainga on Tuesday April 21, 2020 @05:58PM (#22939781)
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.

Re:Matheminecraft: Where math and Minecraft meet by sscott on Tuesday April 21, 2020 @06:22PM (#22939967)
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.

Re:Matheminecraft: Where math and Minecraft meet by haolez on Tuesday April 21, 2020 @10:26PM (#22941417)
Maybe we could use something similar to PostGIS' spatial indexes to fetch only the cubes that we need.
Re:Matheminecraft: Where math and Minecraft meet by haolez on Tuesday April 21, 2020 @10:25PM (#22941404)
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 :)
Re:Matheminecraft: Where math and Minecraft meet by tommsy64 on Tuesday April 21, 2020 @07:15PM (#22940338)
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.
Re:Matheminecraft: Where math and Minecraft meet by sscott on Wednesday April 22, 2020 @03:44AM (#22943192)
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.