i'm going to write a software rendered occlusion culling mechanism for block game 😤
Uncategorized
36
Posts
15
Posters
4
Views
-
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.
-
@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 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.
-
@eniko is there a reason why you're not using the typical hierarchical z buffer approach?
@lritter as far as I know that requires reading data back from the gpu in a way that I don't have access to with FNA
-
@bnut yes, all cubes are 4x4x4 or 8x8x8 blocks in size
-
@bnut yes, all cubes are 4x4x4 or 8x8x8 blocks in size
@bnut (as in I set a constant whether I'm doing 2x2x2 subchunks per chunk or 4x4x4)
-
@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
-
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
simplified my world->screen transforms. instead of doing a 4x4 matrix multiply then dividing by w and multiplying by buffer size (21 multiplies) i switched to a view matrix, view transform the position, then project to the screen manually (13 multiplies) and use view distance instead of depth since i don't care
and it now runs in about 2/3rds the time it did before :D
-
simplified my world->screen transforms. instead of doing a 4x4 matrix multiply then dividing by w and multiplying by buffer size (21 multiplies) i switched to a view matrix, view transform the position, then project to the screen manually (13 multiplies) and use view distance instead of depth since i don't care
and it now runs in about 2/3rds the time it did before :D
changed the way i cull subchunks courtesy of @bnut. i extract the world space frustum planes from my view-projection matrix, normalize, then do `dot(plane.normal, subchunkCenter) + plane.dist` and check against the bounding sphere radius (0.5*sqrt3*side)
occlusion culling now runs in 0.43x the time but also the culling is up from 43% to 74%, which means the game runs much faster. at 12 chunk distance fps above ground is up from 60 to 110!
-
changed the way i cull subchunks courtesy of @bnut. i extract the world space frustum planes from my view-projection matrix, normalize, then do `dot(plane.normal, subchunkCenter) + plane.dist` and check against the bounding sphere radius (0.5*sqrt3*side)
occlusion culling now runs in 0.43x the time but also the culling is up from 43% to 74%, which means the game runs much faster. at 12 chunk distance fps above ground is up from 60 to 110!
@eniko These probably count as optimizing more than needed, but a few suggestions:
1. test without the early out and see if it's faster. It's more ALU work, but because of how deeply pipelined CPUs are you really want to keep the code flow in small loops very predictable.
2. assuming you're targeting 64-bit platforms, you should have access to SSE2, which would let you test 4 chunks against the view frustum at once. Depending on how the memory latency works out, that can net another 2-4x. -
@eniko These probably count as optimizing more than needed, but a few suggestions:
1. test without the early out and see if it's faster. It's more ALU work, but because of how deeply pipelined CPUs are you really want to keep the code flow in small loops very predictable.
2. assuming you're targeting 64-bit platforms, you should have access to SSE2, which would let you test 4 chunks against the view frustum at once. Depending on how the memory latency works out, that can net another 2-4x.@ataylor @eniko does C# have something like loop unrolling directives? That static 4-times loop looks like a prime candidate for it, although I guess doing it by hand with only 4 elements might still be acceptable, assigning the comparison to 4 bools and skipping the last instruction if any is false, or something like that?
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@catsalad I like that this poll is multiple-choice
-
-
#SelfHosting week 1, phase 4. FINALLY.
The main architecture is up and running now.
Lemmy, WriteFreely, Castopod, today I'll get WordPress multisite running; my current site on shared hosting, runs a singular website where I created multilingual through "FullSiteEditing" WordPress feature; but it's quite difficult to maintain in long-term so 2 sites with 2 languages will make it better.
Now I have upgraded my hosting plan to Hostinger kvm2, and associated my VPS to the huge lifetime 10TB cloud I have, for podcasts. PCloud, through rclone. Next phase will be WordPress, then maybe to point various services to the right domain (plusbrothers.net and not .online). Most passages have been done via command line, and to find the right commands I've used google gemini. Unfortunately for some features, American (big) tech has still been useful. #accessibility #selfhost #activitypub #blog #multilingual #blind #WordPress
-
@troberts it was the awesome metal you were listening to, right? the couch couldn't contain itself.
Pippin is helping it recover from the shock
-
@MelissaBearTrix does a small electric heater count?
-
@rufustheduck finding @dillyd right from the start is a nice find, one of the nicest posters here.
And posting cats is kind of an easy win here ;-)
Welcome, and have fun!
-
I'm loving the return of the light each morning. I don't notice so much in the evenings, but even a little light when waking changes the whole day. Come, Sun! Shine over us.
Photo: winged scarab carving from the Edfu Temple, Egypt, ~237-57 bc.
-
@hellomiakoda two paths I see are: drop the proprietary driver if mesa has decent enough support for your card, which should allow Wayland to work; or install a WM that still supports X11 and use that instead of KDE.
