I have car wheel in a display list and as a test I thought I would see how many of these wheels my computer could render smoothly.
What I have found which is really strange, is that when I have these objects being shown near the front of the screen (just about where they would normally start disappearing the frame rate drops considerably. Is this normal as the frame rate is high when the objects are moved more into the scene.
Is it OpengGL doing its clipping, if so is there any way to speed it up as it seems to function very slowly.
Thanks
Perhaps when the objects are up close, you’re filling the screen, and so you’re being fill rate limited in performance. When the wheels move away the fill rate demans decrease loads so performance goes up??
What type of card are you running it on? what res and color depth to? Try running it in a window, and shrink the window right down when the images are up close. If it speeds up, its a fill rate thing.
Sounds like fill rate problems but shouldn’t be with that spec. Try running at a low resolution (320*200), if the wheels are textured lower the texture reolution or disable textureing completly and see what happens.
How many polys are being displayed??
To help fillrate you can sort the polys from front to back (oposite to the traditional painters algo) this should maxamize the efficiency of the depth buffer reducing the fill rate.
The GF2 MX card(s) are limited in fillrate AND TnL performance because their memory is only SDR, whereas the other GF2s have DDR memory. The MX was manufactured to increase sales and sell for lower prices. It’s still better to get like a GTS though, because the MX costs ~9/16 (shh! I’m picky! :P) as much as the GTS, but for a little less than half the performance. Not only that, but if you’re using OGL for splines and crap, I think that OGL polygonizes based on LOD, and as you get closer, it would have to generate more polys, even though you can’t see nearly all of that which are being generated. Try getting the leaked Detonator3 12.xx drivers; they’re lots faster than the official 6.50 drivers at nVidia’s website.
I got the new 12.41 drivers, didn’t do much though on my little TNT2 m64.
To sort back to front you can use a BSP and do a revese traversal but the general way would be to calculate the average/centre z value for each polygon and do a very fast sort on them, a radix sort is the best for high no. polygon, other methods work better for small amounts of data. Sorting is even more important on cards with the hyper z thing like the GeForce 3. I am trying to figure the best way to do sorting with my octree, per a node mught be suffecient.