i'm going to write a software rendered occlusion culling mechanism for block game 😤
Uncategorized
56
Posts
15
Posters
197
Views
-
@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. -
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!
interestingly, if i switch from 4 subchunks per axis (64 per chunk) to only 2 (8 per chunk) the entire occlusion culling pass finishes in just 7ms even on my underpowered workstation at 12 visible chunk radius
unfortunately the culling% does go down from 71% to 57% and so fps goes down from 110 to 90, but that might be worth the trade off 🤔
-
interestingly, if i switch from 4 subchunks per axis (64 per chunk) to only 2 (8 per chunk) the entire occlusion culling pass finishes in just 7ms even on my underpowered workstation at 12 visible chunk radius
unfortunately the culling% does go down from 71% to 57% and so fps goes down from 110 to 90, but that might be worth the trade off 🤔
even if i set the visible chunk radius to 16 (which is quite far!) the occlusion culling runs in 11ms* and my fps above ground is 55
which i would say is solid for this early in the project
*with 8 subchunks per chunk
-
@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?
-
even if i set the visible chunk radius to 16 (which is quite far!) the occlusion culling runs in 11ms* and my fps above ground is 55
which i would say is solid for this early in the project
*with 8 subchunks per chunk
Oh. Most of the gains are from the frustum culling. I can cull a significant % of chunks if I use 64 subchunks per chunk, but that is also very very slow. But it does bring cull % up to like 75%
But just frustum culling chunks culls like 45-50% of chunks and is very very fast :|
8 subchunks per chunks is just a regular amount of slow but also not very effective
So hm. Well I guess at least I learned how to do efficient frustum culling? Womp womp 😔
-
Oh. Most of the gains are from the frustum culling. I can cull a significant % of chunks if I use 64 subchunks per chunk, but that is also very very slow. But it does bring cull % up to like 75%
But just frustum culling chunks culls like 45-50% of chunks and is very very fast :|
8 subchunks per chunks is just a regular amount of slow but also not very effective
So hm. Well I guess at least I learned how to do efficient frustum culling? Womp womp 😔
oh hey i got it down to 54ms from 93 at 16 visible chunk radius with 64 subchunks per chunk by only processing subchunks that have visible faces
i was using visible *blocks* before. but a theoretically visible block (not void/air) surrounded by blocks has no visible faces, so can't actually be seen
-
oh hey i got it down to 54ms from 93 at 16 visible chunk radius with 64 subchunks per chunk by only processing subchunks that have visible faces
i was using visible *blocks* before. but a theoretically visible block (not void/air) surrounded by blocks has no visible faces, so can't actually be seen
oops i had a bug that was causing a bunch of subchunks to not get occluded when they should be. so now the number of depth occluded subchunks is up by 50% and there's 1 depth occluded subchunk for every 2 frustum culled subchunks
-
oops i had a bug that was causing a bunch of subchunks to not get occluded when they should be. so now the number of depth occluded subchunks is up by 50% and there's 1 depth occluded subchunk for every 2 frustum culled subchunks
Had an idea to try tomorrow
Only render occluders nearby the camera and skip depth culling, because far away occluders will be tiny and unlikely to occlude much
Then depth cull far away (sub)chunks, since they're tiny and so only cover a few pixels and so are more likely to be culled
-
Had an idea to try tomorrow
Only render occluders nearby the camera and skip depth culling, because far away occluders will be tiny and unlikely to occlude much
Then depth cull far away (sub)chunks, since they're tiny and so only cover a few pixels and so are more likely to be culled
Actually it could be interesting to treat subchunks like mipmaps 🤔 so level 0 is 1 block per subchunk, level 1 is 2, 2 is 4, 3 is 8 and 4 is the whole chunk
Then I can use lower levels up close for better occlusion and higher levels far away for quicker culling
-
Actually it could be interesting to treat subchunks like mipmaps 🤔 so level 0 is 1 block per subchunk, level 1 is 2, 2 is 4, 3 is 8 and 4 is the whole chunk
Then I can use lower levels up close for better occlusion and higher levels far away for quicker culling
aha! i might be onto something! only rendering occluders into the depth buffer for nearby subchunks and only depth culling far away subchunks dropped the run time from 0.21x original to 0.14x original
i bet if i reduce the number of subchunks far away by making subchunks larger i can get even better gains
-
aha! i might be onto something! only rendering occluders into the depth buffer for nearby subchunks and only depth culling far away subchunks dropped the run time from 0.21x original to 0.14x original
i bet if i reduce the number of subchunks far away by making subchunks larger i can get even better gains
so uh, wow, holy shit!
my new subchunk levels method (where each level is smaller) is a 7x improvement over my last attempt, and my software occluder now runs in 0.02x the time it did before i started optimizing. in other words, it runs 50x faster now! for 12 visible chunk radius its down from 155ms to fucking *4*
interestingly though, even though i have 3 levels, 16, 8 and 4 blocks, i didn't even need the middle level. i just switch straight to whole chunks for depth occlusion
-
so uh, wow, holy shit!
my new subchunk levels method (where each level is smaller) is a 7x improvement over my last attempt, and my software occluder now runs in 0.02x the time it did before i started optimizing. in other words, it runs 50x faster now! for 12 visible chunk radius its down from 155ms to fucking *4*
interestingly though, even though i have 3 levels, 16, 8 and 4 blocks, i didn't even need the middle level. i just switch straight to whole chunks for depth occlusion
in hindsight this makes sense. occluders should be small, since they set up the depth buffer, but then occlusion culling can be done on whole chunks since it doesn't matter how big the area you're testing at one time is so long as the occlusion map is filled up properly
so next i might try rendering single blocks into the occlusion map and depth culling entire chunks always and see how that performs
-
in hindsight this makes sense. occluders should be small, since they set up the depth buffer, but then occlusion culling can be done on whole chunks since it doesn't matter how big the area you're testing at one time is so long as the occlusion map is filled up properly
so next i might try rendering single blocks into the occlusion map and depth culling entire chunks always and see how that performs
16 visible chunk radius now runs at 68 fps above ground (1 short of being truly nice 😔) and the occlusion culler runs in only 5ms
-
16 visible chunk radius now runs at 68 fps above ground (1 short of being truly nice 😔) and the occlusion culler runs in only 5ms
simplified everything and split occluders from depth culling candidate chunks
also trying to be more picky and granular about what occluders to use, so now i'm rendering single blocks nearby the camera. hopefully more granular occluders will improve the culling percentage
-
simplified everything and split occluders from depth culling candidate chunks
also trying to be more picky and granular about what occluders to use, so now i'm rendering single blocks nearby the camera. hopefully more granular occluders will improve the culling percentage
you can call me weird but it is very fun to build a little box around myself and watch my fps go up from 110 to 450 because of the depth occlusion system
-
you can call me weird but it is very fun to build a little box around myself and watch my fps go up from 110 to 450 because of the depth occlusion system
hmm hmm so my subchunk levels go 1³, 2³, 4³, 8³, 16³
but im betting anything above 2³ is gonna be exceedingly rare since a new requirement is having a block with an exposed face. though i havent tested this
but i feel like maybe 1³, then 2²x1 4²x1 8²x1 16²x1 for each axis would probably work a *lot* better given how human construction tends to go
and also ground planes/cliff faces
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@lisyarus to put it another way, the version on the left looks like it is like 20% of the way to being really slick diorama water, and the version on the right looks like it is 80% of the way to being windwaker water.
-
@eniko (classics include Big Top https://en.wikipedia.org/wiki/Big_Top_(video_game) , Prince of Persia 1 and 2, Doom, ZOOL and ZOOL2, Bananoid, Future Wars, Lemmings, Pipe Mania https://en.wikipedia.org/wiki/Pipe_Mania , Mortal Kombat 3, North vs South, Secret Service II)
-
Lewdbrarian: Will that be all, sir?
Me: I... The other day I was thinking of an old jav idol... The one with the sexy...
Lewdbrarian: That is Sally Yoshino, sir.
Me: And... do we perhaps have any vi
Lewdbrarian: You should look in the gray drive, sir. I trust you remember the password.
Me: yes. yes.
Lewdbrarian: We do not have any video. But there are pictures saved from usenet. Just look under ..\Alt\Binaries\Pictures\Jav\Y\
Me: Thank you.
Lewdbrarian: Glad to serve, sir.
-
@eniko OK so here's SOME that I keep in my DOSbox because of nostalgia:
https://en.wikipedia.org/wiki/Blackthorne which I loved for the “shoot behind your back” gesture
https://en.wikipedia.org/wiki/Fiendish_Freddy%27s_Big_Top_o%27_Fun where you have to play circus tricks while a capitalist sabotages your actions because he wants to buy the circus.
HoverTank, a shareware game that you can find here https://cheesysoftware.net/alphaomega/index.html that allows hotseat 1vs1 play (it's tanks shooting at each other, very fast, very funny sounds)
and then some classics.
-
@lisyarus I like the depth dependent water better. I think it wants to be fancier though, like maybe fake caustics in the shallows, blur the depths, something on the shore line, some surface wiggle + some specular highlights.
I think the reason the plain version doesn't feel like it is missing anything is because it doesn't really look like water beyond being symbolically recognizable as semantic water. The plain version would actually be better if it was opaque imo.
-
Some other #MastoBlaster screenshots, from the emulator
-
Lewdbrarian: I suggest a quick search to confirm, since this particular memory is over 40 years old by now.
Me (after check): Yup. Yup. It checks out.
Lewdbrarian: I am glad I could be of service, sir.
Me: Hey... Uh... You wouldn't happen to remember where we saw that last now, would you?
Lewdbrarian: I am so very sorry, sir. Records of VHS titles specially those not fully watched have been purged. Since we no longer own any tapes, or devices to play them. I hope you understand.
