koobas.hobune.stream
Occlusion culling in levels generated at runtime
I'm creating a FPS maze game where the maze is generated pseudo randomly at runtime.
I would like to take advantage of occlusion culling as the number of draw calls can become very large as the maze size grows.
Now obviously I can't bake at runtime, but I was hoping to get some input on alternatives (if not to use occlusion culling, to at least achieve a similar affect).
The following are the ideas that I had to reduce draw calls (though I do not know if they would slow things down with the overhead they would add).
1) Add a fog affect to limit view distance, a sphere could be used to turn off the mesh renders of any object outside the sphere and turn any objects on inside the sphere. It would not be as good as real occlusion culling, but it would restrict the range at which the engine was drawing unnecessary objects.
2) Merge meshes into very large meshes but break them up into smaller chunks when the player gets near for better lighting effects. When the player passes away they can remerge.
I don't know if anyone has tried anything like either of these ideas, or if they have any other solutions. Any input would be appreciated.
Doom 3 based occlusion areas and portals might be the perfect solution for procedural mazes.
I was unable to find any such C#/Unity variations of it.
Edit: Here is my implementation, it has very simple ConvexPolygon (idWinding) and Area classes.
My game Realmaze3D generates meshes at runtime, where the meshes are broken into sections made of 4x4 squares. (That can actually be set to arbitrary numbers, but 4x4 seemed like a good balance; a normal-sized maze has about 60 pieces total.) Whenever the player turns or moves, the game scans the maze array from the player's position and turns on the pieces that should be visible. Essentially it's a primitive form of real-time occlusion culling, but it's very fast and typically results in only a few draw calls at any given time.
Your first idea is superfluous, since Unity's frustum culling already does this. If you just set the camera's far clip plane to the point where the fog becomes 100% opaque, then you don't have to do anything else.
Your second idea is sort of what I did, minus the merging/breaking/remerging part. Frankly there's not much point doing that, since you can't generally see very far in a maze, so you might as well leave the chunks separate. Just a relatively basic visibility routine like I used is fine.
The point of the second idea was that you couldn't see far. By combining them I would hope to reduce the number of draw calls. As for the second idea I had not realized that fulstrum culling also deals with distance (though I really should have).
I guess I'm not completly clear about what you did. You said it was like my second idea $$anonymous$$us the breaking merging, but there isn't much to the idea beyond that. Are you just saying that you broke/merged things at generation.
The array thing seems like it could work for me. Of course the issue is co$$anonymous$$g up with the algorithim to run through it.
What I mean is that each 4x4 section of the maze is a separate mesh. If the maze was a single floor that was 8x8 squares in size, then there would be a total of 4 meshes. The visibility routine "looks" down hallways and turns meshes on as appropriate.
