All the links to SMAA for compiling in unreal are all dead?

http://www.iryoku.com/smaa/ can no longer be reached, although there are copies on the Wayback Machine (such as this one from November 2020).

When defining SMAA_DECODE_VELOCITY to point towards a function that takes a float4 vector an error is generated at line 1323 because the input will be a float2 from swizzling the rg components of the texture sampling, whereas in the other three cases there is no swizzling so a float4 is passed.

Hi there,

i am integrating this great SMAA in my own OpenGL test framework. I am a bit confused if i handle correctly the lookup textures.

First i had to apply this patch to get the edge detection itself working:
pushrax@cd8f88c

Also i noticed that OpenGL and DirectX have different coordinate system locations in terms of uv-coordinates. So i inverted the Y-axes of the fullscreen triangle texture coordinates to get a buttom up rendering. But then my confusion starts. I use bmp files dumped by the provided python scripts. After reading them in i mirror them, so the Y-coordinate is flipped. After that step i get reasonable results but still different ones compared to the DX10 demo.

So i have no idea what causes the differences in my edge, weight and result pass. I adjusted the images to fit the lower left corner. So direkt comparison should work.

The edges seems to be shifted a little bit, but only some of them.

The weights seem to have flipped red and green parts as well as different intensity. This is the point where i am mostly confused. Is this flipping of red and green parts a result of failed usage of the lookup textures or is it a result of the very small differences from the first pass?

The reults itself looks reasonable and quite good, but on some parts still different. Everything seems thicker in the OpenGL results. Good visable at the wire for example.

So it seems to be related to my questions asked at the old opengl port project:
https://github.com/scrawl/smaa-opengl/issues/3

I tried to compile the last SMAA.hlsl with the following:

define SMAA_GLSL_3 1

define SMAA_PRESET_MEDIUM 1

define SMAA_PREDICATION 1

My (Nvidia Geforce GT430) GLSL compiler complains:

0(614) : error C7011: implicit cast from "float" to "bool"
0(615) : error C7011: implicit cast from "float" to "bool"
0(1269) : error C1115: unable to find compatible overloaded function "SMAAMovc(bool, vec4, vec4)"
0(1270) : error C1115: unable to find compatible overloaded function "SMAAMovc(bool, vec2, vec2)"
0(1271) : error C7011: implicit cast from "float" to "vec2"

EDIT: corrected line number, basically are simple cast errors

these error are easily fixable:
614 : SMAA_FLATTEN if (bool(cond.x)) variable.x = value.x;
615 : SMAA_FLATTEN if (bool(cond.y)) variable.y = value.y;
1269: SMAAMovc(vec4(horizontal), blendingOffset, float4(a.x, 0.0, a.z, 0.0));
1270: SMAAMovc(vec2(horizontal), blendingWeight, a.xz);
1271: blendingWeight /= dot(blendingWeight, vec2(1.0));

EDIT2: there are many more cast errors if compiled in ULTRA or HIGH (const float to vec2), but once fixed i get a very strange link error:

(0) : fatal error C9999: *** exception during compilation ***

This error popup only in ULTRA or HIGH mode, I don't know I can possibly fix this.

I am trying to integrate SMAA into my little engine, and I just finished integrating the edge detection part. The red/green edge texture is also generated. But it's hard for me to check whether I am integrating correctly since quite a lot of people reported the problems they met in #8 and #5. I don't see a final conclusion in these issues such as "DO flip the area/search texture" or "DO NOT use this PR #5". This makes me quite confused.

So I am wondering if you could give some final suggestions for the flipping issue.

Besides, it seems that https://github.com/RobertBeckebans/RBDOOM-3-BFG provides a correct GLSL implementation and it got a lot of stars. I am going to refer to his code for a comparison.

Dear All,

I've integrated the SMAA S2X and 4X modes for OpenGL. Getting the integration going was relatively easy (just follow the integration notes in SMAA.hlsl) and don't forget to add some missing defines to SMAA.hlsl in the #if defined(SMAA_GLSL_3) || defined(SMAA_GLSL_4) section:

#define SMAATexture2DMS2(tex) sampler2DMS tex
#define SMAALoad(tex, pos, sample) texelFetch(tex, pos, sample)

Once I got it running, the 4X mode didn't look as good as expected compared to T2X - some edges look better, but others look worse. I think the reason for this is the difference in MSAA2x subsample positions between DirectX and OpenGL.

The integration notes in SMAA.hlsl call for the scene to be rendered with D3D10_STANDARD_MULTISAMPLE_PATTERN for SMAA 4X. This allows the subsamples to match the order in the @SUBSAMPLE_INDICES table. When the scene is rendered this way, you have the following subsample positions in DirectX:

       * Sample positions DirectX:
       *   _______
       *  | S1    |  S0:  0.25    -0.25
       *  |       |  S1: -0.25     0.25
       *  |____S0_|
       *

On the other hand, for MSAA2X in OpenGL you get the following subsample positions (positions adjusted for pixel centre that is reported at (0.5,0.5) - see below):

        * Sample positions OpenGL:
        *   _______
        *  |    S0 |  S0:  0.25     0.25
        *  |       |  S1: -0.25    -0.25
        *  |_S1____|
        *

I've been puzzling on how to adjust the subsampleIndices to make SMAA 4X work in OpenGL. Does anyone have some insight here ? In the DX10 demo it is mentioned that the indices have the following layout : Indices layout: indices[4] = { |, --, /, \ }. How should that be interpreted ?

I suspect I also need to adjust the camera jitter, since with the recommended jitter of (0.125, 0.125) and (-0.125, -0.125) for SMAA4X I would end up with a net jitter in OpenGL of:

           *   ________
           *  |      S0|  S0:  0.3750    0.3750
           *  |    S2  |  S1: -0.1250   -0.1250
           *  |  S1    |  S2:  0.1250    0.1250
           *  |S3______|  S3: -0.3750   -0.3750
           *

As a test, I modified the camera jitter offset to use the original, unadjusted subsample positions of MSAA2X instead: (0.75, 0.75) and (0.25, 0.25) (obtained with glGetMultisamplefv, (0.5, 0.5) is the pixel centre). That improved things quite a bit, but I can't help but think I'm still missing something?