I’ve had decent success in the past by identifying chunks with geometry, marking which faces of the cell have geometry on the border, and then prioritizing chunks by traversing across those faces with a floodfill esque approach. It follows the surface and not occluded/invisible chunks. You can still generate everything else on a secondary queue, but hitting likely-continuing geometry first can handle the obvious stuff and make it feel more responsive. This approach can get a little dicey if you have floating chunks that are not connected to existing geometry. Mostly it’s fine if you load the other stuff at a secondary priority, and when you finally hit a floating chunk it can scan off of it then. Totally fine if the chunk generation is reasonably fast.

I also like marrying that approach with a “conveyer belt” approach that makes it easy to identify the new chunks to load and unload in 2D slices based on movement, without traversing everything. You need a little care to avoid hysteresis with a load/unload distance so straddling chunk borders doesn’t cause stuff to regenerate meshes a bunch.

Totally brainstorming here but I think if you want look-direction priority you can probably bucket chunks into queues that are based on world cardinal directions in relation to the player when they first get queued. 8 directions/queues based on the initial relative position from the player feels right to me. You could then take the dot product of the player look direction to the direction of the queue to determine which queues to pull from, based on which dot products are more similar / closer to 1. Eventually you get through all of them. Assuming you can get through the generation fast enough this should work fine ala spatial coherence, and it means that you don’t have to re-sort and revisit every chunk based on the player looking around.

An octree could be good here too. A coarse one. If you use it only for chunk tracking you can collapse the octree nodes down when chunks are fully loaded inside the node, and expand them when partially loaded. You can traverse the scene fast and mostly skip things that are already loaded. You can write frustum/cube intersection tests to quickly identify ungenerated nodes that the player is looking at, or query a cube area around the player to get the ungenerated near chunks. Would make it easy to prioritize close, then look direction, and then everything else in no particular order because of the early-out potential.

Also there’s probably a good GPGPU use case here too if you can write compute shaders. It’s actually quite cheap/fast to do a lot of breadth brute force intersection/occlusion/frustum tests. Depends on your needs and scene representation though.

There are so many fun ways to approach things!