Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 1 more developer from Canada and 12 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 29 Apr 2002
Offline Last Active Yesterday, 03:27 PM

Topics I've Started

SMAA GLSL conversion

08 June 2015 - 03:47 PM



Has anyone had any luck getting this running under OpenGL. Ive followed the notes they give for integrating it, Im testing it on the reference image (one of), I got the first edge detection pass to produce the exact result, but Im yet to get the second pass, the blend weights pass, to produce the correct result.

Oddly enough searching "SMAA GLSL" produces 2 results, one which claims GLSL as been fixed, and the other where two individuals seem to have given up trying to get it into their dx code (no idea if they ever did).


The blend weight pass uses two precomputed Area and Search textures


Scene -> EdgeDetect -> [AreaTex, SearchTex->] BlendWeights -> NeighborBlend -> "SMAA scene"


Possible points of failure

- Area and Search are used as *.dds files in the working demo, I converted them using nv photoshop plugin to *.tga

(Ive tried every configuration of these textures)


- Ive tried flipping the Area and Search textures vertically to not break the HLSL assumed convention

(didnt work)


- There is a scripts folder containing two python scripts which generate the Area and Search textures directly as *.tga, I tried these with my second rewrite of the optimized version, I get more colorful results but still something wrong


- The scripts in the latest optimized version available seem to produce different Area and Search textures then the original (older) *.dds files from the demo


- There is a DX 9 demo with a DX9 Search texture, im using the DX10 version of the texture (sampled as .rg)

(im sampling as .rg, have been from start, Im using the red and green texture)


- the checkered pixel offset patterns im noticing (front of the ship, green line meeting red line in the demo scene) looks like a potential offset problem (maybe vert, maybe horz, maybe both)

I rewrote it in pure GLSL, gone over it countless times, Im certain they are equal (the edge pass works so Im on the right track).


- Ive also tried changing the way the source images are sampled, point (nearest) vs bilinear (linear) for all the images

(no real impact)


Demo Ref Scene captures

Attached File  Unigine02.png   1.19MB   0 downloadsAttached File  _SMAA_RefScene_EdgePass.png   510.24KB   0 downloadsAttached File  _SMAA_RefScene_BlendPass.png   486.1KB   0 downloads


Blend Weight result I got converting the original unoptimized code using the *.dds converted Area and Search

Attached File  _SMAA_OriginalDX10_BlendResult.png   316.87KB   0 downloads


Blend Weight result I got converting the newer optimized code using python script generated Area and Search *.tga

Attached File  _SMAA_OptimizedDX10_BlendResult.png   615.97KB   0 downloads


Some how I pulled an older version of the code directly off the site (think I clicked the "Direct Links" 2.8 post) and got the unoptimized version dated 2011, I converted it, which resulted in the first blend weights image (4 image above).

Later after that failed, I found the optimized version of the code on github that used an HLSL file claiming to be GLSL compatible, dated 2013, converted it, which resulted in the second blend weights.


Im doing this conversion under GL3.3, I can post the shader code I rewrote but this post is getting long, but as I said, I rewrote it twice, went over each countless times, and its failing in a similar way each time, Im thinking its the precomputed textures or some small offset Im screwing up. The problem feels external, just wondering if anyone has had any luck with this.

Mantle programming guide and white paper released

18 March 2015 - 08:48 PM




From whats being said about the new apis coming, this should give an early look at whats to come

Vulkan is Next-Gen OpenGL

03 March 2015 - 03:20 AM





Handling Tall Shadow Casters Culled By View Volume

19 December 2014 - 03:47 AM

I have some tall objects, with a sort of third person camera that looks down toward the ground. When tall nearby objects are culled by the camera, their shadows pop out of the scene.

I thought about extending the objects bounds based on the direction of the light and the angle, a sort of 'bound the shadow' idea, but it would blow up if the light source (sun) went down and became parallel with the ground, the bound would extend across the map. It could work but has edge cases.

Specifically for out door directional light sources, any suggestions for handling this situation? Inflate the view volume? A second view volume for culling 'tall' objects?

Post process order?

22 July 2014 - 08:35 PM

Wondering what people think, or what you do yourself and why, stick any I may have missed in.


Screen space reflections - havent done them, not sure where, close to start?...
Eye Adaptation - builds info probably done early?
Lens flare - get it in before bloom?

Bloom - before dof ??
DOF - you want the bloom 'under' it?

FXAA - you want to AA toward then end right?

Color Correction - want final color, before correcting...

Tone Mapping - fit for ldr

Gamma Correction - correct for screen output

Vignette - because its just black on top of everything else...