Early Z Pass occlusion
Early Z Pass occlusion
There is allot of talk about saving fillrate with portals, occlusion culling and deffered rending.
How about an early z-only pass? its very easy to implement in irrlicht. If you have transform time to waste, you can redner the scene with a z write only which is extremely fast since there is no fragment processing and most of the vertex processing is shutdown(like interpolation of colours and tcoords). Then without clearing the depth buffer render the scene again with colour write on, all the new rendering is z compared and any occluded fragments are killed early, thats per pixel occlusion culling with 0 overdraw!.
I have tried this on a quake map with parallax mapping and made a considerable diffrence to the framerate (not much of a framerate diffrence using the normal shading).
The only trouble i see is if some one activates this method where they use a shader that modifies fragment depth, the fragment shader is off during the z only pass hence the fragment will not use the depth made from the pixel shader. In that case the early z pass can be a SMaterial flag which can be true for most scenenodes. Similar to the HW buffers hints.
I rendered the objects with this flag in the scenemanger near the shadow pass and made the setMaterial method in the video driver read the SMaterial flag and disable colour writes when needed.
Is there any hope for this going into irrlicht?
How about an early z-only pass? its very easy to implement in irrlicht. If you have transform time to waste, you can redner the scene with a z write only which is extremely fast since there is no fragment processing and most of the vertex processing is shutdown(like interpolation of colours and tcoords). Then without clearing the depth buffer render the scene again with colour write on, all the new rendering is z compared and any occluded fragments are killed early, thats per pixel occlusion culling with 0 overdraw!.
I have tried this on a quake map with parallax mapping and made a considerable diffrence to the framerate (not much of a framerate diffrence using the normal shading).
The only trouble i see is if some one activates this method where they use a shader that modifies fragment depth, the fragment shader is off during the z only pass hence the fragment will not use the depth made from the pixel shader. In that case the early z pass can be a SMaterial flag which can be true for most scenenodes. Similar to the HW buffers hints.
I rendered the objects with this flag in the scenemanger near the shadow pass and made the setMaterial method in the video driver read the SMaterial flag and disable colour writes when needed.
Is there any hope for this going into irrlicht?
"Irrlicht is obese"
If you want modern rendering techniques learn how to make them or go to the engine next door =p
If you want modern rendering techniques learn how to make them or go to the engine next door =p
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Check out the latest SVN/trunk version from Irrlicht. It has an OverrideMaterial in the scene manager and can disable the color rendering via SMaterial settings. That way you can easily make a complete render loop with the desired settings.
For making it an essential part of Irrlicht it would require some more thoughts on the render pipeline since we don't have enough means to define such renderpasses in the API.
For making it an essential part of Irrlicht it would require some more thoughts on the render pipeline since we don't have enough means to define such renderpasses in the API.
You don't "retrieve the depth buffer". Basically:
- When you render some objects, their z-depth gets written to the zbuffer.
- When you render something else that is behind them, or partially behind them, the graphics card doesn't have to shade anything that's got a higher zbuffer value, because it's already occluded.
So say you have 2 spheres. First you render them to the zbuffer in a very "cheap" way (No shading, no color writes, just transformation etc...) and now you have the z values of the sphere pixels written to the zbuffer. Now you can only see one side of one of the spheres, the spheres are not transparent, so only one of them is visible. What you do after that is render the exact same spheres again, this time with the complex shading etc, and you won't have to shade in the sphere in the back because it will get z-rejected because you already have the zvalues of the sphere in front written to the zbuffer, and you did not have to perform any complex shading (E.g. Parallax mapping, which is where this method excels because it trades an extra transformation pass for less shading).
Cheers I hope that explains it more or less.
- When you render some objects, their z-depth gets written to the zbuffer.
- When you render something else that is behind them, or partially behind them, the graphics card doesn't have to shade anything that's got a higher zbuffer value, because it's already occluded.
So say you have 2 spheres. First you render them to the zbuffer in a very "cheap" way (No shading, no color writes, just transformation etc...) and now you have the z values of the sphere pixels written to the zbuffer. Now you can only see one side of one of the spheres, the spheres are not transparent, so only one of them is visible. What you do after that is render the exact same spheres again, this time with the complex shading etc, and you won't have to shade in the sphere in the back because it will get z-rejected because you already have the zvalues of the sphere in front written to the zbuffer, and you did not have to perform any complex shading (E.g. Parallax mapping, which is where this method excels because it trades an extra transformation pass for less shading).
Cheers I hope that explains it more or less.
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
After reading this i've come to a question. Does Irrlicht render the objects sorting them front to back? because that way, the far objects have a higher chance of getting Z occluded faster than just sending them to render randomly. It is almost the same idea we are speaking here, in certain way, and you don't really have to render a Z pass first.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Then you are quite offtopic Nate_D as that was not mentioned anywhere in this thread
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
-
- Posts: 66
- Joined: Sat Sep 29, 2012 11:58 am
Re: Early Z Pass occlusion
hi BlindSide i'm new to irrlicht. Can you pls explain me how to create DEPTH TEXTURE using irrlicht ? as i'm looking for shadow mapping i dono how to obtain depth texture ? there is no books too refer so sad
Thanks in advance
Thanks in advance
Re: Early Z Pass occlusion
Ha-ha - didn't Blindside write XEffects? Look at Ex 1 in XEffects where Blindside has done all the work.
Re: Early Z Pass occlusion
you can very easily help yourself to a DEPTH texture of ANY Render Target in OGL
just modify COpenGLTexture.cpp and make sure your depth attachment is not a Renderbuffer but a Texture2D
then you can setTexture using the COpenGLDepthFBO
just modify COpenGLTexture.cpp and make sure your depth attachment is not a Renderbuffer but a Texture2D
then you can setTexture using the COpenGLDepthFBO