Filters on containers in pixi-layers

[nicknack23]

I have an application with:

* multiple groups of sprites currently organized into containers
* one or more filters applied to each sprite group
* groups and individual sprites that overlay each other in default z-index order
* but some sprites need to be sent to a bottom or top layer (but still use the filters of their sprite group)

Core Pixi takes care of points 1-3 nicely and I was hoping to use pixi-layers for point 4. Here's a small example:
https://www.pixiplayground.com/#/edit/ocKhrG_qVPo6JvNlyneu-

On the left you see sprites A-F in default order. On the right I use pixi-layers to send B to the bottom and C to the top. This works fine so far. But there are also filters active which are not working.

To see the filters, activate line 9 and comment out line 8. This puts everything inside a standard container instead of a pixi-layers Stage, so pixi-layers is bypassed completely. Now you see the filters, but the layers no longer work.

There is a directly relevant issue in the repo:
https://github.com/pixijs/layers/issues/45

But since no Pixi devs have commented there, I'm not sure if this is a bug or if this is fundamentally impossible due to how pixi-layers works. I suspect the latter.

Which is it? Is there a (relatively) simple way to get the filters and layers working at the same time? In my real application I have multiple sprites in different filter groups that need to be rendered in the bottom layer (like B), or in the top layer (like C).

[ivan.popelyshev]

> But since no Pixi devs have commented there, I'm not sure if this is a bug or if this is fundamentally impossible due to how pixi-layers works. I suspect the latter.

2019 year. 

 

Im sorry, I dont have time right now to solve that. If you want to apply filter to LAYER , you have to add your own calculateBounds() to that layer, or filterArea, because there's no way layer gets correct bounds.

[ivan.popelyshev]

Oh, right, let me explain:

hgow filters work: suppose you have filter on it. Pixi takes temporary rendeTexture, renders element there, then with a shader its rendered on screen.

Now, consider structure

root -> container -> element
root -> layer

you applied filter to container, but moved element to "layer" via pixi-layers.

Now, how the heck filter is supposed to work on element? 

That's fundamental problem TREE STRUCTURE vs Z-ORDERING. Its not possible together. I implemented pixi-layers that way you actually can do that stuff, by applying filter to layer if you also specify its bounds somehow (via filterArea or somehitng like that). If you have great idea of "how to make API better that there will be determenistic way to handle filters in z-ordering" - please post it.
 

[ivan.popelyshev]

even easier task: imagine there're operations "RENDER ELEMENT", "PUSH FILTER", "POP FILTER". Now , please try arrange those operations in a list that will satisfy you

Edited October 5, 2021 by ivan.popelyshev

[ivan.popelyshev]

Quote

render B
render A
render D
render E
render F
render C

that's only for render, that's order you want. Now we have to add push filter and pop filter there to get desired result. Which one is it?

[ivan.popelyshev]

Hm, actually, if we add those filters on container to elements themselves - it has to work, however, it affects performance (basically, x3 on filters)!

Its possible to implement, but the problem is - how to distinguish filters that people want to take from parent container and filters they dont want to?

[nicknack23]

Wow, thank you for all the explanations! I did NOT expect five replies in just one hour - from the same person! ?

I assure you that there was no criticism in my question. I think Pixi is amazing, and even more amazing is the support you give absolutely everyone who posts in this forum. 

Quote

Im sorry, I dont have time right now to solve that. If you want to apply filter to LAYER , you have to add your own calculateBounds() to that layer, or filterArea, because there's no way layer gets correct bounds.

Maybe I'm misunderstanding what you mean. I don't really to apply filter to (all sprites in) LAYER, only some sprites. But when I try it as an experiment it works immediately even without calculateBounds or filterArea. For example, insert on line 42 in my example:
layers.main.filters = [blur, noise];

Quote

Hm, actually, if we add those filters on container to elements themselves - it has to work, however, it affects performance (basically, x3 on filters)!

Its possible to implement, but the problem is - how to distinguish filters that people want to take from parent container and filters they dont want to?

I understand that applying filters to every individual sprite would be very bad for performance (I don't understand how you get x3, but no matter). And I admit I didn't consider that other people might NOT want to apply filters from a container after they set parentLayer to something else. In my application I simply want to keep all the filters.

This is my mental model (very wrong I'm sure) of what pixi-layers currently does. Given the containers from my example, i.e.:

container   // container.filters = [alpha]
|- sprites A, B, C

container   // container.filters = [blur, noise]
|- sprites D, E, F

Then when you set B.parentLayer = BOTTOM and C.parentLayer = TOP, the tree get literally transformed to:

sprite B

container   // container.filters = [alpha]  (but not used inside layers)
|- sprite A

container   // container.filters = [blur, noise]  (but not used inside layers)
|- sprites D, E, F

sprite C

Instead, I would like pixi-layers to copy parent container (maybe all ancestor containers?) along with the filters property:

container   // container.filters = [alpha]
|- sprite B

container   // container.filters = [alpha]
|- sprite A

container   // container.filters = [blur, noise]
|- sprites D, E, F

container   // container.filters = [alpha]
|- sprite C

Then there could be an aggregation step to improve performance so that consecutive functionally identical containers get aggregated:

container   // container.filters = [alpha]
|- sprite B, A

container   // container.filters = [blur, noise]
|- sprites D, E, F

container   // container.filters = [alpha]
|- sprite C

And finally it would be rendered as usual. All this probably makes no sense considering how pixi-layers is ACTUALLY implemented. But that's my mental model and what led me to post my question. In my fantasy world this might actually work. ? And again, I'm assuming that everyone wants to keep all parent filters.

[ivan.popelyshev]

OK, that's very helpful. We need that mode

[nicknack23]

Glad you appreciate the idea! I'll post a link to this discussion in that Github issue.