TAA Rendering Pipeline Not Working

Bugs
1

The TAARenderingPipeline has stopped working since version 8.24.1 when using a MultiRenderTarget in the pipeline. I have tested on 8.25.0 and above but still encounter the issue. It works as expected on versions prior to 8.24.0.

This playground demonstrates the issue. Commenting out the line which adds the MultiRenderTarget to the camera makes TAA apply as expected.

1 Like
3

Thanks for reporting, this PR will fix the problem:

3 Likes
5

Thanks for that!

1 Like
7

Hi again,

Iā€™ve noticed that there still appears to be an issue with TAA when both a Multi Render Target and a Post Process is used. The sandbox demonstrates the problem. Seems like any post process causes it.

8

The TAA post-process should be the first one of the camera, so TAARenderingPipeline should be created before any other post-process:

I updated the documentation to make it clear:

Note that using a frame graph works out of the box:

2 Likes
9

Hmm, I see. Needing to have the TAA first in the pipeline seems to not work with my edge rendering technique.

The screenshots are an example of a post process edge detection shader which prior to version 8.24, worked quite nicely with the TAA, but it appears that since this is a post process technique it is no longer captured by the TAA shader.

Before 8.24:

image
image465Ɨ255 22.9 KB

After 8.24:

image
image396Ɨ270 15.5 KB

Iā€™ve included a playground with a simplified version of the edge detection shader that shows that the TAA isnā€™t able to anti-alias the edges themselves.

10

In this case, you should create the TAA rendering pipeline after the edge post-process, but set the new properties:

taa.reprojectHistory = true;
taa.clampHistory = true;

Additional bonus: you can also set taa.disableOnCameraMove = false; to keep TAA even if the camera moves, as the new options get rid of the ghosting effect (see Babylon.js docs).

1 Like
11

Sorry to continue to bother you about this. Iā€™ve noticed that there is potentially a bug in the reprojectHistory mechanism that causes a ā€˜too much recursionā€™ error to occur sometimes.

It happens here when I comment out the line that adds the standard material:

And it happens here when I add TAA before the meshes are created:

Another thing Iā€™ve noticed, which is not necessarily a bug but itā€™s inconvenient, is that reprojectHistory breaks materials that use layout (location = 1) as an output because presumably the motion vector texture is bound to that location and causes a conflict.

12

There is a reentrancy issue with the default scene material and material plugins when the material plugins are registered before the default material is created. The easiest way to resolve this issue is to create this material immediately after creating the scene by executing scene.defaultMaterial;:

Pre-pass rendering must be enabled to generate the motion vector texture, so it will use (at least) one additional texture for this. You will need to take this into account if you want to generate an additional output texture yourself.

2 Likes
13

Thanks for exploring these issues with me, I appreciate it.

14

Hi, sorry to revisit this. There still seems to be an issue with Material Plugins and reproject history, or perhaps Iā€™m misunderstanding something. If you comment out line 23 here the material behaves correctly but with it enabled it is like the plugin material isnā€™t applied at all.

15

Thatā€™s because the black and white plugin is not implemented to be usable with the prepass renderer.

It directly modifies gl_FragColor, whereas it should modify color, so that the right color is recorded in the prepass color texture: