By the way there was NO culling - not even on the camera distance!
When me and my dad added camera distance culling, our scene of 1000 cubes went from 10 fps to 20.
I cant believe they didnt even cull based on camera distance…
seriously?!? :o
i guess i just assumed the clipping distance on the camera actually culled 
in which case sonix, if you’ve got a big scene then anything’s probably a good idea 
cheers
Piran
By the way there was NO culling - not even on the camera distance!
When me and my dad added camera distance culling, our scene of 1000 cubes went from 10 fps to 20.
I cant believe they didnt even cull based on camera distance…
Maybe speed wasn’t a priority and neither was graphics quality, features, only ease of use…yeah…the game-engines programmers really knew what they were doing! 
in which case sonix, if you’ve got a big scene then anything’s probably a good idea
Yes! When I added simple culling to one of my test games, it increased the framerate dramaticlly!
Someone should do some sort of realtime culling script. I’ll go ask in the python forum. That could dramatically increase the speed of our games!
Pooba
I have again been searching for a solution to this problem, and I have found a few scripts that could possibly be adapted.
This is a system that only renders the normals that are facing the camera, ‘Fast Backface Culling Using Normal Masks’, a paper by Hansong Zhang and Kenneth E. Hoff III.
Web page:- http://www.cs.unc.edu/~zhangh/backface.html
PDF :- http://www.cs.unc.edu/~zhangh/backface.pdf
Code for algorithms described in the PDF
http://www.cs.unc.edu/~zhangh/bfcsrc/nmask.h
http://www.cs.unc.edu/~zhangh/bfcsrc/nmask.C
http://www.cs.unc.edu/~zhangh/bfcsrc/encode.C
Another method:- http://neptune.cs.byu.edu/egbert/a3glab/papers/Voxel_Column_Culling.pdf
And another:- http://www.cis.ohio-state.edu/~crawfis/cis781/Slides/VisibilityCulling.ppt
A few more algorithms for culling:- http://www.flipcode.com/harmless/issue01.htm
And one more, Frustrum Culling tutorial with code included:- http://www.flipcode.com/articles/article_frustumculling.shtml
Are these methods of any use?
Sonix.
opengl does backface culling
I would expect frustrum culling to come with the next revision of the game engine. I thin there are at least two people eager to implement it.
(in laymen terms frustrum culling doesn’t draw objects that are not in the canera’s view)
That would be me and my dad. Zarf was going to if we forced him to and no one picked it up, but I convinced my dad to “help” me do it. By help, I mean program it all himself;)
It’s still slow going, but we should at least have these:
*distance culling - implemented
*quadtrees - generation complete, but wont work until we implement
*frustrum culling - havent started
So we’re kind of in the middle there, halfway between being started and having something cool that works.
If we are able to after that, probably try out octrees, bsp trees, portals, etc.
But simple stuff first.
Saluk, that’s superb news. If I can help in any way, let me know.
Sonix.
Please explain these! Portals? Like in Serious Sam?
I have never even heard of a thing called octree or bsp tree!
BTW, to those who have played serious sam or know something about realtime graphics, i have found a fake way to make bump maps. I´ll post some of my FX somewhere as soon i can finish my school projects.
octrees - imagine a big cube around the level. Now subdivide to give 4 smaller cubes. Keep subdividing until the poly-count within each cube is within an acceptable limit (or you reach a certain number of subdivides). Then, when in realtime, work out which of those cubes is within the cameras view and draw only the polygons contained within them. Octrees are quite fast to calculate, they don’t require massive pre-compiling of the level before you play it and are quite efficient although BSP is better for indoors.
darnit, i’m late, sorry gotta go…
cheers
Piran
What sort of speed increases are we talking about with this culling? 2x? 3x? or even more?! That would be great!
Fake bump maps can be made by rendering an image of a wall with a bump map, then using that rendered image as a game texture.
Keith. 8)
You could also fake a bump map by using a lot of polygons:)
oh great! bump mapped meshes are fake high polycount meshes, and now you want to fake a bump map using a high polycount mesh? sort of like a fake-fake high polycount mesh, that actually IS a high polycount mesh!
the speed increase resulting from good culling algorythm(s) can be very significant.
It isn’t unheard of to at any one time be only drawing about 300 triangles when the scene is composed of greater than 5000 (or more)
if the scene were made of 50 000 triangles many computers would not run well without a culling algorythm that takes the triangles drawn to below 1000
1000 is almost a resonable number of triangles for most systems to draw
does anyone have an idea on why my comp. does that? (check my first reply on the first page)
the number of polygons is not the only thing that can slow your game down
too many objects, too many collision faces, alpha faces, complex game logic, slow python, other programs running, unfreed memory from another program…
the list goes on and on
I have had differences on my computer in speed from 11 to 111 fps, on the same file. It isn’t blender (entirely), but there are too many variables for me to track it down
True, but some of those things you mention are a relation to the number of polygons. Collisions faces and alpha faces for instance. Although culling polygons wont help collision faces (you’ll have to use some in-game method to cut down on those) they can help with alpha faces, if the alpha faces aren’t directly in front of you:)
But there are definately many variables that affect speed. You can only be so efficient, and then it’s up to the content you develop and the hardware its being run on.