When it comes to rendering engines, we have to mention delayed rendering. Basically, an engine is not a good rendering engine if it does not implement delayed rendering, but unfortunately, three.js does not implement delayed rendering (ps: call for MRT implementation). Since there is no MRT and delayed rendering, we were not going to write post-processing, but even if there is no post-processing, we hope to achieve some cool effects, so let’s make a simple modification of Three.js to achieve a high performance post-processing renderer.

To implement post-processing we first need to consider the requirements, whether we need to accommodate mobile, whether we need to accommodate large screens (4K), whether we need to support WebGL1, whether we need to have a decent performance in all kinds of graphics cards. At present, my main consideration is: good performance, can accommodate large screen, do not plan to support WebGL1 perfectly, use webGL2 features as much as possible. All subsequent performance tests are to N card as performance test indicators, regardless of AMD card (AMD anti-aliasing processing performance will be higher, but dynamic processing performance will be low, there are a lot of details) well, we care about the good performance, as much as possible to use webGL2 features, To complete a post-processing renderer, we first need to consider anti-aliasing. Commonly used techniques include oversampling and multi-sampling, as described in this sectionAdding a Link DescriptionThree. Js has implemented SSAA, SMAA and TAA, three kinds of hypersampling technology, and the effect is not bad. There are specific examples of three. SSAA has the best anti-aliasing effect, but the worst performance and is completely unusable in real life. SMAA performance is better, 2000 objects lose about 15 frames (SMAA is a bit more complicated than FXAA calculation, SMAA has less research, I don’t know if it can solve the sawtooth problem of line, if you know, please leave a comment). SMAA is generally acceptable, but 2000 objects is still a bit too much frame rate and is not our first choice. TAA works very well and is a good choice if there is very little moving in the scene. If there are moving objects, animations, etc., basically anti-aliasing will not work. In theory it should be possible to achieve dynamic TAA, but it is difficult to achieve with current technology. Therefore, TAA is not considered to include our post-processing renderer (TAA cannot be used in real use scenarios where animation or texturing flow effects are common). SMAA: Good effect, cost around 15 frames (2000 objects)SSAA: the best effect, too much overhead (2000 objects basically have no frame rate)

TAA: The effect is similar to SSAA, but currently only works when stationary

As for multi-sample MSAA, this feature must use WebGL2, which is provided by WebGL. It works just as well as the anti-aliasing principle of the browser itself. It is no different from normal rendering results, and the performance cost is not too high, provided that we do not use StencilBuffer. In addition, there are some minor issues with the release of the three.js MSAA block, which can be modified in the deallocateRenderTarget interface. Now we can use MSAA as the primary anti-aliasing technology. MSAA although the performance overhead is not large, but the only disadvantage is that the comparison eats video memory, if it is a large screen, and the graphics card is not good, or easy to collapse, can not be opened. Therefore, we should continue to choose a low cost anti-aliasing that does not eat video memory (of course, we can also consider SMAA, currently due to the high frame rate overhead (2000 objects lost about 15 frames), we do not consider adding SMAA). MSAA: basically no frame rate overhead, good effect, but consumes video memory (2000 objects).The final alternative is FXAA, which can refer to this article:Adding a Link DescriptionIn detail, FXAA’s performance overhead is very small, but the effect is very general, especially the thin line sawtooth can not be solved, the camera edge flash effect can not be solved, and there is another problem because FXAA relies on edge blur anti-sawtooth, so the picture will inevitably be slightly blurred. But its biggest benefits are that it costs little and consumes no video memory, and is easiest to integrate into post-processing renderers. But it can be a good choice when the video memory is low and the graphics card is bad. Hence the need to join FXAA. FXAA: General effect, low overhead, no way to fix jagged lines, resulting in blur (2000 objects)We looked at the engines, and almost every engine implemented FXAA, and many implemented FXAA3. FXAA3 works better, but still doesn’t solve the wiring problem. Cesium’s anti-aliasing strategy is completely FXAA3, which is acceptable, so for now we are using Cesium’s FXAA3_11. Finally, we choose to use MSAA plus FXAA3_11 anti-aliasing strategy (of course SMAA and TAA are also optional). To be continued, questions are welcome.