🔒 Locked

rendermanagement and sorting

Started by ehmdjii Jun 30, 2006 at 4:22 AM 6 replies 1.1k views

Original Post

Jun 30, 2006 at 4:22 AM

hello, first, just tell me if this is correct: objects with fully opque material and fully opaque textures: do not care about rendering order enable writing to z-buffer objects with partially opaque material: render back-to-front disable writing to z-buffer objects with fully opaque material, but with partially opaque textures: render front-to-back enable writing to z-buffer objects with partially opaque materials AND partially opaque textures: ????? now what about this last case? how should i render those? are there any libraries (rendermanagers) that would do this stuff for me? thanks!

Specchum

Jun 30, 2006 at 5:16 AM

That's interesting. In my engine (so-called) I don't worry about partial opaque materials and/or textures. I have only 2 lists - one for objects that require alpha blending (texture or not is immaterial {pun unintended} to me) and one that don't. The alpha blended list is sorted from back to front and z write disabled while the non-alpha blended list is sorted front to back with z enabled. The opacity is controlled by alpha so, partially opaque falls in alpha-blended category automatically.

HTH!

darkprophet

Jun 30, 2006 at 6:59 PM

Why do you disable depth writing in the alpha queue?

What I do in my engine is split the current geometry's pass into 2, the first is for front face culling and render that, the second is for back face culling and render that. Seems to work fine. And i haven't had any issues.

The only real problem is the two texture fetches, but those are negligable these days anyway (unless they are out of vram...but thats a different story)

Regards,
DarkProphet

noisecrime

Jun 30, 2006 at 9:13 PM

objects with fully opaque material, but with partially opaque textures:
render front-to-back
enable writing to z-buffer
quote]

Thats not going to work, not unless you're using alpha testing on the textures. Just because a texture has an alpha channel, does not prevent those pixels from being written into the depth buffer, they will.

As Specchum said, you only need two passes, one for opaque and one for transparent materials.

ehmdjii

Jul 3, 2006 at 9:22 AM

thank you.

so i can group transparent-textures and transparent colors into one pass?

and why do i have to sort opaque objects anyway? shouldn't the depth-test care about them?

DrakeSlayer

Jul 3, 2006 at 9:32 AM

I think you must sort opaque objects to optimize the usage of the Z-buffer. If you draw them front to back, you will reduce overdraw. since objects in the front are already drawn, objects in the back are more likely to fail the Z-test. It can increase performance drastically in the case you use materials with complex shaders.

Stani R

Jul 3, 2006 at 9:51 AM

Quote:
Original post by DrakeSlayer
I think you must sort opaque objects to optimize the usage of the Z-buffer. If you draw them front to back, you will reduce overdraw. since objects in the front are already drawn, objects in the back are more likely to fail the Z-test. It can increase performance drastically in the case you use materials with complex shaders.

In this case wouldn't sorting by shader state be better? - changing shaders is supposed to be the most expensive state change in OpenGL, and the way I understand it, the state change would happen before the z-test.

More importantly, you need to write the code and profile it to find bottlenecks before you start writing optimizations like these. Some experienced programmers have stated before that bottlenecks are almost never where you think they are, so profiling is important.

Topic Locked

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