Investigate unorthodox rendering strategies for GL

[bkoropoff]

Looking at CPU profile data, BSP tree traversal is very expensive considering the amount of geometry it feeds to the GPU. It made sense for using the painter's algorithm to render small maps in software in 1993, but when you have a Z buffer and a GPU that can render billions of triangles per second from vertex buffers, it's not so great.

The developers of Helion apparently came to the same conclusion and ditched BSP traversal (for rendering) with good results.

[bkoropoff]

Hybrid strategies are also possible, e.g. update visible flats/segs/sprites with the BSP tree in a separate thread as the player moves and have the main thread render from the most recent cached result. With some care it should be possible to avoid the player being able to see pop-in unless they're noclipping, etc.

BSP traversal itself is also possible to make multi-threaded for GL. Since it's just generating a list of render commands, there's no reason different branches of the BSP tree couldn't be farmed out to a pool of worker threads. Avoiding lock contention would require some care.

[kraflab]

While we're talking about new strategies, what's your opinion on the idea of writing a whole new renderer in vulkan and removing opengl entirely? 😄

[bkoropoff]

Vulkan might be overkill until CPU bottlenecks other than graphics API calls are reduced. Having access to more modern features would be nice, though.

[bkoropoff]

Prototyping portal-based rendering

[bkoropoff]

293 now includes an experimental portal-based renderer