i'm going to write a software rendered occlusion culling mechanism for block game 😤
-
i have my plan all laid out
@eniko I'm heartened to see recognizable pseudocode; I feel slightly less incompetent and old.
Aside: Are you familiar with the testing/behavior-driven-development language Gherkin? It's a loose but formal pseudocode for translating requirements into tests https://leantest.io/blog/exploring-gherkin-syntax-for-testers-and-developers
-
@eniko I'm heartened to see recognizable pseudocode; I feel slightly less incompetent and old.
Aside: Are you familiar with the testing/behavior-driven-development language Gherkin? It's a loose but formal pseudocode for translating requirements into tests https://leantest.io/blog/exploring-gherkin-syntax-for-testers-and-developers
@arclight nope, this is the first ive heard of it!
-
i have my plan all laid out
oh no it's only partially done and it's already slow ðŸ˜
-
@eniko I'm not familiar with this RPG programming language. What is this written in?
-
@arclight nope, this is the first ive heard of it!
-
-
oh no it's only partially done and it's already slow ðŸ˜
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 >_>;
-
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 >_>;
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 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
@eniko bounding spheres?
-
@eniko bounding spheres?
@canacar doesn't work, corners might extend past the sphere due to perspective which means it's not a conservative enough metric https://zeux.io/2023/01/12/approximate-projected-bounds/
-
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 a projected cube is always going to be an irregular convex hexagon (or in the axial degenerate case, a rectangle). you can test other corners against the hexagon's edges (or the planes into the screen that they form) only slightly more expensively than testing against a bounding rect, and it doesnt under-cull
-
@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.
@eniko (this can be repeated with as many or as few slices as you like, and the intersection tests could be made *extremely* quick)
-
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)
-
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)
@eniko thank you occluders
-
undefined aeva@mastodon.gamedev.place shared this topic on
-
i'm going to write a software rendered occlusion culling mechanism for block game 😤
@eniko is there a reason why you're not using the typical hierarchical z buffer approach?
-
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)
@eniko
So the obvious performance hack is to set your game in the 1870's and the player character is a horse wearing blinders. -
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.