There is probably another nicer way to fix this, but when implementing this algorithm in GL in my engine it wasn't working correctly. It seemed that adjusting for the fact that +V is up in GL vs. +V is down in DX could fix the issue. Doing A/B comparisons with the sample app and my GL app along the way, it did indeed fix the issue. Maybe flipping the Area/Search textures and flipping my inputs could also fix it, but doing it this way keeps all the inputs and outputs consistent with the existing engine code.

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.

Luckily it was only a few lines thanks to your defines !

Note that despite my commit message, I have tested it now. It compiles on OpenGL using profiles arbfp/arbvp1 and up.

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?

In SMAAColorEdgeDetectionPS(), the calculations of left-left and top-top deltas are performed as:

    t = abs(C - Cleftleft);

and

    t = abs(C - Ctoptop);

However, these are not differences of neighboring pixels, so should be modified as follows:

    t = abs(Cleft - Cleftleft);

and

    t = abs(Ctop - Ctoptop);

Thanks!

This adds support for OpenGL ES 2 and WebGL 1 via SMAA_GLSL_ES2 as well as support for OpenGL 2 via SMAA_GLSL_2 (only tested via OpenGL ES - the difference here is that support for while loops is not required in ES 2 and is disallowed by WebGL). The output is incorrect when using medium-precision float in the fragment shader, so highp should be used.

Allows building the demos with mingw. Supports both 32- and 64-bit versions. By default it's set up to cross-compile on Linux but should also work if building natively on Windows.

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: https://github.com/pushrax/smaa/commit/cd8f88cd1548a2966eb1c4bfe0677427fa885140

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

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.