Sign in to follow this  
Stiffler

Your opinon on the rendering of a scene

Recommended Posts

Stiffler    163
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...

Share this post


Link to post
Share on other sites
superpig    1825
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.

Share this post


Link to post
Share on other sites
m4gnus    240
AFAIK the pixelshader is only executed for the pixels that passed the depth test so culling faces yourself will not change anything.

regards,
m4gnus

Share this post


Link to post
Share on other sites
oggialli    217
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.

Share this post


Link to post
Share on other sites
matches81    474
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.

Share this post


Link to post
Share on other sites
oggialli    217
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]

Share this post


Link to post
Share on other sites
matches81    474
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.

Share this post


Link to post
Share on other sites
Stiffler    163
Sorry, i had our state academic team tournament over the weekend, but tonight i'm going to give the depth thing a try, i'll let you know how it goes.
Thanks for the help

Share this post


Link to post
Share on other sites
Stiffler    163
Wow, you guys are amazing. Thanks a lot, disabling the colorwrites and using the idea of a depth render pass worked wonders. It now has an almost constant cost of using my parallax shader. I love this place... maybe this will be the thing that lets me win state :)

Share this post


Link to post
Share on other sites
Stiffler    163
Okay, this last question is just something that I am personally wondering... Is this technique of having a multipass rendering system to keep the pixel shader work low considered normal in the professional workplace? Or is it not as useful as it seems to me?

Share this post


Link to post
Share on other sites
matches81    474
Are you talking about that depth-only pre-pass?
I don´t have any professional experience, so I don´t know whether this is common practice with professionals. But I think that the benefit from this depth-only pre-pass is mostly that you don´t have to sort your polygons (or meshes to speed sorting up) from front to back. If you´re sorting front to back anyway the benefit of this pre-pass won´t be too big I guess. Could be wrong there, though.
Have you ever tried sorting your scene front to back?

Share this post


Link to post
Share on other sites
oggialli    217
Nah, polygonal-level sorting breaks your batching so it's not a real alternative on today's hardware. Doing a depth-only prepass (maybe associated with conservative chunk occlusion culling on CPU if geometry is heavy or vertex programs slow) is a good way to ease fragment processing load still conserving the proper batching etc. So it's a common practice in the industry nowadays too.

Polygonal-level techniques like BSP sorting, not counting alpha blending here, are mostly a remnant from the past, when you didn't have any excess fillrate to burn. Nowadays you are limited by the CPU, not fillrate if you start using polygonal-level techniques for anything.

Share this post


Link to post
Share on other sites
matches81    474
Quote:
Original post by oggialli
Polygonal-level techniques like BSP sorting, not counting alpha blending here, are mostly a remnant from the past, when you didn't have any excess fillrate to burn. Nowadays you are limited by the CPU, not fillrate if you start using polygonal-level techniques for anything.


That´s why I put "or meshes to speed sorting up" in brackets ;) I know that sorting on polygon-level is unnecessary and / or even harmful to performance these days.
But you´re definitely right about the batching issue. A depth-only pre-pass allows you to batch without caring about spatial relationships, which makes batching much easier and allows for larger batches in most cases, I guess. Haven´t thought of that. Good point.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this