Yeah, stuff like checking lots of polys etc is a bad idea for python. It's just not fast enough for things like that.
Some diagrams would be nice, I really wat to get some culling into the engine! I'll do as much as I can, which isn't much, when I get blender compiled.
I'm afraid I've got to apologise, guys. I had a go at creating some diagrams this afternoon, and in doing so realised that my idea was flawed.
I don't think it would work any better than the old-fashioned method of dividing a level into a cubic mesh and simply listing all polygons visible from any point in each cube. (at the moment, that is. I'm still trying to find a way to make it work properly, so don't give up all hope yet!)
There is one, single point in my original proposal that still stands....the method I just described is currently only used for static level meshes that never move. Characters and other "entities", to use the lingo of the FPS level designers, are not optimised.
This should not be the limit of optimisation, in my opinion. Every mesh should be optimised, including dynamic meshes that can change shape. All you need is an extra dimension in the matrix representing the grid which allows a separate visibility grid to be generated for each frame of the morphing ipo. Each grid should be centred about the object centre, and camera position relative to that centre used to look up the visibility data.
This allows, among other things, the generation of large scale, non-rail following vehicles that can be piloted around a game environment, landed anywhere, and used as a base, and can be walked around, while in motion or landed, by the player, eg airships, sailing ships, spaceships, submarines, airliners, trucks, train carriages, tanks, etc...