Post-Process example #5648

enzofrancescaHM · 2025-01-30T09:56:11Z

Description:
Minimal example to show the possibility of implementing Post-Processing in A-Frame.
NOTE: for Post-Processing to work also in VR mode, supermedium/three.js#20 must be implemented in supermedium three.
Changes proposed:
-index.html running a simple scene with simple geometries with and without emission
-bloom.js, a minimal implementation of Bloom effect

vincentfretin · 2025-01-30T11:06:43Z

Where does all those 1087 lines of code comes from?
You should be able to import the postprocessing library with an importmap, I advice you to base your example on the new importmap example https://github.com/aframevr/aframe/blob/master/examples/boilerplate/importmap/index.html and write a small bloom component of a few lines.
The bloom effect integration in r3f is just this https://github.com/pmndrs/react-postprocessing/blob/master/src/effects/Bloom.tsx

enzofrancescaHM · 2025-01-30T16:01:17Z

Where does all those 1087 lines of code comes from? You should be able to import the postprocessing library with an importmap, I advice you to base your example on the new importmap example https://github.com/aframevr/aframe/blob/master/examples/boilerplate/importmap/index.html and write a small bloom component of a few lines. The bloom effect integration in r3f is just this https://github.com/pmndrs/react-postprocessing/blob/master/src/effects/Bloom.tsx

Yes, thanks for pointing that, I completely missed the new feature of A-Frame to use importmap. Sorry for that, I've reduced the bloom.js to the bare minimum to work.

examples/post-process/index.html

examples/post-process/bloom.js

vincentfretin · 2025-01-30T16:58:51Z

Yes, thanks for pointing that, I completely missed the new feature of A-Frame to use importmap

That new importmap example exist since 2 days ago ;) I'm glad I did it so we can have a simpler example here without copying all the code.

examples/post-process/bloom.js

vincentfretin · 2025-01-30T17:02:00Z

Didn't we agree from supermedium/three.js#20 to use
https://github.com/pmndrs/postprocessing that is more performant than the three/addons effect composer?

dmarcos · 2025-01-30T17:17:34Z

Didn't we agree from supermedium/three.js#20 to use https://github.com/pmndrs/postprocessing that is more performant than the three/addons effect composer?

Whatever yields 90fps with the simpler code and least amount of dependencies

enzofrancescaHM · 2025-01-30T17:45:24Z

Didn't we agree from supermedium/three.js#20 to use https://github.com/pmndrs/postprocessing that is more performant than the three/addons effect composer?

pmndrs does not work in VR at the moment. I have opened tickets there, but at the moment no one is working on it.

Typo Co-authored-by: Noeri Huisman <[email protected]>

deleted useless tick function Co-authored-by: Noeri Huisman <[email protected]>

dmarcos · 2025-01-31T08:13:39Z

I merged THREE changes and updated A-Frame so should work on top of master.

Can you put the examples under showcase and rename to post-processing: showcase/post-processing?

Thanks so much for all the effort

examples/post-process/bloom.js

mrxz · 2025-01-31T09:08:35Z

examples/post-process/bloom.js

+    this.scene = this.el.object3D;
+    this.renderer = this.el.renderer;
+    this.camera = this.el.camera;
+    this.composer = new EffectComposer(this.renderer);


Instead of recreating EffectComposer, RenderPass and UnrealBloomPass each update, they can be created once in init and only updated here.

mrxz · 2025-01-31T09:09:40Z

examples/post-process/bloom.js

+  },
+  bind: function () {
+    const render = this.renderer.render;
+    const system = this;


Nitpick: this isn't a system, probably better to name it self.

examples/post-process/bloom.js

mrxz · 2025-01-31T09:36:11Z

examples/post-process/bloom.js

+ * Unreal Bloom Effect
+ * Implementation for A-Frame
+ * Code modified from Akbartus's UnrealBloomPass.js
+ * https://github.com/akbartus/A-Frame-Component-Postprocessing


Given that the source is MIT licensed, the original copyright and license notice should be included.

vincentfretin · 2025-01-31T10:01:08Z

examples/post-process/index.html

+          "imports": {
+            "aframe": "../../dist/aframe-master.module.min.js",
+            "three": "https://cdn.jsdelivr.net/npm/[email protected]/build/three.module.js",
+            "three/addons/": "https://cdn.jsdelivr.net/npm/[email protected]/examples/jsm/"


It should be

"three": "../../../super-three-package/build/three.module.js", "three/addons/": "../../../super-three-package/examples/jsm/",

like https://github.com/aframevr/aframe/blob/master/examples/boilerplate/importmap/index.html
so it uses the three version from node_modules.

vincentfretin · 2025-01-31T10:02:02Z

examples/post-process/index.html

+          shadow="type: pcfsoft; autoUpdate: true" 
+          background="color:black;"        
+          renderer="anisotropy:4; stencil:true; alpha:false; colorManagement:true; exposure:1.0;"
+          bloomm="threshold: 1.0; strength: 0.6; radius: 1; exposure: 1.0">


Does the example still work? there is two m here.

enzofrancescaHM · 2025-02-05T19:19:49Z

Wow, amazing work @mrxz ! Yes, as you were saying the effect seems a little bit cheaper than the one on this PR, but it is super acceptable and nice. Maybe two paths with different levels of quality / performance are the right way. And, I agree that we should merge and than iterate over it.

dmarcos · 2025-02-05T19:29:47Z

Wow, amazing work @mrxz ! Yes, as you were saying the effect seems a little bit cheaper than the one on this PR, but it is super acceptable and nice. Maybe two paths with different levels of quality / performance are the right way. And, I agree that we should merge and than iterate over it.

Haven't tried in VR. Is the "more expensive" one noticeably better visually? If yes two paths is fine. If not maybe we can just have the cheaper one.

enzofrancescaHM · 2025-02-05T20:17:41Z

mrxz · 2025-02-05T20:34:49Z

The UnrealBloomPass uses multiple different Gaussian blur radii and combines them. Instead I only approximate one (large) blur and composite it, similar to what PlayCanvas is doing. The larger the intended bloom radius, the more noticeable the difference will be.

But it's actually possible to get closer while still (though barely) maintaining 90fps on Quest 2. See: https://thrilling-alkaline-headline.glitch.me/index2.html

This PR	Old	New

But it becomes questionable how useful a post processing effect is that eats up practically all your rendering budget.

Any improvements you can suggest on this PR for Quest2?

The biggest gains are in reducing the render targets used while rendering, but this is mostly caused by the internal implementation of the EffectComposer and UnrealBloomPass. So not much that can be done without modifying them directly or 'forking' them. Not sure if that's the best approach for an example. In that sense it might be worth looking into pmndrs/postprocessing as they do combine passes where possible.

One thing that can be done is optimizing the car asset using gltf-transform, as it does cause more draw calls than needed. But that isn't directly related to the bloom effect, of course.

enzofrancescaHM · 2025-02-05T20:48:19Z

I think your new iteration looks very good! Yes, it is very veery similar to the PR's one.

dmarcos · 2025-02-05T21:08:44Z

How much of the rendering budget is used in Quest3? How much is reasonable? Any target we should aim at?

mrxz · 2025-02-06T11:45:30Z

How much of the rendering budget is used in Quest3? How much is reasonable? Any target we should aim at?

Depends on too many factors to give a concrete answer on what is reasonable. In general I think users just want to "slap on bloom". In that sense the implementation in this PR is limiting for Quest 3. It pushes the GPU to the highest clock level (4) and GPU utilization is consistently >90%. You'll probably have a hard time adding much more to the scene, making it only really suitable for relatively small experiences. Although users could experiment with targetting 72fps and/or use viewport scaling (https://immersive-web.github.io/webxr/#dom-xrview-requestviewportscale).

With https://thrilling-alkaline-headline.glitch.me/index2.html the Quest 3 remains at GPU level 2 in my testing. Though worth pointing out that due to the way it works the bloom effect isn't a fixed-cost and does actually scale with the overall scene complexity. But at the very least there is clearly headroom.

It also depends on what you want from the bloom effect. The current demo scene is setup with a fairly large bloom effect. If someone only cares about a subtle glow around lights/neon-signage a cheaper blur method is probably good enough and less demanding.

dmarcos · 2025-02-06T12:57:01Z

How much of the rendering budget is used in Quest3? How much is reasonable? Any target we should aim at?

Depends on too many factors to give a concrete answer on what is reasonable. In general I think users just want to "slap on bloom". In that sense the implementation in this PR is limiting for Quest 3. It pushes the GPU to the highest clock level (4) and GPU utilization is consistently >90%. You'll probably have a hard time adding much more to the scene, making it only really suitable for relatively small experiences. Although users could experiment with targetting 72fps and/or use viewport scaling (https://immersive-web.github.io/webxr/#dom-xrview-requestviewportscale).

With https://thrilling-alkaline-headline.glitch.me/index2.html the Quest 3 remains at GPU level 2 in my testing. Though worth pointing out that due to the way it works the bloom effect isn't a fixed-cost and does actually scale with the overall scene complexity. But at the very least there is clearly headroom.

It also depends on what you want from the bloom effect. The current demo scene is setup with a fairly large bloom effect. If someone only cares about a subtle glow around lights/neon-signage a cheaper blur method is probably good enough and less demanding.

Thanks. We should probably limit to Quest3 and up then. People slapping bloom (without understanding the cost) representing 90% of post processing demand is the reason why I resisted. It’s good this PR is just an example. Some friction to use it but enables those that want to experiment.

enzofrancescaHM · 2025-02-06T13:03:27Z

I agree, this PR is for opening the way to Post-Process in VR in A-Frame, implementation is not finished here and it is good to leave room for experimenting and improving. With this PR merged we can also push other repos to contribute, i.e. pmndrs/post-processing. At the moment it does not work in VR but yesterday I've managed to make it work, maybe I can open some discussions over there to have more tools to use.

cabanier · 2025-02-06T17:26:34Z

How much of the rendering budget is used in Quest3? How much is reasonable? Any target we should aim at?

Depends on too many factors to give a concrete answer on what is reasonable. In general I think users just want to "slap on bloom". In that sense the implementation in this PR is limiting for Quest 3. It pushes the GPU to the highest clock level (4) and GPU utilization is consistently >90%. You'll probably have a hard time adding much more to the scene, making it only really suitable for relatively small experiences. Although users could experiment with targetting 72fps and/or use viewport scaling (https://immersive-web.github.io/webxr/#dom-xrview-requestviewportscale).

FYI Quest Browser 36.5 added support for dynamic viewport scaling so you could ask to render fewer pixels if you see the framerate dip. Does the current approach allow for dynamic resizing of render targets?

It also depends on what you want from the bloom effect. The current demo scene is setup with a fairly large bloom effect. If someone only cares about a subtle glow around lights/neon-signage a cheaper blur method is probably good enough and less demanding.

Simply activating post-processing will still cause all those flushes.
The solution is very similar to what you (@mrxz ) did for reflections: you need to pre-process the render targets ahead of time and then have 2 passes (1 scene render + 1 postprocess). That should fix a lot of the problems.

mrxz · 2025-02-06T17:40:37Z

The solution is very similar to what you (@mrxz ) did for reflections: you need to pre-process the render targets ahead of time and then have 2 passes (1 scene render + 1 postprocess). That should fix a lot of the problems.

I don't see how you could bring a bloom effect down into a single pass. You will need to perform a blur, which is going to require either ping-pong between two targets or consecutive downsampling and upsampling steps. Unless you do the full kernel per fragment, but that is prohibitively expensive.

@cabanier Did you try this demo https://thrilling-alkaline-headline.glitch.me/index2.html?
It's a different approach where the bloom is rendered ahead of time and overlaid when forward rendering the scene. It performs surprisingly well (stable 90fps on Quest 3, ~90fps on Quest 2), despite the many intermediate passes for down/up-sampling.

ovrgpuprofiler trace

Surface 0    | 3360x1760 | color 32bit, depth 24bit, stencil 0 bit, MSAA 4, Mode: 0 (Direct)    | 1   3360x1760 bins ( 1   rendered) |  0.00 ms | 1   stages : Render : 0.002ms
Surface 1    | 1680x880  | color 32bit, depth 24bit, stencil 0 bit, MSAA 1, Mode: 1 (HwBinning) | 4   864x448 bins ( 4   rendered) |  0.81 ms | 14  stages : Binning : 0.152ms Render : 0.588ms StoreColor : 0.012ms Blit : 0.005ms StoreDepthStencil : 0.014ms
Surface 2    | 840 x440  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   864x448 bins ( 1   rendered) |  0.13 ms | 2   stages : Render : 0.124ms StoreColor : 0.002ms
Surface 3    | 420 x220  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   480x224 bins ( 1   rendered) |  0.04 ms | 2   stages : Render : 0.034ms StoreColor : 0.003ms
Surface 4    | 210 x110  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   288x128 bins ( 1   rendered) |  0.02 ms | 2   stages : Render : 0.015ms StoreColor : 0.002ms
Surface 5    | 105 x55   | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   192x64  bins ( 1   rendered) |  0.02 ms | 2   stages : Render : 0.011ms StoreColor : 0.003ms
Surface 6    | 52  x27   | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   96 x32  bins ( 1   rendered) |  0.01 ms | 2   stages : Render : 0.008ms StoreColor : 0.002ms
Surface 7    | 26  x13   | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   96 x32  bins ( 1   rendered) |  0.01 ms | 2   stages : Render : 0.008ms StoreColor : 0.003ms
Surface 8    | 52  x27   | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   96 x32  bins ( 1   rendered) |  0.01 ms | 2   stages : Render : 0.008ms StoreColor : 0.002ms
Surface 9    | 105 x55   | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   192x64  bins ( 1   rendered) |  0.01 ms | 2   stages : Render : 0.009ms StoreColor : 0.003ms
Surface 10   | 210 x110  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   288x128 bins ( 1   rendered) |  0.02 ms | 2   stages : Render : 0.012ms StoreColor : 0.003ms
Surface 11   | 420 x220  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   480x224 bins ( 1   rendered) |  0.03 ms | 2   stages : Render : 0.025ms StoreColor : 0.003ms
Surface 12   | 840 x440  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   864x448 bins ( 1   rendered) |  0.08 ms | 2   stages : Render : 0.079ms StoreColor : 0.003ms
Surface 13   | 640 x335  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   672x352 bins ( 1   rendered) |  0.06 ms | 2   stages : Render : 0.05ms StoreColor : 0.003ms
Surface 14   | 105 x55   | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   192x64  bins ( 1   rendered) |  0.01 ms | 2   stages : Render : 0.009ms StoreColor : 0.002ms
Surface 15   | 210 x110  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   288x128 bins ( 1   rendered) |  0.02 ms | 2   stages : Render : 0.012ms StoreColor : 0.002ms
Surface 16   | 420 x220  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   480x224 bins ( 1   rendered) |  0.03 ms | 2   stages : Render : 0.026ms StoreColor : 0.002ms
Surface 17   | 840 x440  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   864x448 bins ( 1   rendered) |  0.08 ms | 2   stages : Render : 0.079ms StoreColor : 0.003ms
Surface 18   | 640 x335  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   672x352 bins ( 1   rendered) |  0.06 ms | 2   stages : Render : 0.05ms StoreColor : 0.003ms
Surface 19   | 210 x110  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   288x128 bins ( 1   rendered) |  0.02 ms | 2   stages : Render : 0.012ms StoreColor : 0.002ms
Surface 20   | 420 x220  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   480x224 bins ( 1   rendered) |  0.03 ms | 2   stages : Render : 0.026ms StoreColor : 0.003ms
Surface 21   | 840 x440  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   864x448 bins ( 1   rendered) |  0.08 ms | 2   stages : Render : 0.079ms StoreColor : 0.003ms
Surface 22   | 640 x335  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   672x352 bins ( 1   rendered) |  0.06 ms | 2   stages : Render : 0.05ms StoreColor : 0.003ms
Surface 23   | 420 x220  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   480x224 bins ( 1   rendered) |  0.03 ms | 2   stages : Render : 0.026ms StoreColor : 0.002ms
Surface 24   | 840 x440  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   864x448 bins ( 1   rendered) |  0.08 ms | 2   stages : Render : 0.079ms StoreColor : 0.003ms
Surface 25   | 640 x335  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   672x352 bins ( 1   rendered) |  0.05 ms | 2   stages : Render : 0.05ms StoreColor : 0.002ms
Surface 26   | 840 x440  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   864x448 bins ( 1   rendered) |  0.08 ms | 2   stages : Render : 0.078ms StoreColor : 0.003ms
Surface 27   | 640 x335  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   672x352 bins ( 1   rendered) |  0.06 ms | 2   stages : Render : 0.05ms StoreColor : 0.002ms
Surface 28   | 3360x1760 | color 32bit, depth 24bit, stencil 0 bit, MSAA 4, Mode: 1 (HwBinning) | 72  288x320 bins ( 38  rendered) |  5.20 ms | 82  stages : Binning : 0.775ms Render : 1.777ms StoreColor : 0.422ms Blit : 0.005ms Preempt : 1.854ms

cabanier · 2025-02-06T18:30:15Z

The solution is very similar to what you (@mrxz ) did for reflections: you need to pre-process the render targets ahead of time and then have 2 passes (1 scene render + 1 postprocess). That should fix a lot of the problems.

I don't see how you could bring a bloom effect down into a single pass. You will need to perform a blur, which is going to require either ping-pong between two targets or consecutive downsampling and upsampling steps. Unless you do the full kernel per fragment, but that is prohibitively expensive.

yes, bloom still needs a separate pass.

Looking at your trace, you can see that we bound to the swapchain texture, but then immediately switch:
Surface 0 | 3360x1760 | color 32bit, depth 24bit, stencil 0 bit, MSAA 4, Mode: 0 (Direct) | 1 3360x1760 bins ( 1 rendered) | 0.00 ms | 1 stages : Render : 0.002ms
After this, I'm unsure if foveation is still working

The second pass is likely rendering the scene (with no MSAA and only half the resolution?) and since it's so simple, it renders quickly. (My proposal to foveate any texture would likely make little difference in this case)
Surface 1 | 1680x880 | color 32bit, depth 24bit, stencil 0 bit, MSAA 1, Mode: 1 (HwBinning) | 4 864x448 bins ( 4 rendered) | 0.81 ms | 14 stages : Binning : 0.152ms Render : 0.588ms StoreColor : 0.012ms Blit : 0.005ms StoreDepthStencil : 0.014ms
You're also storing depth for no reason. Maybe you can discard it to save some time?

Do you know what all these other small items are that are rendered each frame? if they don't change, maybe they can be cached.

At the very end, there is an expensive pass which is likely unvoidable. I suspect that foveation would still help.

That being said, this trace is looking a LOT better than the one I capture 2 days ago!

mrxz · 2025-02-06T23:06:20Z

@cabanier Thanks for you insights

After this, I'm unsure if foveation is still working

Visually foveation is definitely still active. There are no draw/clear calls issued at this stage so that might explain why. Either way, after avoiding this switch it didn't really impact the trace much:

ovrgpuprofiler trace

Surface 0    | 1680x880  | color 32bit, depth 24bit, stencil 0 bit, MSAA 1, Mode: 1 (HwBinning) | 4   864x448 bins ( 4   rendered) |  0.83 ms | 14  stages : Binning : 0.137ms Render : 0.629ms StoreColor : 0.012ms Blit : 0.005ms StoreDepthStencil : 0.011ms
Surface 1    | 840 x440  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   864x448 bins ( 1   rendered) |  0.14 ms | 2   stages : Render : 0.133ms StoreColor : 0.003ms
Surface 2    | 420 x220  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   480x224 bins ( 1   rendered) |  0.04 ms | 2   stages : Render : 0.033ms StoreColor : 0.003ms
Surface 3    | 210 x110  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   288x128 bins ( 1   rendered) |  0.02 ms | 2   stages : Render : 0.015ms StoreColor : 0.003ms
Surface 4    | 105 x55   | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   192x64  bins ( 1   rendered) |  0.02 ms | 2   stages : Render : 0.011ms StoreColor : 0.003ms
Surface 5    | 52  x27   | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   96 x32  bins ( 1   rendered) |  0.01 ms | 2   stages : Render : 0.009ms StoreColor : 0.002ms
Surface 6    | 26  x13   | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   96 x32  bins ( 1   rendered) |  0.01 ms | 2   stages : Render : 0.008ms StoreColor : 0.003ms
Surface 7    | 52  x27   | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   96 x32  bins ( 1   rendered) |  0.01 ms | 2   stages : Render : 0.008ms StoreColor : 0.003ms
Surface 8    | 105 x55   | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   192x64  bins ( 1   rendered) |  0.01 ms | 2   stages : Render : 0.009ms StoreColor : 0.002ms
Surface 9    | 210 x110  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   288x128 bins ( 1   rendered) |  0.02 ms | 2   stages : Render : 0.013ms StoreColor : 0.003ms
Surface 10   | 420 x220  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   480x224 bins ( 1   rendered) |  0.03 ms | 2   stages : Render : 0.025ms StoreColor : 0.002ms
Surface 11   | 840 x440  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   864x448 bins ( 1   rendered) |  0.09 ms | 2   stages : Render : 0.08ms StoreColor : 0.003ms
Surface 12   | 640 x335  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   672x352 bins ( 1   rendered) |  0.06 ms | 2   stages : Render : 0.05ms StoreColor : 0.003ms
Surface 13   | 105 x55   | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   192x64  bins ( 1   rendered) |  0.01 ms | 2   stages : Render : 0.009ms StoreColor : 0.002ms
Surface 14   | 210 x110  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   288x128 bins ( 1   rendered) |  0.02 ms | 2   stages : Render : 0.012ms StoreColor : 0.002ms
Surface 15   | 420 x220  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   480x224 bins ( 1   rendered) |  0.03 ms | 2   stages : Render : 0.026ms StoreColor : 0.002ms
Surface 16   | 840 x440  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   864x448 bins ( 1   rendered) |  0.08 ms | 2   stages : Render : 0.079ms StoreColor : 0.003ms
Surface 17   | 640 x335  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   672x352 bins ( 1   rendered) |  0.06 ms | 2   stages : Render : 0.05ms StoreColor : 0.003ms
Surface 18   | 210 x110  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   288x128 bins ( 1   rendered) |  0.02 ms | 2   stages : Render : 0.012ms StoreColor : 0.002ms
Surface 19   | 420 x220  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   480x224 bins ( 1   rendered) |  0.03 ms | 2   stages : Render : 0.025ms StoreColor : 0.002ms
Surface 20   | 840 x440  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   864x448 bins ( 1   rendered) |  0.08 ms | 2   stages : Render : 0.079ms StoreColor : 0.003ms
Surface 21   | 640 x335  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   672x352 bins ( 1   rendered) |  0.60 ms | 3   stages : Render : 0.05ms StoreColor : 0.002ms Preempt : 0.488ms
Surface 22   | 420 x220  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   480x224 bins ( 1   rendered) |  0.04 ms | 2   stages : Render : 0.031ms StoreColor : 0.003ms
Surface 23   | 840 x440  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   864x448 bins ( 1   rendered) |  0.09 ms | 2   stages : Render : 0.08ms StoreColor : 0.003ms
Surface 24   | 640 x335  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   672x352 bins ( 1   rendered) |  0.06 ms | 2   stages : Render : 0.051ms StoreColor : 0.003ms
Surface 25   | 840 x440  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   864x448 bins ( 1   rendered) |  0.09 ms | 2   stages : Render : 0.081ms StoreColor : 0.003ms
Surface 26   | 640 x335  | color 32bit, depth 0 bit, stencil 0 bit, MSAA 1, Mode: 2 (SwBinning) | 1   672x352 bins ( 1   rendered) |  0.06 ms | 2   stages : Render : 0.051ms StoreColor : 0.003ms
Surface 27   | 3360x1760 | color 32bit, depth 24bit, stencil 0 bit, MSAA 4, Mode: 1 (HwBinning) | 72  288x320 bins ( 44  rendered) |  4.62 ms | 93  stages : Binning : 0.685ms Render : 2.201ms StoreColor : 0.389ms Blit : 0.005ms Preempt : 0.976ms

You're also storing depth for no reason. Maybe you can discard it to save some time?

I was aware, just didn't invalidate it yet as Three.js doesn't expose a convenient way to do so.

Do you know what all these other small items are that are rendered each frame? if they don't change, maybe they can be cached.

These are the blurring passes. That's what I meant with not seeing how you could bring the bloom effect down to one pass. Currently 5 different blur radii are combined, so there's definitely some saving possible at the expense of image quality. But even if we'd only want a subtle short length bloom, you'd at the very least have something like "main render" + "horizontal blur pass" + "vertical blur pass" + "bloom pass".

The only way I know to avoid this would be to do the full blur kernel for each pixel, but that can't possible be more performant. Though if there is some technique I'm missing, I'd love to know. Any reference to bloom implementations for Quest are also be appreciated.

At the very end, there is an expensive pass which is likely unvoidable. I suspect that foveation would still help.

This is indeed unavoidable, though a cheaper bloom based on a singular blur radius can still save almost 1 ms on this pass. Though obviously not sure how meaningful these time measurements are when the GPU level is at 2 (not fixed, just not seeing it jump up with this load).

Foveation is already active at this point as mentioned above. When I disable the foveation the render time does indeed shoot up. Interestingly enough the output using logcat | grep VrApi always reports Fov=0 even when it's clearly on. Is this expected? Can reproduce it with https://threejs.org/examples/?q=teleport#webxr_vr_teleport as well. The lines on the walls in this example make it easy to verify visually that it's active.

That being said, this trace is looking a LOT better than the one I capture 2 days ago!

Your previous capture was essentially just the stock EffectComposer + UnrealBloomPass, whereas this is a different approach entirely. Strictly speaking it isn't even post-processing, but it seems serviceable for the bloom effect. Sadly that also means that these results don't translate to other potential post processing effects.

cabanier · 2025-02-06T23:18:13Z

You're also storing depth for no reason. Maybe you can discard it to save some time?

I was aware, just didn't invalidate it yet as Three.js doesn't expose a convenient way to do so.

It's one of the things that will be fixed in the three.js redesign. As long as you clear the swapchain backed texture, you should still get foveation.
Is there a reason to render the scene without MSAA?

Do you know what all these other small items are that are rendered each frame? if they don't change, maybe they can be cached.

These are the blurring passes. That's what I meant with not seeing how you could bring the bloom effect down to one pass. Currently 5 different blur radii are combined, so there's definitely some saving possible at the expense of image quality. But even if we'd only want a subtle short length bloom, you'd at the very least have something like "main render" + "horizontal blur pass" + "vertical blur pass" + "bloom pass".

OK, since those passes are very fast, it doesn't look like a problem.

Foveation is already active at this point as mentioned above. When I disable the foveation the render time does indeed shoot up. Interestingly enough the output using logcat | grep VrApi always reports Fov=0 even when it's clearly on. Is this expected? Can reproduce it with https://threejs.org/examples/?q=teleport#webxr_vr_teleport as well. The lines on the walls in this example make it easy to verify visually that it's active.

Yes, that is expected. Because of the out-of-process nature of the Chromium renderer, we can't use the system API calls that set up foveation so it's not recorded in the tool.

That being said, this trace is looking a LOT better than the one I capture 2 days ago!

Your previous capture was essentially just the stock EffectComposer + UnrealBloomPass, whereas this is a different approach entirely. Strictly speaking it isn't even post-processing, but it seems serviceable for the bloom effect. Sadly that also means that these results don't translate to other potential post processing effects.

Great! The rendering of the scene itself would still benefit from foveation but we'll have to wait for that API to land.

mrxz · 2025-02-07T10:23:43Z

Is there a reason to render the scene without MSAA?

The main forward pass is the last one, which is using MSAA x4 as can be seen from the trace. No MSAA is used for the bloom input as it will get blurred anyway (blur is a great AA technique 😉) and resolving an HDR buffer still leaves aliasing artifacts around bright areas. So I don't see a reason to use MSAA there.

Great! The rendering of the scene itself would still benefit from foveation but we'll have to wait for that API to land.

Indeed, looking forward to trying that out. Also WEBGL_shader_pixel_local_storage could be interesting here. Currently blending happens in sRGB, which is all sorts of wrong, it just happens to look okay.

dmarcos · 2025-02-10T16:56:16Z

@enzofrancescaHM this is pretty close. let me know if you need any help. all the back and forth can be overwhelming 🙂

enzofrancescaHM · 2025-02-11T09:26:54Z

@dmarcos well, don't worry, my commitment is still very high. I'm waiting for you to take decision on the right path. My opinion is that all the proposed modifications by @mrxz are not resolutive, touching only a small subset of the performance issue by lowering the number of passes or the resolution of them. There is, of course, something else to change to drastically raise FPS, but at the moment I think there is no one that has the needed commitment to work on that. This PR is here also for demonstrating that Post-Processing is indeed possible in VR via A-Frame, I suggest to use the current example and merge, maybe using the optimized car model, and leave room for improvements in the future, counting on the fact that who wants to work on it can start from a working example and not from scratch.

dmarcos · 2025-02-11T14:37:11Z

@dmarcos well, don't worry, my commitment is still very high. I'm waiting for you to take decision on the right path. My opinion is that all the proposed modifications by @mrxz are not resolutive, touching only a small subset of the performance issue by lowering the number of passes or the resolution of them. There is, of course, something else to change to drastically raise FPS, but at the moment I think there is no one that has the needed commitment to work on that. This PR is here also for demonstrating that Post-Processing is indeed possible in VR via A-Frame, I suggest to use the current example and merge, maybe using the optimized car model, and leave room for improvements in the future, counting on the fact that who wants to work on it can start from a working example and not from scratch.

No changes on the effect for now in this PR. Just need to improve example as per comments.

enzofrancescaHM · 2025-02-11T19:28:48Z

@dmarcos ok, just to be sure, the improvements for the example are:

adapt the sample to use the proper info button in par with other examples
replace the car model with the optimized model proposed by @mrxz.
If anyone has something to add, please let me know so I do the last bunch of modifications. Thanks a lot.

dmarcos · 2025-02-11T19:56:14Z

@dmarcos ok, just to be sure, the improvements for the example are:

adapt the sample to use the proper info button in par with other examples

replace the car model with the optimized model proposed by @mrxz.
If anyone has something to add, please let me know so I do the last bunch of modifications. Thanks a lot.

Yep. That's most of it. Thanks so much! looking forward to shipping this in 1.7.0

enzofrancescaHM · 2025-02-12T10:01:45Z

@dmarcos ok, done.

examples/showcase/post-processing/message.html

examples/showcase/post-processing/index.html

dmarcos · 2025-02-14T18:05:03Z

examples/showcase/post-processing/index.html

+            toggleEffect();
+        });
+
+        leftHand.addEventListener('triggerup', (event) => {


This should go into a component effect-controls

<a-entity effect-controls="hand: right">

You can set inside:

this.el.setAttribute('meta-touch-controls', {hand: this.data.hand}); this.el.setAttribute('hand-tracking-controls', {hand: this.data.hand});

You don't need to treat each button separately. Can only listen to buttondown and pinchstarted

dmarcos · 2025-02-14T18:08:14Z

Almost done:

There's a conflict in examples/index.html from last merges
Encapsulate toggle logic into a component.

Thanks so much for sticking with it

enzofrancescaHM added 3 commits January 30, 2025 09:32

Create base html file for post-processing bloom example

9094de9

Create bloom.js for post-process bloom example

19f78b4

Update index.html changing path

868863a

enzofrancescaHM added 2 commits January 30, 2025 16:56

Update index.html to use importmap

22ad7d0

Update bloom.js to use importmap

fbd5cef

mrxz reviewed Jan 30, 2025

View reviewed changes

examples/post-process/index.html Outdated Show resolved Hide resolved

mrxz reviewed Jan 30, 2025

View reviewed changes

examples/post-process/index.html Outdated Show resolved Hide resolved

mrxz reviewed Jan 30, 2025

View reviewed changes

examples/post-process/bloom.js Outdated Show resolved Hide resolved

mrxz reviewed Jan 30, 2025

View reviewed changes

examples/post-process/bloom.js Outdated Show resolved Hide resolved

enzofrancescaHM and others added 4 commits January 30, 2025 18:46

Update examples/post-process/index.html

d6b9d96

Typo Co-authored-by: Noeri Huisman <[email protected]>

Update examples/post-process/bloom.js

d86dd9f

deleted useless tick function Co-authored-by: Noeri Huisman <[email protected]>

Update bloom.js to discard useless wait

2b409aa

Update index.html to set bloom directly on a-scene tag

5617d2f

mrxz reviewed Jan 31, 2025

View reviewed changes

examples/post-process/bloom.js Outdated Show resolved Hide resolved

mrxz reviewed Jan 31, 2025

View reviewed changes

examples/post-process/bloom.js Outdated Show resolved Hide resolved

mrxz reviewed Jan 31, 2025

View reviewed changes

examples/post-process/bloom.js Outdated Show resolved Hide resolved

mrxz reviewed Jan 31, 2025

View reviewed changes

examples/post-process/bloom.js Outdated Show resolved Hide resolved

mrxz reviewed Jan 31, 2025

View reviewed changes

examples/post-process/bloom.js Outdated Show resolved Hide resolved

mrxz reviewed Jan 31, 2025

View reviewed changes

vincentfretin reviewed Jan 31, 2025

View reviewed changes

Added info panel, changed model

c0d4dd6

dmarcos reviewed Feb 13, 2025

View reviewed changes

examples/showcase/post-processing/message.html Outdated Show resolved Hide resolved

dmarcos reviewed Feb 13, 2025

View reviewed changes

examples/showcase/post-processing/index.html Show resolved Hide resolved

enzofrancescaHM added 3 commits February 14, 2025 08:44

Update message.html to remove useless statement

f524e11

Update index.html to add toggle bloom in VR

81c5f65

Update message.html to add toggle instructions

d9cbda8

vincentfretin mentioned this pull request Feb 14, 2025

how to use EffectComposer/UnrealBloomPass in Aframe #4897

Closed

dmarcos reviewed Feb 14, 2025

View reviewed changes

Post-Process example #5648

Are you sure you want to change the base?

Post-Process example #5648

Conversation

enzofrancescaHM commented Jan 30, 2025

vincentfretin commented Jan 30, 2025

enzofrancescaHM commented Jan 30, 2025

vincentfretin commented Jan 30, 2025

vincentfretin commented Jan 30, 2025

dmarcos commented Jan 30, 2025

enzofrancescaHM commented Jan 30, 2025

dmarcos commented Jan 31, 2025

mrxz Jan 31, 2025

Choose a reason for hiding this comment

mrxz Jan 31, 2025

Choose a reason for hiding this comment

mrxz Jan 31, 2025

Choose a reason for hiding this comment

vincentfretin Jan 31, 2025

Choose a reason for hiding this comment

vincentfretin Jan 31, 2025

Choose a reason for hiding this comment

enzofrancescaHM commented Feb 5, 2025

dmarcos commented Feb 5, 2025

enzofrancescaHM commented Feb 5, 2025

mrxz commented Feb 5, 2025 • edited Loading

enzofrancescaHM commented Feb 5, 2025

dmarcos commented Feb 5, 2025

mrxz commented Feb 6, 2025

dmarcos commented Feb 6, 2025

enzofrancescaHM commented Feb 6, 2025

cabanier commented Feb 6, 2025

mrxz commented Feb 6, 2025 • edited Loading

cabanier commented Feb 6, 2025

mrxz commented Feb 6, 2025 • edited Loading

cabanier commented Feb 6, 2025

mrxz commented Feb 7, 2025

dmarcos commented Feb 10, 2025

enzofrancescaHM commented Feb 11, 2025

dmarcos commented Feb 11, 2025

enzofrancescaHM commented Feb 11, 2025

dmarcos commented Feb 11, 2025

enzofrancescaHM commented Feb 12, 2025

dmarcos Feb 14, 2025 • edited Loading

Choose a reason for hiding this comment

dmarcos commented Feb 14, 2025

mrxz commented Feb 5, 2025 •

edited

Loading

mrxz commented Feb 6, 2025 •

edited

Loading

mrxz commented Feb 6, 2025 •

edited

Loading

dmarcos Feb 14, 2025 •

edited

Loading