Your opinon on the rendering of a scene
Right now I'm having trouble with the most efficent way to render a scene from my S.T.L.P project for my high school. My program displays a 3d maze that you can walk through generated by a partners program, and being a showoff, i wanted to add some special effects so i implemented parallax mapping on the walls. This works great, and looks great, but when i am standing in a position where walls further away are draw after the closer walls, the frame rate drops enough to notice :(. So, should i implement a type of bsp to render from back to front always, or is there an easier way that i am missing to occlude walls from rendering?
p.s., i didn't know what exact specs to include, so if you need more information to answer my question, feel free to ask.
Thanks...
Quote:Original post by Stiffler
S.T.L.P
?
Are you doing all this in software or something? If it's on hardware, you should be using the z-buffer to do your occlusion work.
AFAIK the pixelshader is only executed for the pixels that passed the depth test so culling faces yourself will not change anything.
regards,
m4gnus
regards,
m4gnus
Try doing a depth-only pre-pass. What I mean is, draw the scene once with color buffer writes off. Then draw the scene again with color buffer writes on. If you have a lot of overdraw and a expensive fragment shader (/otherwise bad fragment performance) this will be beneficial.
Quote:Original post by Stiffler
So, should i implement a type of bsp to render from back to front always, or is there an easier way that i am missing to occlude walls from rendering?
You should not render from back to front anyways, except you got transparent (alpha blended) polygons in there. If you render back to front the chance is pretty high that every polygon, visible or not, will have to go through your pixel shader (and with parallax mapping this is rather expensive). Rendering front to back will only send the necessary polygons through the pixel shader, which should aid your performance.
If rendering front to back doesn´t help enough, oggialli´s suggestion with the depth-only pre-pass should help. The depth-only pre-pass is used to fill the depth-buffer using the cheapest method possible. As oggialli mentioned for the pre-pass you normally disable color-writes and write only to the depth buffer. After that (in the following normal rendering pass) you disable writing to the depth-buffer, enable color-writes and set the depth buffer comparison function to "equal", so only the pixels that are actually visible get shaded.
The depth-only pre-pass should be simple to implement, as it requires no sorting of any kind beforehand.
It otherwise is, but you don't take into account the fact that a z-passed fragment CAN and usually also WILL be drawn over with an another, closer fragment. Just give it a little thought, it's not very complicated at all.
[Edited by - oggialli on March 12, 2006 12:26:25 PM]
[Edited by - oggialli on March 12, 2006 12:26:25 PM]
Quote:Original post by m4gnus
so what i said is not correct?
regards,
m4gnus
sure it is, at least the part that the pixel shader is only executed for pixels that passed the depth test. But, imagine something like the following:
----------------------- D----------------------- C----------------------- B----------------------- A o <------ Camera
The camera points toward the four quads A,B,C and D.
If the quads were rendered in the order D,C,B,A (which means back to front) the following would happen:
When rendering quad D, every pixel will pass the depth test, because the depth buffer was cleared right before rendering it. After that, when rendering quad C, every pixel of C would pass the depth test again, because every pixel would be closer than the points of D were. Same thing for quad B and A again and you just pixel shaded the same regions of the screen 4 times, which, with something like parallax mapping, is quite expensive.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement