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

[eniko@mastodon.gamedev.place]

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

[eniko@mastodon.gamedev.place]

i have my plan all laid out

[riley@toot.cat]

@eniko I'm not familiar with this RPG programming language. What is this written in?

[eniko@mastodon.gamedev.place]

@riley this would be english >_>

[riley@toot.cat]

@eniko Oh.

[oblomov@sociale.network]

@eniko I've been working a lot with Inform7 these past days, so I can see why @riley would think it's a high-level programming language, that's basically exactly what Inform7 looks like.

[arclight@oldbytes.space]

@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@mastodon.gamedev.place]

@arclight nope, this is the first ive heard of it!

[eniko@mastodon.gamedev.place]

oh no it's only partially done and it's already slow 😭

[brouhaha@mastodon.social]

@riley @eniko
The RPG programming language, which actually exists (and that isn't what was shown) is one of the most awful programming languages ever created.

[korpiq@kamu.social]

@eniko @arclight I like BDD with Gherkin a lot. Too bad that so few work places work in ways that support such clear thinking.

[riley@toot.cat]

@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

[eniko@mastodon.gamedev.place]

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 >_>;

[eniko@mastodon.gamedev.place]

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

[brouhaha@mastodon.social]

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

[riley@toot.cat]

@brouhaha Not to be confused with: Informix. The "ix" is not Roman nine.

@eniko

[jsbarretto@social.coop]

@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.

[canacar@ioc.exchange]

@eniko bounding spheres?

[eniko@mastodon.gamedev.place]

@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/

[vfig@mastodon.gamedev.place]

@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