PDA

View Full Version : zero overdraw



MarsuGL
02-19-2002, 07:52 AM
Hello,
i have read two articles focusing of the subject : hidden polys removal

the first was an interview of our favorite game programmer that was saying (if i'm not wrong because i never been able to find this interview again on the net) that bsptrees+frustum culling+PVS was leading to : 0 overdraw.

i have understand reading this that there isnt any polygon behind an other one in any part of the screen.


in an other article about game programming
they were saying that the calculations involved by the bsp-algorithm was eating a lot of cpu power and many game companies dont implement 0 overdraw in their engine.
Instead they make a compromise by letting some little overdraw and reducing cpu use.


What do you think of this? I don't know if the second article is right..
what are the best thing to do assuming the game is a FPS with static world.


tanks
Marsu[HOUBAHOP]GL

Devulon
02-19-2002, 01:20 PM
It seems you might be talking about John Carmack ? Anyway to answer your question 0 overdraw is a bit of complex matter. When making a bsp yo can eliminate overdraw by splitting the polys so as one will never intersect any other one. But that is only in world space. Once everything gets projected onto the screen polygons can now overlap. You could dynamically generate a bsp based on the camera view but that is simply far beyond any currently available processors (maybe in like 50 years ?). Basically the general way that I am currently trying to do things and the way I believe most engines go is a combination of bsp and PVS. The order for drawing objects is take the player position, use PVS to get rid of everything that is completely invisible, traverse bsp and frustum cull (backface culling shouldn't be necessary because of the bsp). At this point there is still chance of overdraw. the best thing to do now is get out of vector space and get into the screen. Quake 1 I belive used visibility spans along the horizontal raster lines. Most hardware cards only do Z-Buffering. But with hardware you can't really do anything at the pixel level. I know I know you got shader programs now, but I don't think its possible to do any type of vis with them not in 128 instructions. Perhaps that is something to look into. I don't see it being practical but sortof possible.

I know that didn't make any sense and that it went on forever but what do you want. If you want a better explanation of how bsp+culling+PVS work together let me know and I will try to be more specific.

Happy Coding.

MarsuGL
02-20-2002, 01:39 PM
thx fr ur useful explanations,
i have understood that i have maybe misunderstood carmack's explaination.
it was maybe projetting on future.

So, engines are 'using' an acceptable of overdrow, not 100%.

Currently i'm not at this step of the devellopment stage but
can you tell me what is the first usefull thing (bsp,pvs,...?) to implement to have a less problems with scenes that slow when using a lot of polys ?
If possible ont that isn't the hardest to code http://www.opengl.org/discussion_boards/ubb/smile.gif

tnx
Marsu