Post Process doesn't work

I’m implementing it using the code in this project.

However, it doesn’t work well in the iPhone browser.

https://launch.playcanvas.com/1070362

Cause
I noticed that it was because the version of PlayCanvas Engine was up.

https://launch.playcanvas.com/1070362?use_local_engine=https://code.playcanvas.com/playcanvas-1.38.2.js

Is it possible to get this to work with the current version?
Or is there any other good solution?

Hi, @sutobu000, and welcome to PlayCanvas!

Could you please describe what happens on the iPhone? What is the visual defference between the engine releases?

Hi!
The latest version looks like the image.
The outline remains like an afterimage.

There is no afterimage in v1.38.2.

This only happens on iPhone.

@mvaligursky this looks like a similar issue to this thread Engine change to frame pushing / z buffer?

yes that looks similar … please set app.scene.layers.logRenderActions to true and see what it logs into the console. You can do that on PC, the results are the same. It’s likely from that you will be able to spot if some color buffer clear is missing on a camera or a layer perhaps?

I set app.scene.layers.logRenderActions to true.

sorry… I don’t understand even if I look at this…

That seems ok. Looking at lines where meshes are non 0 (so something gets rendered), this is the meaning:

  1. camera “Untitled” is rendered to render target called “Untitled”. It clears color, depth and stencil buffer of that render target.
  • Layer Normal gets rendered to it.
  1. camera “Camera” is rendered to render target "“Camera-posteffect-0” (this is target created by post processing). Again this clears color, depth and stencil of this target.
  • this renders one mesh on layer World.
  • then when Immediate layer is done (just before UI), a postprocessing attached to this camera runs.

so all this seems ok, I dont see any obvious problems.

We have an issue at the moment with some non-power of 2 textures on WebGl1 … I wonder if this is related. Try running this in WebGl1 mode in different browsers on PC to see if you can repro it?

2 Likes

Thanks for the clear explanation!

I tried running it on WebGL1.

I checked with the following devices and browsers.

  • [Windows] Chrome, Firefox, Edge
  • [Mac] Chrome, Safari
  • [iOS14.4] Chrome, Safari

All of the above results are like the image.

Did the problem occur because it didn’t support WebGL 2.0?

2 Likes

I suspect it’s related to WebGl1, yes … and your tests seems to confirm that.
There’s a custom path to render depth on WebGl, as depth buffer cannot be used … so perhaps the difference is there. Maybe try and capture log with app.scene.layers.logRenderActions on WebGl1? Maybe there’s a clear missing on depth or something.

I set app.scene.layers.logRenderActions on WebGl1.

I see the following has changed.

[WevGL2.0]
3 Cam: Camera Lay: Depth OPAQUE ENABLED Meshes: 0 RT: rt-depth2

[WevGL1.0]
3 Cam: Camera Lay: Depth OPAQUE ENABLED Meshes: 0 RT: rt-depth1

Does rt-depth1 mean depth?

1 Like

try this to clear the depth layer perhaps. Not sure as refactoring of the depth texture rendering is still ahead of me - at the moment its integration is not ideal and limited.

Maybe you can for now try and remove dependency on depth edges? That would confirm the depth access is the problem.

var depthLayer = app.scene.layers.getLayerByName("Depth");
depthLayer.clearColorBuffer = true;
depthLayer.clearDepthBuffer = true;
depthLayer.clearStencilBuffer = true;
2 Likes

WOW!
This is exactly what I was looking for!

Thank you for leading me to the correct answer!

so what’s new? have you got it to work?

I tried this with “initialize” and it worked fine with webGL 1.0 as well.

The afterimage has disappeared.
This is what I was looking for.

[Add]
I’ve confirmed that this works correctly in Safari on the iPhone!

2 Likes

by the way, have you thought of using https://wickedengine.net/2019/09/22/improved-normal-reconstruction-from-depth/ ?
if this effect is used on large scene, it could save a lot of cpu time to not have to re-render the scene to the normal map.

3 Likes

I’ve used that approach for the world position of pixel rays to calculate screen space ambient occlusion, it worked quite ok in both webgl 1/2.

2 Likes

I wasn’t thinking of this way.
I will try this as well.

Thank you!!