I highly doubt that BSP is either neccessary or the most optimal way to render levels nowadays.
I would split my levels up into a set of objects, and then determine which of those objects are visible from a particular area at a particular time.
However, when doing this, you must pack as many polygons into as few surfaces as possible. Surfaces slow stuff down. But having a ton of polygons in an object which is halfways off the screen is also a waste.
So you have to balance the size of your objects with the limitation of using as few objects/surfaces as possible.
I would try to split my level up into "rooms". A "room" might be a square section of terrain. I would then combine all objects in the room which will not be animated but use the same set of textures into a single surface. For example, if I had trees in a "room", all their trunks would be one surface, and all their leaves would be a second surface with an alpha map.
But if I had chairs in a room, and I wanted those chairs to be affected by physics, then I would make the chairs invidual objects as they need to be animated.
Then I would split the level up into a grid, or a set of cubes that each contain a room, and figure out which other rooms the player can see from a particualr room and store that so I know which entities to hide and which to show. I would also consider hiding sub objects in rooms which are far from the player that are unlikely to be seen.
I might even make two levels of detail for each room, one for closeups, and one for when the room is in the distance. This might contain a list of which objects should be hidden in the room when it is in the distance as well, and those objects would not have lower detail models. Then I could reduce the cost of rendering stuff far away.
My foliage system took an extra step with actually combining rooms in the distance into larger objects with fewer polygons per room combined into this object. But if you have lots of levels of detail, this can be costly which is why I suggest only two levels and making the transition far enough away that it won't be obvious.
I would split my levels up into a set of objects, and then determine which of those objects are visible from a particular area at a particular time.
However, when doing this, you must pack as many polygons into as few surfaces as possible. Surfaces slow stuff down. But having a ton of polygons in an object which is halfways off the screen is also a waste.
So you have to balance the size of your objects with the limitation of using as few objects/surfaces as possible.
I would try to split my level up into "rooms". A "room" might be a square section of terrain. I would then combine all objects in the room which will not be animated but use the same set of textures into a single surface. For example, if I had trees in a "room", all their trunks would be one surface, and all their leaves would be a second surface with an alpha map.
But if I had chairs in a room, and I wanted those chairs to be affected by physics, then I would make the chairs invidual objects as they need to be animated.
Then I would split the level up into a grid, or a set of cubes that each contain a room, and figure out which other rooms the player can see from a particualr room and store that so I know which entities to hide and which to show. I would also consider hiding sub objects in rooms which are far from the player that are unlikely to be seen.
I might even make two levels of detail for each room, one for closeups, and one for when the room is in the distance. This might contain a list of which objects should be hidden in the room when it is in the distance as well, and those objects would not have lower detail models. Then I could reduce the cost of rendering stuff far away.
My foliage system took an extra step with actually combining rooms in the distance into larger objects with fewer polygons per room combined into this object. But if you have lots of levels of detail, this can be costly which is why I suggest only two levels and making the transition far enough away that it won't be obvious.