Hi!

I am writing my own game/engine and I'm facing a problem. I have a lot of semi-transparent things such as the water surface, particles, (stained) glass, etc. They need to be lit like any opaque thing, otherwise you'll have e.g. glass that makes everything behind it brighter when it is lit while the rest is dark.

While I know the ambient and diffuse brightness of the scene before rendering it, I do not know whether you are in a dark cave or next to a light source, so just using the sun light for that does not work.

So I am pretty sure I need to do the same post processing lighting calculations (sun light, volumetric ambient lighting, etc.) for semi-transparent pixels that I do for opaque pixels.

However, when I do this I run into another problem. If there are 2 or more transparent things behind each other, this breaks when they are lit differently, e.g. by shining a flashlight at the rain in front of the water surface in the background. I implemented multiple render passes to solve this, but this still has a limitation (2, 3, or 4 transparent things, based on the settings) and it is pretty slow.

I am using order-independent transparency rendering (weighted sum of colors based on depth) because I cannot order everything by distance, especially not the particles.

The tutorials I could find are very basic and I don't know what to look for specifically. Can anyone point me in the right direction here?

I am basically out of ideas, the only thing I could think of would be rendering the semi-transparent objects grouped by type and do lighting calculations for each group, i.e. water first, then particles, and so on. But I don't know if this would be much faster or look better.

ok so you are not showing any images nor telling us what tutorial you followed, so what i'm saying next is based on assumption that you are using a good tutorial ? … and based on what you said;

things to check for the oit side of things:

• you are using 2 render targets (rgba16f and r8), right ?
• you are using the 16f-target as the accum target and the r8-target as the revealage target, right ?
• during the opaque pass, you are testing and writing to the z-buffer X, right ?
• during the oit pass, you are using the same z-buffer X and still testing but not writing to it, right ?
• during the oit pass, you are rendering your transparent surfaces in whatsoever order, right ?
• during the oit pass, your input colours are not gamma encoded somehow, just pure linear rgba values, right ?
• after the oit, you are doing a full screen pass to composite those render targets to your opaque frame buffer, right ?
• right ? ?

Beosar said:
They need to be lit like any opaque thing, otherwise you'll have e.g. glass that makes everything behind it brighter when it is lit while the rest is dark.

1/

ok make sure that your transparent surfaces are all lit before applying oit on them; oit is a blending tech not a lighting tech so make sure all your lighting is done on them before oit takes place, u might have to light them in a separate pass; (light them up as though they were opaque surfaces)

then after the lighting is done on those soon-to-be transparent surfaces you can then apply oit on them to make them transparent;

to be sure that your transparent surfaces are well lit, turn off oit and check to see if the lighting result is what you expect; when u r 100% sure that lighting on those surfaces is as expected now turn oit back on;

2/

another thing u could do to check:

• turn lighting off on those transparent surfaces
• apply oit on them and see if it results in what u expect;
• when it does then turn lighting back on for those surfaces
• apply oit and see what u get

3/

• if after oit, your result is aliased, just apply some fxaa
• if after oit, your result is too bright, then premultiply your resulting oit rgb values by the corresponding alpha value

if u still have a problem, u might have to share your code, tute, or shaders…

That's it … all the best ?

It is working as it is supposed to work. The problem is that the technique I am using has limitations that result in incorrectly lit transparent pixels and it is too slow.

ok well, since you're not sharing code, u'll have to integrate PPLL into your undisclosed tech yourself -mum's not happy-, look here from page 29:

https://www.slideshare.net/KiHyunwoo/rendering-aaaquality-characters-of-project-a1

then look here and mod the k-buffer to satisfy the ppll needs:

http://www.sci.utah.edu/~csilva/papers/i3d2007.pdf​​

oh and don't forget to store the Forward's ppll radiance value - that's the trick and finally you're gonna have to think about reducing overdraw;

you have all u need now

PS: if the links don't work, it's a gamedev.net problem…not my fault

-boom-