Pixi.js: Multisampled textures not handled at all in PixiJS internally

[SukantPal]

@ivanpopelyshev When you created multisampled textures with renderbuffers, you introduced an extra step in the render process:

msaaTexture.framebuffer.multisample = 16;

renderer.render(displayObject, msaaTexture);
renderer.framebuffer.blit();

This makes it very problematic to the extent that PixiJS itself fails to take care of this extra step in masking.

No blit here:
https://github.com/pixijs/pixi.js/blob/064135e795dbfe7b53248ff457d71cb8536077ac/packages/core/src/mask/StencilSystem.ts#L93

@bigtimebuddy I would propose that we do a blit in renderer#render and save the user all future hassle. What do you think?

Pen :pen:

Here's an example that fails with masking (comment out graphics.mask = mask, and it'll work):

https://codepen.io/sukantpal/pen/abNwBoN

[ivanpopelyshev]

We should add an if there like in FilterSystem, its logical.

According to https://github.com/gameofbombs/pixi-blit/blob/master/src/RenderBufferGL2.ts#L43 in my real production usecase, blit after render can be used to copy stuff to different renderTexture, so forcing blit()is not an option.

If we transform renderer.render arguments to object form, we can add extra flag "whether to blit stuff". Whether to set it to true by default is not important.

[SukantPal]

You don’t really need to add an if b/c framebuffer.blit() already checks for it. What do you think about moving the blit into Renderer#render?

Sent from my iPad

On Aug 29, 2020, at 8:25 AM, Ivan Popelyshev [e-mail] wrote:



We should add an if there like in FilterSystem, right?

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://github.com/pixijs/pixi.js/issues/6844#issuecomment-683283693, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFLJDB3TDXDWUBYOVEKW3U3SDDXUXANCNFSM4QOU52EA.

[ivanpopelyshev]

Wait, i still dont udnerstand why doesnt your example work.

I just told you what i think about moving it there.

[SukantPal]

@ivanpopelyshev Sorry, that part of your message didn't go into my email. The circle in the example won't show up on a WebGL-2 enabled browser.

[ivanpopelyshev]

Because i edit my messages. most of the time.

[bigtimebuddy]

I'm in favor of options for render. What do you think about these two signatures?

render(displayObject, options)
render(displayObject, renderTexture, options)

Where options is:

• clear
• transform
• skipUpdateTransform
• blit (proposed)

[SukantPal]

+1

[SukantPal]

We should also create a “renderer.flush” method so users don’t have to both flush the batch renderer and blit the framebuffer after rendering a display-object.

On Sep 12, 2020, at 6:12 AM, Matt Karl <[email protected][e-mail]> wrote:

I'm in favor of options for render. What do you think about these two signatures?

render(displayObject, options)
render(displayObject, renderTexture, options)

Where options is:

• clear
• transform
• skipUpdateTransform
• blit (proposed)

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://github.com/pixijs/pixi.js/issues/6844#issuecomment-691462257, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFLJDB3SI4HC7NH4VV4UJIDSFNCRTANCNFSM4QOU52EA.

[GoodBoyDigital]

both good! no super strong opinion. probably option one! something for next major version?

[ivanpopelyshev]

Finally! As prophecied!

Option two, because most of external calls will be done with renderTexture, and default options are good for case when renderTexture===null

[SukantPal]

I think doing both would be okay since the render() is not hot.