I added asteroids to my game levels now.
Asteroids are huge objects, about 3000 meters in diameter, that you can fly into. The fighter itself is 18 meters in diameter. The asteroid is about 40,000 polys.
My first approach was to render the physics geometry in the radar, and the regular mesh on the screen. However, my performance wasn’t very good – 50 FPS or so, about half of what I usually get on complex levels. There are about 500 boxes and 50 physics spheres for the large asteroid. So I stopped rendering the physics objects, figured out how to cut off the top of the asteroid, and render that instead. This brought me up to 60 FPS.
The next thing was that those 550 or so physics objects, even though they never render (visibility set to false), might still be processed through Ogre. While Ogre has many good qualities, efficiency isn’t one of its strongest strengths. So I deleted those objects after processing the physics bounds. This freed up some memory and got me from 60 to 62 FPS.
My next guess was that if any part of the asteroid renders, the whole asteroid renders, when in fact only the part you are looking at needs to be drawn. You only see a diameter of about 500 meters on the screen, about 1/(6^2) of the total asteroid, so there’s a lot of pointless vertex culling.
I decided to break the asteroid up into a grid, each cell of which is about half of what you can see on the screen. This means that at any given time it will render 4 cells. However, I went a little bigger and made each cell 800/2 meters. This is because I am anticipating a lot of players may complain the max camera zoom distance is still too low. If I made it higher later I wouldn’t want to resplit all the objects. At 400 meters per cell, and 3000 meters in diameter, this is slightly less than 8 cells on an edge, or 64 cells total. If I can render only 4 / 64 cells, this is a great improvement.
It took me a while to figure out how to do it in the modeling program. I eventually made an 8×8 grid of helper planes and split along each of these planes. After this, and rerunning the game, I now got 75 FPS. So someone with a machine half as fast as mine should still get at least 30 FPS, which is acceptable. (Actually it will be higher, as I was running the server too).
The problem as usual is this technique is too technically complicated for my artists to do. I’ll tell them to do it, and maybe get lucky, but I’ll give 10:1 odds they will mess it up somehow: the splits won’t be exactly 400 meters, won’t be evenly spaced, won’t be centered at the origin, splits will be missing, and/or it will take days and days. So I’m going to have to do it myself for all the models, just as I spent the last 3 days painfully creating physics geometry for every level and every asteroid.
One reply on “50 to 75 FPS”
with the splitting thing I’d seriously consider checking out the ‘dotSceneOctree’ project in ogreAddons CVS. It has a tool which takes a .scene file and automatically splits the geometry while also making a new .scene file placing each chunk back in it’s relative position.
The tool doesn’t make new polygons when splitting, unlike max’s cut functions, so the polys are ‘disconnected’ really, just depends how big individual polys are.
.scene is also identical to .osm, in fact if you search on the forums someone made a osm to .scene converter. But anyway, it would be trivial to modify dotSceneOctree to process osm files instead of .scene, or just export dotScene levels, which I suspect you wouldn’t want to change to at this stage (if you do, use the OgreMax tools)
I’ve used this on my racing game as the artist just happily models the whole world as one chunk, so this sped the game up alot without creating new polygons from the splitting process.