Transparencies and Babylon 5: Super Improvement!

Following the Order Independent Transparency note which can be found in the Transparent Rendering chapter of BJS doc, I have to say that I am very impressed and excited by this incredible improvement, since it has been around with Babylon 5 alpha.
On recent GPUs, we only experience a slight overhead which is definitely worth the improvement in quality and ease of use.
Warm congratulations to the Babylon team.
Looking forward to the release, which will hopefully set aside some weaknesses (e.g. the lines and dashed lines appear (at least for me) to be incompatible with turning scene.useOrderIndependentTransparency to true).
An idea of the date of a beta then of a release?


Thanks a lot for the kind words :slight_smile:

Let s see if the daddy of it @CraigFeldspar could do something for it ???

1 Like

I have sent a message to daddy. Thanks for unveiling his name!
What great work indeed.
All the best,

Jean-Marie Laborde
Président Fondateur de Cabrilog +33 6 0778 8628

Directeur de recherche at CNRS, Université Grenoble Alpes, France.

1 Like

Hello Jean-Marie,
I’ve seen your private message, but allow me to answer here, as some other people may stumble onto the same problem.

Would it be possible for you to set up a simple playground demonstrating the problem with orderIndependentTransparency + lines ? It could be a simple fix

1 Like

Hello Craig.
My apologize for not following immediately. I have now prepared a playground to demo the issue. It is

It would be so nice if you could find a fix !
All the best !

Please let me know if you need some further info.
(The issue appears on Chrome, Firefox as well Safari…)

@CraigFeldspar will have a look shortly

Hi @Jean-Marie_Laborde, I’ve made a PR to fix that issue :

Once it’s merged, a new nightly will be shortly released and your issue should be resolved


Wonderful! Thanks! jm

In making use of useOrderIndependentTransparency wich works remarkably well, I have noticed following phenomenon:
Consider a mesh made of just one triangle, coming with some standard material and alpha = 0.7 As expected, depending which side of the triangle you are facing, the triangle is visible or not at all visible (in case of its orientation is the “wrong one”).
But if we turn useOrderIndependentTransparency to true, the face which used not be visible, appears now somehow “in transparency”.
Here is a PG demonstrating the phenomenon, it is based on a PG out of BJS documentation. I have adapted it slightly to fit the situation I am describing in adding 3 lines at the end:
customMesh.material.backFaceCulling = true;
customMesh.material.alpha = 0.7
scene.useOrderIndependentTransparency = true
(Note that backFaceCulling make not too much sense here):

So the question can this behavior be considered as “on purpose” aka a feature, or is it more some kind of bug ?

@CraigFeldspar, could you have a look into this one ?

Hi @Jean-Marie_Laborde,

First thanks for your kind words, I appreciate a lot.
I looked into the code, and we indeed disable all backFaceCulling before entering into the depth peeling renderer (that gives us OIT).
Why ? A little peek into how we proceed to render OIT : we “peel” each depth layer, by rendering them individually. And each depth layer may contain back faces, that contribute to the final color, we have to take these faces into account and accumulate their color values.

OIT was thought to work on “closed volumes”, so I’m considering single faced planes as an edge case.

Now, that said, we could add a property that would disable this behaviour, and take into account the material’s backFaceCulling property instead of ignoring it.
We could do it scene wide (depthPeelingRenderer.ignoreBfc: boolean), or material based (something like depthPeelingRenderer.bfcWhiteList: Material[]). @sebavan WDYT ?

There are no kind words, you just deserve them!!
A way to make a choice at material level would offer more flexibility. Anyway why not offering both possibilities if there is no performance tradeoff ?
Many thanks, Jean-Marie L (Cabri)

I like the perMaterialApproach as well :slight_smile:

That’s really great OIT coming in v5, congrats! :metal:

Is it expected that some PBRMat properties aren’t render in the same way if OIT enabled or not?
By playing with this test scene, I’ve noticed sheen & subsurface acting in a different way:

key playground lines are:

  • line 6 to enable/disable OIT
  • line 73 & 76 to play with dragon PBRMat

@CraigFeldspar is definitely the GURU for this part :slight_smile:

In theory, we use the exact same PBR shader to render pixel colors, OIT comes just to accumulate layers of transparency into a final color.

Can you provide screenshots of what you have/what you expect ? The main visual difference I see is that with OIT we render the backfaces, so you get a material that’s twice “thicker”.

Make sense about the “twice thicker” thing. Note that even with other engines I don’t know a lot about OIT pro & cons, so maybe my observation is naive.

I’ve updated my playground to quickly switch OIT, backface culling, and few PBR properties: , that way you can see how it acts (green = enabled, red = disabled)

  • when backFaceCulling, sheen, subsurf refraction are disabled, no matter if you enable or disable OIT (except alpha handling of course :sunglasses:)
  • but since you’re enabling sheen or subsurf refrect, you have a visual difference

(but again maybe it’s expected and knowledge to have when activating an option like OIT?)

Your second PG makes it indeed clearer, especially when you go almost opaque (0.99 alpha).
There may be some issue indeed, maybe it’s connected with env texture sampling.
I’ll try to have a look as soon as I get some bandwidth


Hello, Unfortunately I have noticed that, on recent commits of Babylon 5.0.0 (actually say beta 5), we get an error on my exemple from above using a system of lines.
(For simplicity turning my exemple back to an ordinary line (and not a dashed line) does not help).

We get some
in a peeling operation.
I hope it won’t be too difficult to that fix for you, dear Craig!
ATB Jean-Marie L.

I am pretty sure @CraigFeldspar will fix it in no time :slight_smile: