So the actual tris rendered isn't what the TrisRendered() command is reporting? Interesting, as I just ran a test using TrisRendered() which seemed to indicate that the CameraRange occlusion was occluding meshes rather than tris, which didn't seem right.
I also noticed a jump in the tris reported as being rendered when the center-point of a bot I had in the test arena came into view of the camera, which I thought should have happened instead when the edge of its bounding region (as used by Blitz's frustum culling system) came into view, particularly since I was only using the bot and a single mesh arena in the test so there was nothing else to throw the count out.
The system I was thinking of doing was just a quick and dirty system suited for simple indoor arenas built to work with it, probably similar to your range box system. Basically you'd set up a data structure which defined the arena as a set of overlapping spherical zones which would enclose arena sections. As the player moved from one zone to another, they'd be registered in the new zone. The maximum camera range would be adjusted mathematicaly so that it was relative to the centerpoint of the zone rather than the centerpoint of the player, possibly with additional offsets which adjusted the camera range relative to the camera direction to give more control over the shape of the zone.
The main purpose would be to be able to build quick and simple single mesh arenas, built for this system using rooms with limited line of sight.
It all needs fleshing out a great deal more though. And it would only be worth doing if the camera range occludes tris rather than meshes, which I hope it does.
|
