Mass slowdown when objects near front edge of screen

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.

Nutty

I have a GeForce 2MX.
Resolution 800x600 16bit.

I have tried the program in window and fullscreen but I havent tried the scaling window thing, thanks for the suggestion I will give it a go.

Thanks for your reply

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.

I have tried lowering the size of the window and yes everything runs smooth. Just limited to the refersh rate of the monitor(75 Frames per second.)

I am drawing a very simple car axle 100 times.
Polygon count in total 15,600 triangles.
(No Textures)

I am also drawing 4 wheels which in total have 288 triangles and are textured.

This reason I tried doing this in the first place was to see how many polygons I could use for my scenery/landscape.

Its a bit annoying as the code so far runs beautifully smooth when the car is further into the screen.

I guess it’s limited by the fill rate.

How do I sort the polys from front to back?

I currently use polys which have been setup using 3D exploration.

Thanks again.

[This message has been edited by royster (edited 06-07-2001).]

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.

Official M$ WHQL 12.41 drivers are available now. I’ll be f***ked if I can download them though… must be a surge of people trying to get them!!

Nutty

>>The GF2 MX card(s) are limited in fillrate AND TnL performance<<

every single card ever invented is fillrate + geometry limited

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.

Tim