An important optimization?
Blitz3D Forums/Blitz3D Programming/An important optimization?
| ||
| http://www.extremetech.com/article2/0,3973,1086862,00.asp I was just reading that... And it SEEMS that it indicates that the FASTEST way to render a scene where some polygons are occluded is to draw the potentially occluded polygons LAST. Ie, front to back rendering, rather than back to front! Anyone know if this is true or not? I suppose it's easy to test. Unfortunately in Blitz there's no way yet to use entityorder and render objects with zbuffering. I will pass this info along to Mark. |
| ||
| Did a test, and Blitz sorts entities back to front, drawing the most distant entities first. Which is exactly the opposite of what this articel seems to indicate will be fastest! |
| ||
| I think that's how S3 use to do it. They were tops in 3d at a point before voodoo came out. They also had a lot of problems with compatibility issues and games on different cards. I think it's up to the driver and up to directx on the render order and you would end up having to write hardware specific code the way it was in the old days. |
| ||
| It makes sense to me that the optimal would be to draw the nearest triangles first. |
| ||
| Yeah, it does kind of make sense... But it also makes sense to think there wouldn't be a speed hit at all. You'd think they would draw the scene to the zbuffer, and then using that actually calcualte texture and lighting stuff for only those pixels that are visible for each polygon. But I guess this allows them to throw out whole polygons so they don't even have to write them to the zbuffer, which would save a lot cause writing to the zbuffer is almost as memory bandwidth intensive as writing pixels. There's less work involved, but memory is slow. |
| ||
| I just did a test and I'm not sure how much effect this has on speed anymore. I rendered in the hgihest resolution I could, and if I draw the skybox tiny so it covered the whole rest of the scene instead of of being behind it, then the framerate only went up by 4fps, from 62 to 66. That's a pretty small change, and could be attributed to any number of things because this test isn't exactly the same thing. But it's close enough to tell if it would result in a speed increase. 4fps though... Not much of an increase. Of course my scene is a terrain where only 50% of the screen is covered by the terrain normally. I suppose 8fps is a pretty good increase. But to get that you'd have to be rendering indoor enviroments with small areas of sky visible, and/or rendering terrain with lots of trees covering the sky much of the time. |
| ||
| I remember Carmack talking of this. That was not due to the card being clever enough to throw out whole polygons very early. This technique exists, but requires a hierarchical z-buffer, a bit like a mip map. It's been a while since I didn't check very deep the sepecifications of newest cards, but I'd be surprised they include such a buffer (amybe another technique, don't know). And above all I'm sure they didn't at the time Carmack talked of this. At that time the speed up was more due to fill rate considerations: if you draw front faces first then the next triangles will much more often fail the z-depth test (which means less pixels that need to be written in the frame buffer) than when drawing back to front. |
| ||
| I don't know if it's a heirarchial zbuffer or not, but new cards cheat to clear the zbuffer faster. :-) They divide the zbuffer into 8x8 regions, and set each region to "dirty" when they clear the screen, then they pay attention to which regions become cleared as stuff is drawn or something. This saves them tons of bandwidth cause they don't have to set every single z value to 0 every time you clear the screen. |
| ||
| That seems clever. But it's not related to the speed up of drawing front to back. Or have I missed something? |
| ||
| Probably not. |
| ||
| I did hear that Mark was working on something like that a while back.. In one of his updates |
   |