Let's assume that I created in Blender a race track with landscape. I can export it to single wavefront obj file and then load in my graphics engine using assimp but it doesn't allow to use frustum culling. Should I split such big scene too seperate objects or some model formats allow to split object within single file. How graphics engines load such big scenes ? Do you know some useful techniques/articles ?
In short, yes, you should split the scene. But I would advise that you use a more programmatic method rather than splitting by hand. And as below, will document my own approach and thoughts. You will reach your own conclusions on what you want to do, I hope this is guide in what does and doesn't work.
A lot of game engines to pre-process their scenes prior to use in, quake developers actually had a BSP tool that used to take the original editor maps and convert them to BSP files (Binary space partitioning). Some games just in-game cut the world up there an then, I personally went the preprocess route.
There are a few very tried and tested methods, mostly using tree structures (Binary, Quad and Oct are the most popular), Rastertek has some great tutorials on how to use your your cut up terrain, just search for "quadtree implementation", lots of tutorials on that. Before you go and do this, understand that each has its pros and cons. There are other methods apart from this ,but I will only go on what I have done so far.
There is a wealth of documentation and tutorials out there on how to technically do each of these approaches. So I will go with what I have done in my own game.
For my own implementation, I went with a quad tree, which seems to lend itself well to terrain. Although in 3d, terrain using quad trees seems to work well. In my implementation, I cut the world up into a grid (X/Z plane, Y is height, I did not cut it up vertically). The approach was to firstly to create a bounding box, divide this into 4 equal sized child boxes and bin the geometry based on the median of the triangles into each box they were contained within. I would then regenerate the bounding box for each node, I repeated this until I had an acceptable breakdown of geometry (this is subjective on the type of game you have, my view is a fixed point.).
Finally, I would then in game each frame, traverse the tree, testing the bounding box as each node against the camera Frustum, when eventually a node would be found outside the view I would then mark it as culled, and traverse the rest of the children and mark them as culled.
- I selected a Quad tree implementation because of the game view. If had more vertical terrain, I may have leaned towards Oct trees.
- A tree implementation lends itself to assisting with culling of static assets also. I took advantage of the tree structure to add other attributes to the leaves.
- My implementation ignored some of the more advanced concepts, such as cutting geometry up where it crossed over planes.
- Of note, ensure that you aren't putting repeated assets into your mesh like trees or walls. Anything that you put in that occurs multiple times, I suggest you use instancing so that you gain the advantage of drawing these assets quickly. I attached the instancing flags to the leaf nodes, so when I culled the box, I culled all the instances of assets in that part of the scene.
- Finally, plan it. I wish I had done this more, I spent time refactoring my game engine over the past 3 years to add more functionality. No, you don't have to implement everything you desire, but leave it open enough.
Most of this is my experiences. But at the end of the day, yes, you will need to commit time to this pursuit. Good luck.
Note: I will post some screenshots later of the culling in my game to give you an idea of how my efforts panned out.