well i got it working, and it does work. fps at 12 chunk render distance up to 75ish from 45ish on my not very powerful gpu

some kinks to work out still, can probably make it faster, but it's a good proof of concept

atm it's running across multiple frames so if you rotate the camera very fast, it takes a frame or two for the geometry to show up >_>;

@brouhaha That's the IBM's vision of it. But RPG (pretty much aka IF) is a whole genre of programming languages, and the non-IBM ones, designed for for writing rôle-playing games and/or other kinds of interactive fiction, rather than generating report programs, are often quite nice.

@eniko

@riley @eniko
Oh, no doubt. Inform 7 is extremely awesome.

i wish i knew a better way to approximate the bounding rectangle of these AABB cubes. atm i'm using an extremely generous buffer to make sure nothing is considered offscreen when it's not actually offscreen in my first pass, but that means i wind up doing a lot of matrix multiplications for corners of subchunks that aren't on screen

i wish i knew a better way to approximate the bounding rectangle of these AABB cubes. atm i'm using an extremely generous buffer to make sure nothing is considered offscreen when it's not actually offscreen in my first pass, but that means i wind up doing a lot of matrix multiplications for corners of subchunks that aren't on screen

@eniko bounding spheres?

i wish i knew a better way to approximate the bounding rectangle of these AABB cubes. atm i'm using an extremely generous buffer to make sure nothing is considered offscreen when it's not actually offscreen in my first pass, but that means i wind up doing a lot of matrix multiplications for corners of subchunks that aren't on screen

@eniko Just had an idea. Take a slice of your world, at the level of 3D chunks. Greedy mesh it: gaps are any 3D chunks with gaps in their 'shell'. Remember the greedy mesh polygons. When rendering a chunk, intersect its AABB's corner verticles with the plane of the slice. If all verticles fall inside a greedy polygon and are behind the plane, rendering can be skipped.

i wish i knew a better way to approximate the bounding rectangle of these AABB cubes. atm i'm using an extremely generous buffer to make sure nothing is considered offscreen when it's not actually offscreen in my first pass, but that means i wind up doing a lot of matrix multiplications for corners of subchunks that aren't on screen

lol. it is *much* more effective underground. at 12 chunk radius fps goes from 45 to 230 😊

(big occluders in your face helps cull a lot of chunks)

i'm going to write a software rendered occlusion culling mechanism for block game 😤

lol. it is *much* more effective underground. at 12 chunk radius fps goes from 45 to 230 😊

(big occluders in your face helps cull a lot of chunks)

i wish i knew a better way to approximate the bounding rectangle of these AABB cubes. atm i'm using an extremely generous buffer to make sure nothing is considered offscreen when it's not actually offscreen in my first pass, but that means i wind up doing a lot of matrix multiplications for corners of subchunks that aren't on screen

@eniko so, disclaimer, I don't know if this is useful advice to your situation, but I found these to be handy on a project I worked on a while back:

https://lxjk.github.io/2018/03/25/Improve-Tile-based-Light-Culling-with-Spherical-sliced-Cone.html

https://wickedengine.net/2018/01/optimizing-tile-based-light-culling/

iirc we used a modified version of the spherical-sliced cone test combined with the tile depth bitmask strat for dealing with depth discontinuity. this was for culling reflection probes though, not objects.

@eniko is there a reason why you're not using the typical hierarchical z buffer approach?

@bnut yes, all cubes are 4x4x4 or 8x8x8 blocks in size

@eniko I want to say we used AABB and sphere tests as coarse tests, and anything that survived the initial elimination got a more expensive test that miiiight have just been the spherical slice test, but I'm remembering something about calculating a culling primitive in object space instead of world space and getting a major win from that, but I can't remember what that was about and I don't think it was this.

lol. it is *much* more effective underground. at 12 chunk radius fps goes from 45 to 230 😊

(big occluders in your face helps cull a lot of chunks)

ok so two ideas:

1. i should be culling in world or view space, which is more reliable and cheaper

2. for projecting corners i think i can cut out some operations when doing the world->screen transform since all i care about is screen x/y and some relative depth, not actually normalized depth like for a depth buffer so i can actually use linear view space distance