Postprocessing: FXAA

[stevesch]

Does the postprocessing module support an equivalent to the FXAA pass in the three.js example code?

[vanruesc]

Hi,

the FXAA technique is not included in the postprocessing library. Only SMAA is currently included to have one go-to antialiasing pass.

The reason for that is because SMAA appears to be better than FXAA, TAA and SSAA. It's less blurry and faster. That said, once there's something better than SMAA, it will be replaced.

[vanruesc]

Closing due to inactivity.

[stevesch]

Thanks

[marcofugaro]

I am using FXAA because SMAAImageLoader takes ~1s to generate the lookup tables.

@vanruesc have you looked into a way of baking the base64 string of the images or do the lookup tables need to be generated each time on runtime?

[vanruesc]

@marcofugaro The SMAAImageLoader caches the generated image data using localStorage and should resolve immediately after the first run. The data images were originally being loaded from static base64 strings, but this approach has been deprecated because it inflates the size of the library; the base64 data takes up 65kb while the script only takes up 8kb.

If you're in desperate need for speed on the first page load, you can load the images manually as plain images (search and area) or as base64 data strings (search and area):

const searchImage = new Image();
const areaImage = new Image();

// Images always load asynchronously.
searchImage.addEventListener("load", handleProgress);
areaImage.addEventListener("load", handleProgress);

searchImage.src = searchImageDataURL;
areaImage.src = areaImageDataURL;

[marcofugaro]

@vanruesc the first run is actually the most important one. Most users usually open my projects only one time.

I would 100% trade a slightly bigger bundle size for the computing time it takes to generate them. 65kb take much less time to download over the internet than what it takes to generate them.

I am on a Macbook Pro and it takes over 1 second to generate them the first time.
The subsequent times it takes ~about 600ms somehow (maybe reading from localStorage)~ 20ms actually, I was starting the render loop before it was finished.

Again, I appreciate that the API makes it possible to handle the images by yourself, I'll use the base64 strings you provided, but I just think it would be easier for users to use SMAA without the usage of the SMAALoader and async code.

[vanruesc]

but I just think it would be easier for users to use SMAA without the usage of the SMAALoader and async code.

Unfortunately, it is not possible to load images synchronously. The purpose of the SMAAImageLoader is to make the asynchronous loading process as easy as possible.

I would 100% trade a slightly bigger bundle size for the computing time it takes to generate them. 65kb take much less time to download over the internet than what it takes to generate them.

I see, thanks for the feedback! I've tried to optimize the generation script but only managed to speed it up by ~30%. It still takes roughly 1700ms in Firefox and 1200ms in Chrome on my system. I like the procedural approach, but it's probably better to switch back to static base64 strings since they are already part of the library anyway. I'll adjust the SMAAImageLoader for the next release.

[marcofugaro]

Glad to be useful!

Unfortunately, it is not possible to load images synchronously.

Right, what about doing it in the TexureLoader approach? With the url in base64 the loading should be instantaneous, just like doing setTimeout(() => {}, 0).

But I don't know the internals of the postprocessing enough to know if that's possible.

[vanruesc]

With the url in base64 the loading should be instantaneous

It's fast but not instantaneous because the base64 strings are compressed PNG images that need to be decompressed.

what about doing it in the TexureLoader approach?

That approach is also asynchronous and you still have to wait for that loader to finish before the textures can actually be used. Three's documentation explains that the returned texture may be used immediately, but it will only appear once it's fully loaded. I believe that this functionality only exists for backwards compatibility reasons. In my opinion, the correct way is to load assets first and then start rendering. This would be impossible to do consistently if the loading process of the search and area images was hidden from the user.

[marcofugaro]

In my opinion, the correct way is to load assets first and then start rendering. This would be impossible to do consistently if the loading process of the search and area images was hidden from the user.

Alright, makes sense.

[arpu]

what is about Basis compressed image Textures for this?

[vanruesc]

@arpu The basis universal format is used to compress textures as much as possible. It requires a huge large transcoder (1mb 430kb) and only makes sense if you have lots of large textures. Small base64 strings are much faster to load. But the point is that even instantaneous loading would still be asynchronous.