serene knot
A while ago, I made a virtual terrain rendering system. It works really nicely and looks great imo. The main issue from keeping it from looking 100% is that tile rendering is slow. I only render 1 tile per frame, and ideally, the system should pick the tile that needs updating the most. Right now I calculate this on the CPU by looping over the tiles and picking the one that takes the most screenspace (kinda). The thing is, this calculation only involves calculating its world XZ (Y is up) size and projecting that as if it were a plane facing the camera, then calculating its size based on that.
This is obviously a flawed approach as terrain is mostly flat, and this system approximates tiles as mostly vertical. This whole system is typically handled by rendering the terrain to a low res screen texture, where each color represents a different tile, then looping through the pixels, selecting the largest tile. That tile is then rendered and it is known for a surety that is the biggest on screen tile.
However, I am on mobile, and swapping framebuffers is best avoided, further, the algorithm is just a bit slow, especially having to render the entire terrain twice per frame (although of course the one rendered for the low res screen could be simplified.
So just trying to find the best solution, ideally one that exists on the CPU for a small cost.
atomic garden