Postprocessing: Question: What are SMAA search and area images?

[smoes]

In your demo with SMAA you pass both these images to the SMAAPass. What are they for? I'm a little puzzled. I have no textures in my render scene. Documentation does not explain that properly. Why are these two images needed, what are they, and how can I generate them?

(I need fast and reliable anti-aliasing since chrome-antialiasing fails on some devices)

[vanruesc]

Hi Simon!

Why are these two images needed, what are they?

The SMAAPass uses these two data images as look-up-tables to detect aliasing artifacts. There is a link to the original SMAA project in the SMAA documentation where you can find this excerpt from the project's readme: _"The technique focuses on handling each pattern in a very specific way (via look-up-tables), in order to minimize false positives in the pattern detection. Ultimately, this prevents antialiasing features that are not produced by jaggies, like texture details"_.

It's worth noting that the SMAA implementation from the three.js examples hides the loading process of these images from the user and tries to load them synchronously, which introduces race conditions. It was decided in #62 that the postprocessing library should let the user load these images asynchronously and then provide the loaded images in the SMAAPass constructor.

How can I generate them?

No need to generate anything! The base64-encoded, PNG-compressed images are exposed to the user as SMAAPass.areaImageDataURL and SMAAPass.searchImageDataURL. There's an instruction and an example on how to load the images for both fields: _"Use this image data to create an Image instance and use it together with the area/search image to create an SMAAPass."_

const areaImage = new Image();
areaImage.addEventListener("load", progress);
areaImage.src = SMAAPass.areaImageDataURL;

const searchImage = new Image();
searchImage.addEventListener("load", progress);
searchImage.src = SMAAPass.searchImageDataURL;

Documentation does not explain that properly.

I'd say the explanation is sufficient. The documentation of the SMAAPass constructor parameters states: _"Preload this image using the areaImageDataURL/searchImageDataURL"_ and it links to the documentation of the respective static image data fields.

That being said, I'm open to suggestions on how the documentation could be improved 😇

[smoes]

Thanks for the very comprehensive and really fast answers, I really appreciate it.

That explains a lot and I overlooked the link to the doc. Maybe I was a bit irritated since there are a lot of outdated examples out there, working differently (I saw other AA-passes disappeared entirely?).

May I ask why I have to create these images explicitly in the first place? I would assume them to be optional (to leave the possibility of passing something special), since they are kind of (empty or predefined) buffers right? I think there was a point of confusion: I thought I have to provide any form of specific data.

Anyways, keep up the great work, awesome contribution!

[vanruesc]

I saw other AA-passes disappeared entirely?

There's not a lot of benefit in maintaining multiple passes that do the same thing. As far as I know, the SMAA algorithm generally performs better than the alternative approaches, hence it's the only one included in this library.

I would assume [the images] to be optional, since they are kind of empty or predefined buffers right?

The SMAA shaders need exactly these two provided data images. Otherwise they won't work. It's common practice to use textures as fixed data arrays inside of shaders. The SMAAPass could theoretically generate the images in its constructor, similar to how the GlitchPass generates a default noise texture. However, generating these images procedurally takes way too much time. Therefore, the pre-generated images are provided as plain strings that can be loaded quickly.

If you want to know what the area/search data looks like, you can find the actual area image here and the search image here.

May I ask why I have to create these images explicitly in the first place?

The area and search images are stored as base64-encoded, PNG-compressed strings to minimize their impact on the size of your final product. The best way to load them is by using the native Image class. Loading images is always asynchronous, even if the src property is set to a base64 data string. Since the process is asynchronous it's best to leave the loading to the user so that he/she has full control over it.

I hope that helps clear things up 😄

[smoes]

Yes it does. Thank you for the input, I've learned a lot today :+1:

[vanruesc]

Glad I could help!

[vin-ni]

so can I just do this?

  const areaImage = new Image();
  areaImage.addEventListener("load", progress);
  areaImage.src = PP.SMAAEffect.areaImageDataURL;

  const searchImage = new Image();
  searchImage.addEventListener("load", progress);
  searchImage.src = PP.SMAAEffect.searchImageDataURL;


  const smaaEffect = new PP.SMAAEffect(searchImage, areaImage);

[vanruesc]

Not quite; you should wait for the images to be ready. Otherwise, you'll probably see "RENDER WARNING: texture bound to texture unit X is not renderable" in the console during your first few frames.

You can find an example of how the images should be loaded in the wiki.