Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

edwinnie

GPU optimisation: laydown z

This topic is 5278 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hihi, i was reading the GPU gems book, and came across the part called "render depth only (no color)" or they called "laydown z" first. which i am quite bit cluelessss here, i mean how do we actually render the depth? jus a depth test without clearing the backbuffer? or the other way around? or is there alot more to it actually?? also, the book recommended to disable alpha testing during the render depth only process. thx! Edwinz

Share this post


Link to post
Share on other sites
Advertisement
This refers to rendering the scene with color writes disabled. This translates into only writing the z-value of all polygons in the scene into the z-buffer.

Once the z-buffer is filled with all visible polygons, you re-render your scene with full detail, and if the polygon is invisible in the final result, it will fail the z-test and no more work will be put into it.

This is only really helpful if you are fill-bound in your engine, but this method really sucks if you''re transform-bound (because you have to transform all your polygons twice)

Chris Pergrossi
My Realm | "Good Morning, Dave"

Share this post


Link to post
Share on other sites
quote:
Original post by c t o a n
This is only really helpful if you are fill-bound in your engine, but this method really sucks if you''re transform-bound (because you have to transform all your polygons twice)


while seeing how current cards push hundreds of millions of triangles through transformation you''ll always be fill bound unless your texturing/shading is extremely simple or the scene is extremely complex.

sorting objects by "shading complexity" and maybe use that method only for the complex objects after the simple stuff was drawn might be a good compromise.

Share this post


Link to post
Share on other sites
Well, there are other potential bottlenecks when doing graphics programming, so you might not be fill-bound OR transform-bound, so you might not see a big change, positive or negative, if your engine has other limiting factors.

On the whole though, this is a good technique for improving performance if you''re using complex pixel/vertex shaders, multitexturing, or have alot of overdraw in your scenes.

Chris Pergrossi
My Realm | "Good Morning, Dave"

Share this post


Link to post
Share on other sites
Doesn't rendering your geometry in rough front-to-back order acheive about the same result without the extra transformation work?

EDIT: If you have a lot of different setups (different textures, different shaders, etc) render front-to-back for each setup separately, starting with the simler ones and progressing to the more complex ones. This way, by the time you reach the expensive shading, your z buffer is already almost filled, and the front-to-back rendering order takes care of most of the remaining overdraw.

Michael K.,
Co-designer and Graphics Programmer of "The Keepers"



We come in peace... surrender or die!

[edited by - technobot on May 29, 2004 5:04:11 AM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by technobot
Doesn''t rendering your geometry in rough front-to-back order acheive about the same result without the extra transformation work?


This is probably for places where you don''t have the good front-to-back ordering info. From one of the slides @ GDC I think the suggested order was.. sort by rendertarget, shader, texture (roughly in that order)

Share this post


Link to post
Share on other sites
quote:
Original post by edwinnie
also, the book recommended to disable alpha testing during the render depth only process.


This is because alpha-testing enables/disables the depth write on a per-pixel basis and, because alpha is available later in the pipeline than the early z-write, the early z-write has to be omitted (you can't write to the depth buffer and then have the alpha-test, which happens further down the pipeline, say that the pixel is transparent and shouldn't have written z in the first place). The z-write still goes to the late zbuffer though. This means any batch of triangles rendered with alpha-testing enabled cannot early z-reject subsequent batches rendered in the z-only pass. On modern h/w there's two types of zbuffer - a late one that tests a single pixel and an early one that tests a group of pixels (sometimes rejecting a single triangle with one test).


[edited by - soiled on May 29, 2004 12:09:22 AM]

Share this post


Link to post
Share on other sites
That works well if you don''t have textures with holes in them (alpha keys). Otherwise you''ll have to render those textures twice, and even with color writting disabled you still waste a lot of bandwidth/fillrate, because the texture is needed for the alpha key.
Since most of our plants need alpha testing, it''s not going to be very usefull.



Eternal Lands (free, Open Source MMORPG)

Share this post


Link to post
Share on other sites
Re: "laydown z"
You'll double the batch count, and engines these days (i.e. shader driven) are so easy to become batch-limited.
You should try this *after* you got the engine running and fed with real-world dataset (i.e. during optimization phase).


[edited by - yogiwp on May 31, 2004 11:22:59 AM]

Share this post


Link to post
Share on other sites
You could use a lowpoly approximated mesh instead of rendering the scene geometry twice. Prefilling the zbuffer with an occlusion skin (as in occlusion culling) would probably work pretty well - early z rejection is a kind of degenerated (perpixel) occlusion culling method after all.

If you're not fillrate limited, that is.


[edited by - Yann L on May 31, 2004 11:46:13 AM]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!