4 ms·

One side project that's on my bucket list is to implement very far range of view on Minecraft-like games (e.g. Minetest[1] and Terasology[2]). Something like wh

by haolez 7y ago

One side project that's on my bucket list is to implement very far range of view on Minecraft-like games (e.g. Minetest[1] and Terasology[2]). Something like what we see in Battle Royale games or open-world shooters like Farcry. It's a little frustrating to have such beautiful worlds in these games and not being able to see a large part of it in a stunning landscape. I have no ideas what kind of techniques would be required. I'm not a computer graphics guy :) [1] https://www.minetest.net/ https://www.minetest.net/ [2] https://terasology.org/ https://terasology.org/

sq_ 7y ago
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.
- didericis 7y ago
  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?
  - tommsy64 7y ago
    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-programmers/content/3ds_max_basics/3d_representation.html https://cathyatseneca.gitbooks.io/3d-modelling-for-programme... [2] - https://en.wikipedia.org/wiki/Mipmap https://en.wikipedia.org/wiki/Mipmap
    - didericis 7y ago
      Thanks for the info. That book looks great intro into this kind of stuff, just bookmarked it.
fools 7y ago
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 https://en.m.wikipedia.org/wiki/Draw_distance
sscott 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      Maybe we could use something similar to PostGIS' spatial indexes to fetch only the cubes that we need.
  - haolez 7y ago
    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 7y ago
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-blocky-voxels/ https://0fps.net/2018/03/03/a-level-of-detail-method-for-blo... [2] - http://www.sea-of-memes.com/LetsCode64/LetsCode64.html http://www.sea-of-memes.com/LetsCode64/LetsCode64.html and http://www.sea-of-memes.com/LetsCode67/LetsCode67.html http://www.sea-of-memes.com/LetsCode67/LetsCode67.html
- haolez 7y ago
  I think Terasology managed to participate in GSoC at some time :)

by haolez 7y ago

sq_ 7y ago

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.

didericis 7y ago
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?
- tommsy64 7y ago
  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-programmers/content/3ds_max_basics/3d_representation.html https://cathyatseneca.gitbooks.io/3d-modelling-for-programme... [2] - https://en.wikipedia.org/wiki/Mipmap https://en.wikipedia.org/wiki/Mipmap
  - didericis 7y ago
    Thanks for the info. That book looks great intro into this kind of stuff, just bookmarked it.

fools 7y ago

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 https://en.m.wikipedia.org/wiki/Draw_distance

sscott 7y ago

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 7y ago
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 7y ago
  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 7y ago
    Maybe we could use something similar to PostGIS' spatial indexes to fetch only the cubes that we need.
- haolez 7y ago
  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 7y ago

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-blocky-voxels/ https://0fps.net/2018/03/03/a-level-of-detail-method-for-blo... [2] - http://www.sea-of-memes.com/LetsCode64/LetsCode64.html http://www.sea-of-memes.com/LetsCode64/LetsCode64.html and http://www.sea-of-memes.com/LetsCode67/LetsCode67.html http://www.sea-of-memes.com/LetsCode67/LetsCode67.html

haolez 7y ago
I think Terasology managed to participate in GSoC at some time :)