Jump to content
  • Advertisement
Sign in to follow this  
Adaline

Translucent rendering based on depth sort : Pro and cons ?

This topic is 2524 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

Hello !

Today, I render opaque geometry using deferred shading, and I render translucent geometry 'as it comes' without any sort at all.
So I'm limited to very small alpha values (so that we can't notice too much that draw order is wrong most of the time.)

I would like to eliminate this limitation (so we can use arbitrary alpha values with correct order).
I ignore the situations where even a sort at the primitive level isn't enought (intersections, recursive overlap A/B; B/C; C/A)

What I want to do is straightforward : sort the translucent primitives based on their depth (this is practicable in my case), then gather them in a single buffer (triangle list) (I will use for it a specific vertex layout that encapsulates all existing ones so I can use normal mapping, united color etc..... within this buffer). Then, I'd simply draw this buffer.

So here's the 'idea' .... the problem is I don't feel really able to estimate it (I'm a learning hobbyist)

I would be very glad to know the pro and cons of this solution. Should I study/think about another technique ? Is there a better, practicable existing solution ? Would it stuck me to implement other techniques later? Any suggestion or advice is welcome

Thank you in advance !

Nico smile.png

Share this post


Link to post
Share on other sites
Advertisement
You could keep a static triangle buffer and only generate an sorted index buffer each frame. This would reduce the CPU, but possibly reduce GPU load a little since the triangle data will not be read in a linear order. Also, the order of non-overlapping triangles do not matter of course. You might be able to take advantage of that.

Share this post


Link to post
Share on other sites
Sorting per-primitive is going to be expensive, so that's your obvious downside. You're also going to take a GPU performance hit by using dynamic vertex buffers, along with any CPU performance required to fill that vertex buffer (which might require pre-transforming or even pre-skinning vertices, depending on your hardware and API limitations). Usually games just sort meshes by depth order, and live with the artifacts that result from that. You can also look into pre-sorting techniques for meshes, which aim to ensure that all primitives in a mesh render in the correct depth order.

Share this post


Link to post
Share on other sites
Thank you theagentd and MJP smile.png
I came to the per-primitive-sort idea because there would be for instance glass tubes with translucent objects in them.

Anyway, I think I will sort only the meshes as MJP suggested (for the tube example, the mesh can simply be divided into several chunks to limit artifacts)
It will be much more simpler and faster to implement, and obviously performances will be large better. There will be artifacts for sure but there's always pro and cons in every technique ... I have also to learn how to make good compromises

Thank you also for the "pre-sorting technique for meshes", if the artifacts are too much visible, I'll take a look on it

Nicorolleyes.gif

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!