Originally posted by skw|d:
Think about this, you are sending polys to the hardware card asking it to do all the complex processing you talked about. All the polys must be textured, lit by dynamic lighting, dynamic shadow volumes must split some and shade them, and any other processing must be done to them… but they are never seen!
well “textured, lit by dynamic lighting” is fillrate and “dynamic shadow volumes must split some”??
as far as i know hardware doesn’t have shadow volumes!?
The technique i was referring to when talking about with stencil buffers uses the zbuffer and does absolutely no clipping…
It’s a pure fillrate thang…
And if you’re referring to texture matrix calculations on the card etc.
Yes, those have impact on performance, but geometry has more effect on it than anything else…
The whole point of vsd is to render what the viewer needs to see. The reason is not just fillrate, but to avoid all the other processing that needs to be done to the polys.
And you’re absolutely right!
But the point is that balance is more important than zero-overdraw…
There are more factors than just ‘drawing the polygons you see’
Sure, the less you draw, the faster everything is going to be, that’s obvious.
But it’s faster to draw less polygons and less complex polygons (with less vertices) even if you have more overdraw…
The time it takes to render a scene of polys is not linear, adding 10 times the number of polys does not make it 10 times slower, it is far worse. So the more effort you put into removing polys that will never need to be processed will go a long way, and IMHO is where one should focus their efforts when designing an engine.
It’s all about balance, yes you need to remove as many polygons you don’t see as you reasonably can (without doing so many calculations you actually start slowing down everything)
But clipping polygons is a bad thing most of the time…
But the most important factor to take into consideration is that things like vertex buffers usually have a much bigger impact on performance (this case in a positive way) than removing several polygons…
Look…
I’ve been at siggraph2000 this year and in one of the courses they came with a very good advise.
Theory is good, but it’s worth crap if you don’t actually verify that what you think is going on, IS actually going on.
Check everything, try everything, never assume.
Verify verify verify…
I was working with no-overdraw algo’s before i stated testing everything… and because of those tests i changed my mind…
Please take my advice and do some tests, You’ll discover (like i did) that splitting is very bad for performance, much more so than overdraw.
Ofcourse if you split a polygon and you end up with exactly the same ammount of vertices, sure it’ll be just as fast…
(but ofcourse you’ll still have the extra cpu overhead)
It’s probably more effective to split a level up into some sort of cells (not too small, not too big, non convex)
put them in display lists, and determine which portals are visible and which display lists should be called…
the added advantage of display lists is that the geometric data should already be on the graphics card…
And when you do things like multipass rendering, you just call the list for every pass and you don’t need to send it to the card again, because it’s already resident.
But again, i’m talking about geforce level hardware…
I hope you realize how much faster vertex array ranges (nvidia specific) are faster than display lists, how much faster display lists are than vertex buffers, and how much faster vertex buffers are than sending triangles etc…
And the more static the data is, the faster it can basically be send to the card…
Ofcourse when i say static, i mean from a geometric point of view… you can still rotate/translate the data with the help of matrices (and some extensions), you can even do the same for texture coordinates using texture matrices…
[This message has been edited by Firestorm (edited 09-29-2000).]