| ▲ | badsectoracula 6 hours ago | |||||||||||||
Unless you plan on rendering the level on some very retro hardware (think S3 Virge, maybe Voodoo 1) you can render the entire level in OpenGL with just zbuffer and alpha tested sprites and it'll run perfectly fine - if anything with such low polycount, chances are you're going to make the renderer slower by trying to do occlusion culling on any GPU released in the 21st century :-P. If you pack the geometry in a few vertex buffers (for each unique texture) even per-frame, you'll get four digit FPS in any relatively modern GPU. As an example this[0] video shows the benchmark from Post Apocalyptic Petra running on my previous GPU (RX 5700 XT) which all it does is build a per-frame (client-side) vertex-buffer in OpenGL 1.1 (the engine was made for actual retro PCs running DOS and Win9x so it does some rudimentary occlusion culling but that mainly affects 90s hardware, not anything released since 2000 or so). If anything, the rendering has so little overhead that half of the framerate is "eaten" by the FPS counter overlay :-P. | ||||||||||||||
| ▲ | sklopec 6 hours ago | parent | next [-] | |||||||||||||
That's really cool. Thinking about modern games, a single character model probably has more vertices than my entire level (and yours probably), so it's definitely reasonable to expect occlusion culling for such simple geometry might actually reduce performance rather than increase it. | ||||||||||||||
| ||||||||||||||
| ▲ | pjc50 4 hours ago | parent | prev [-] | |||||||||||||
The synthesis technique would be to build the DOOM-style BSP tree and then construct a bunch of meshes for use depending on which portal space you're currently in, but .. as you say, you don't need to do that because it's at most a few hundred polygons. | ||||||||||||||