Skip to main content
gamedev.net
🔒 Locked

Overdraw Reduction

Started by Daave 6 replies 1.1k views
Original Post
Daave
Daave
I'm looking for ways I can reduce the overdraw in my scene which is killing my framerate. I also have a question about Z Culling... I have a massive plane of expensive water drawing under an island right now. The water is drawn after the island is. it seems to me that the pixels of water under the island that are occluded shouldn't ever hit my water pixel shader because they will fail the z test, but does that happen AFTER my pixel shader? I tried to get early z culling working, and set the states as I heard I needed to, as well as rendering out a pre-z pass, but I never saw a difference and it always seemed very abstract to me as to whether or not it was enabled since it's all behind the scenes. Any recommendations are appreciated.
nullsquared
nullsquared
Use early-Z. Render your full scene with colour write off, only depth write (and obviously no shaders or anything considering colour write will be off). Then, render your scene once more as you always do (without clearing the depth buffer first, of course), except the depth function should be set to equal. Therefore, anything that equals whatever is in the depth buffer (whatever is visible) will be drawn, and everything else will be rejected.

As for your water plane being obstructed by the island... the pixel shader won't be run only if your island is drawn first. Just because your island occludes the water doesn't mean that the water isn't draw first and then the island over it.
Daave
Daave
The island is drawn first. When I look straight down into the ground of the island (with the water below it, and skybox below that) my fps bombs. Why is that?
Daave
Daave
So I implemented early-z and on the comp im on atm it seems to be working. if I look straight into the ground I get 35fps, if I go through the ground and look straight into the water my fps drops just slightly (as it should, the water is a more expensive shader than the ground).

However, running this same build on the hardware im trying to run on doesn't give those results, it gives opposite results. This makes me think that, that hardware doesn't support early-z. It is old laptop hardware.
(The graphics card is a mobility radeon X600 SE if anyone knows whether or not that supports early-z)


Is there another way to reduce overdraw?
MJP
MJP
That GPU should support hierarchical z, so I don't think that's your problem.

Have you determined that the water shader is actually what's causing your problem? Try setting the water pixel shader to just output a blank color....this will help you confirm whether it's bringing your performance down.
Daave
Daave
Well, I'm now on yet another computer, this one with an 8800GTS. Here, with the same build, when I look straight into the ground, my framerate improves (as I would assume). When I go through the ground and look straight at the water it is slightly worse (as the water shader is much more costly than the shader rendering the terrain).

Since I'm getting such vastly different results with this setup, changing the water shader isn't really valid until I get back on one of the other 2 comps.


Another thing I'll mention is that on several comps I notice that MSAA isn't seemingly supported to what the vid card specs are. I can't go over 4x with that X600SE. Any ideas?
Krohm
Krohm
The X600 is an old card. I suppose it comes with an old system.
Take this with a grain of salt but,
-considering that lay-z effectively doubles the batch count-
are you sure the benefit isn't zeroed out by the extra CPU cost?

Supposing this is actually the problem, because as you say,
Quote:
Original post by Daave
I have a massive plane of expensive water drawing under an island right now. The water is drawn after the island is.
Then, layz-first isn't strictly necessary, I agree with MJP, there's a possibility that's not your problem.

For first, could you say more about your shaders?
Previously "Krohm"
Daave
Daave
Quote:
Original post by Krohm
The X600 is an old card. I suppose it comes with an old system.
Take this with a grain of salt but,
-considering that lay-z effectively doubles the batch count-
are you sure the benefit isn't zeroed out by the extra CPU cost?

Supposing this is actually the problem, because as you say,
Quote:
Original post by Daave
I have a massive plane of expensive water drawing under an island right now. The water is drawn after the island is.
Then, layz-first isn't strictly necessary, I agree with MJP, there's a possibility that's not your problem.

For first, could you say more about your shaders?


The water shader samples 2 normal maps and lerps them together. The resulting normal is used to calculate specular highlights and offsets to distort reflection and refraction textures.

The reflection texture is created earlier in the frame by rendering most of the scene from a camera reflected around the water plane. It is then projectively textured to give... reflection. The refraction texture is the scene rendered thus far from the camera the user sees, and is also projectively textured. The reflection and refraction textures are combined with a fresnel term.

The water alphas out near the horizon so that it creates a soft edge with the skybox. So, the water is 4 samples per texel.

The shader rendering the ground is just simple ambient/diffuse/specular lit textured normal mapped terrain. 2 samples per texel.


I can also say that early-z does drop my framerate a good deal across the board (and I would expect). But, in the cases where I think overdraw is killing me it seems to have helped (at least on 1 comp). On this 8800GTS it doesn't matter because it looks like the water is properly not costing me anything when I stare into the ground. On the X600 it looks like it costs me something staring into the ground with or without early-z.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.