Particles and material alpha

[fenomas]

Hi,

 

Is it a fact of life that particles get drawn on top of anything with alpha?

 

http://www.babylonjs-playground.com/#156EO

 

Or is there some combination of settings that would make this scene composite as expected?

[GameMonetize]

"A fact of life": Love this expression

 

The rendering order (on the same renderingGroupId) is: opaque, alpha test, alpha, sprites and then particles

 

The problem in your example is that alpha objects DOES not render to depth buffer

[fenomas]

"A fact of life": Love this expression

 

At companies I've worked for, this was the standard designation for an issue that's not intended, but not fixable either. Like that anisotropic filtering bug I logged that turned out to be a DirectX limitation - our QA would have marked that bug "FOL".

 

The problem in your example is that alpha objects DOES not render to depth buffer

 

Okay, does that mean my example could be changed so that they do render to the depth buffer?

 

In other words, is it a problem with my example, or a FOL? By definition I don't think it can be both.

[GameMonetize]

FOL in this case

 

We do not support alpha objects (Alpha blending I mean) that render to depth 

 

BUT we can think about adding this if we find an use case

[fenomas]

Er, the use case is in the playground I posted, no?

[GameMonetize]

not really why the second object need tranparency?

[fenomas]

Uh, because it's a window? Or a fishtank? Or a transparent alien? Pick a reason 

 

I mean, the use case is simply that Babylon says it supports transparent meshes and particles, so a stupid user who doesn't understand depth buffers or blending (i.e. me) is trying to use both of them. Does it need to be more specific than that? 

 

 

More generally, one thing that makes frameworks hard to work with is when their features work great individually but not in combination. I'm still new to BJS, but I'm getting the impression that there's a kind of "conflict list":

material.alpha, sprites, particles, texture.hasAlpha, shadows

With the rule being that my scene will work great with any one feature from that list, but once I use two of them something will (in general) not render as expected. Of course I understand (very very vaguely) that webGL limitations mean some combinations might be impossible, and others might have performance tradeoffs. But wherever possible it would be better for things to work (and for things that don't work to be documented - perhaps a "feature compatibility matrix" or something).

[jerome]

"feature compatibility matrix"

 

love the idea

[fenomas]

Well, the ideal compatibility matrix would be "everything works with everything." 

 

But just for when it doesn't..

[Wingnut]

C'mon dk, own up.  Fenomas found a butt-grinder annoyance, and it grinds your butt just like it does everyone else's.  Likely more.

 

http://www.babylonjs-playground.com/#156EO#1

 

The sheet of tinted glass (block 2)... tints the red box, tints the skybox material, and doesn't do anything to the particle sprayer.  We all know that this is not rendering "ideally" or even "good".  The particle sprayer "should" be tinted, also.

 

So what's it going to cost, DK?  Would you know?  Can you give us an estimate of workhours, think-time, fall-out ramifications, etc?  Would we lose performance because our depth renderer needs to do more checks?  Alpha-blending BS?

 

I think the use-case criteria has been met.  Burning particle candle, seen through tinted or ice-frosted window... SHOULD obstruct the view of the candle flame. 

 

And... while we're here, let's "mention" how the particleSystem should be able to act like a pointLight source and cause refraction effects on the frosted window glass, if possible.  Ideally, EVERY particle can be a pointLight source, but that's probably 3-layers of impossible. 

 

And... point light sources such as a particle candle flames, should be able to make shadows that "flicker" to match the flames.  (omg)  Candle and torch ops are very important to game coders, I would say.  The new procedural fire texture is great, but I think we will see game authors still using particle systems for torches and candles.

 

So, I vote for further investigation... into trying to advance the particleSystem... just as far as possible. 

 

My investigation so far?  Asking how miserable would it be... to get our particles acting "more normal". 

 

Thanks.  I believe the use-case criteria has been met, but it is not my call on that.  Use-case or not, I also vote to avoid giving deltakosh unnecessary brain tumors.    Party on!

[jahow]

Hey,

 

What about sorting meshes with transparency from back to front, since we can't rely on the depth buffer with them?

 

Just trying to help!

 

@Wingnut: personally, if I were to simulate a torch light in a game, I would place a flickering light source at the center of the flame (where particles would be generated). Also shaking randomly the light source would give a nice "trembling flame" effect. Adding more than one light source for a single torch would be unrealistic to say the least

[GameMonetize]

TL;DR: We cannot sort transparent meshes unless sorting face per face which will reduce FPS to dust.

 

What do you suggest? having transparent objects to render to depth buffer? so we then go back to the need to sort face per face in order to draw back to front hence NO FPS AT ALL.

 

Let's think about a house with two windows and a particle inside. Depending on where the camera is, we have to render window 1, particle, window 2 or the opposite right? But what is SOME particles are emitted with enough power and get out the house? In this case we have to render some particles, window 1, other particles, windows 2

 

So far, the only decent way I found was to render transparent objects with no depth buffer writing.  Then I made the decision to render particles AFTER transparent object. This could be easily inverted but I'm afraid this will just move the problem

 

I would love to have infinite time and patience to serve all your asks guys, but this one is not an easy one.

[Wingnut]

*nod*  Thanks for the explanation.  I hope you aren't grumpy with me, but it seemed you were stringing-along Fenomas a bit.  You're certainly allowed to do that, but I'm also allowed to try to get "the story" about this, if one exists.    Again, thanks for telling us about the issues... I appreciate that.

[GameMonetize]

I updated my explanation a little bit to give more details about my design decision

 

No problem Wingnut, I may look a little bit grumpy but this is just because I'm terribly tired. My baby (a little girl) is due this Tuesday and my wife does not sleep well (So do I;)) And things will just get worse next week, I think!

 

So I'm not stringing-along anyone, I was just too lazy to explain why this is almost an impossible situation. But once again, I someone has a better idea, I would love to fix it. I'm not over comfortable with how the transparent objects and particles are integrated.

[Temechon]

Congrats ! I'm sure everything will going well for you and your family ! My baby is due by the end of the month, and I can truly understand your lack of sleep

Good luck for both of you !

[jerome]

Hey guys (father speaking)... Congrats 

 

... and start to forget the concept of "free time" 

 

Until now, you just believe you have no time for this or that.

You will soon experiment the real time disappearance : some kind of spacio-temporal-baby vortex.

 

 

 

 

 

 

 

 

But don't worry, it doesn't last more than dozen of years 

[jahow]

Hey DK, don't worry, the community on this forum is more than capable of finding a solution to this issue. And congratulations

 

Let's first take a look at what's written out there:

https://www.opengl.org/wiki/Transparency_Sorting -> gives pretty much the same conclusion than DK: there is no way to render perfectly several overlapping translucent polygons. The current implementation in BJS is what is considered "good enough for most cases".

http://www.openglsuperbible.com/2013/08/20/is-order-independent-transparency-really-necessary/ -> talks about the use of A-buffer to do per-pixel, order-independant transparency rendering. I don't think this would be reasonable in a WebGL environment, where CPU time is already a rare commodity.

http://stackoverflow.com/questions/15994944/transparent-objects-in-threejs -> how Three.JS handles the issue. I think it's interesting.

 

Now, with the suggestions regarding BJS:

1/ I was suggesting mesh/node ordering by depth, since this would help solve many issues, especially the one raised by Fenomas in the PG. Actually the idea would be to group sprites, translucent meshes & particle generators and order all these guys by depth. Even if particles are rendered in one batch, these could be easily rendered before or after the translucent wall, thus resolving this particular issue. It's not perfect, but it's already a little better.

2/ I think that mesh sorting in general plays an important role in performance as well as visual render. A developer might chose to order opaque meshes by material to gain performance, or to organize meshes by layers to avoid z-fighting or make sure certain things are drawn on top.

 

How about we add a way for advanced users to manually change the way meshes are sorted (and if they must be sorted at all)? Something like:

scene.sortingFunctions.opaqueMeshesFunction = null;     // no sorting will be done on thesescene.sortingFunctions.transparentMeshesFunction = BABYLON.Scene.DefaultSortingFunctions.SortByDepth;scene.sortingFunctions.particleGeneratorsFunction = function(node1, node2) {   // sort stuff, returns -1, 0 or 1 etc.}

Now that I think of it, this solution is pretty gross and verbose... and may need a serious refactoring of the scene rendering code. Anyway, that may spark genius ideas in someone else's brain.

 

Final note: this is an important issue. Most WebGL applications will use transparency (and not juste alpha test) one way or the other.

[Wingnut]

Congrats on the fatherhood, DK!  I thought it was only Temechon that was having a baby.  You guys are really good coders... considering you still have properly working... ummm...  social lives. 

 

Damn, programmers with girlfriends.  Whooda?  Pretty rare, here in the USA.  I was living with a girl in South Dakota once, and I got caught coding an Al Gore rhythm that tried to get her to go away. 

 

(I had to install a new roof on our doublewide trailer... for punishment)

 

French woman, dk?  Probably so.  American women will not let you compute (or have any other enjoyment) after you've kissed them once. 

 

@Jerome - "spacio-temporal-baby vortex"  hahaha  Hey J... you're an IT pro, right?  When you wire-up and fire-up networks, do you consider the wires/signals between them... as "tubes"?    You seem to be completely engulfed in the land of tubes.  Conversely, I have not spent any time with a tube... in quite a few years.  Odd for a musician.  We have a reputation for wilingness to be with ANY tube. 

 

What was the subject, again?  Oh yeah, that "ordering" stuff.  hmm.

[fenomas]

DK: oh, if it's basically impossible then it's just a FOL, which is all I wanted to ask. I just thought you were saying that it could be added if there was a use case. And congrats on the baby of course. I hear "Pixel" is a nice name for a girl...

 

 

Now speaking only to people without impending family additions:

 

The broader point, I think, is that limitations like this may be stupidly obvious to GL programmers, but regular users of a framework naturally assume that feature A works with feature B unless the docs say otherwise. I don't think it's just me, I've noticed that many of the forum threads are variations on "why don't my sprites cast shadows?" and so forth. So I think it would be helpful if someone who knows how the features interrelate could do a pass over the tutorials, or construct a compatibility guide. If the docs say X doesn't composite with Y then users will plan their scenes around that, but without such info people waste time building scenes that can't work, then waste more time asking in the forum what they've done wrong, and eventually make DK grumpy with their idiocy.

 

So basically if someone could document incompatibilities, it would make DK happier, and thus a better father. Do it for Pixel.

[fenomas]

Jahow: Interesting, thanks! I think much of it is a question of simplicity vs. complexity. For example, one could imagine a 3D engine with a "scene.transparencyType"which could be "particles" or "transparent_meshes" but not both. That would limit the engine's expressiveness but at the same time it would be harder to create a scene that didn't work as intended. I guess Three's ability to turn depth sorting on or off per object is at the other end of the spectrum - presumably powerful but useless to anyone who doesn't understand the underlying internals.

 

Incidentally about sorting opaque meshes, I'm trying this now but my guess is it makes more sense to do at the application level, because in general you don't need to sort very often and you only want to do it at application-specific times (like after adding new meshes). But apart from that I don't understand any of this enough to comment.

[jahow]

I agree, documenting is critical. However I think transparency in itself is a vast enough topic to justify one dedicated tutorial.

 

How about adding such a tutorial (which I'd be more than happy to initiate), and then another page to document incompatibilites as a bullet-point list? Something like "Known incompatiblites" or even better: "Known limitations".

[GameMonetize]

Thanks guys (Pixel is awesome we decided to choose Lucy:))

 

Just a side note, we DO sort back to front transparent objects:

https://github.com/BabylonJS/Babylon.js/blob/master/Babylon/Rendering/babylon.renderingGroup.ts#L45

 

I think we can add more control to users over sort algorithm (A simple callabck function) and we can already control if a mesh render to depth buffer by changing it with onBeforeRender

 

But should we go further?

 

Edit: I like the "Known limitations" idea

[jahow]

I've added an article about transparency here: http://doc.babylonjs.com/page.php?p=25100

 

Working on the 'known limitations' page

 

As for the sorting order, after thinking about it I'm not sure this is really necessary. What would be great is be the ability to put meshes in different 'layers', that would give users a finer control on meshes visibility without sacrificing usability. Also showing & hiding groups of meshes would be easier.

[jerome]

Really useful !

Like it !

[GameMonetize]

Thanks a lot jahow! this is really fantastic

 

For layers, we already have it: mesh.renderingGroupId