MLAA (Morphological Anti-Aliasing)

Posted By: rojart

MLAA (Morphological Anti-Aliasing) - 10/28/10 13:54

It would be great to added the new MLAA technique in the future.

Quote:
In short, MLAA is a shape-based anti-aliasing method that uses post processing filters to reduce aliasing. Like the SSAO, MLAA can be hand-coded in a 3D app or added in graphics drivers.

Quote:
What are the advantages of MLAA over MSAA?

* For similar quality, it is considerably faster, one order of magnitude in the PC case.
* For consoles, where the MSAA sample count is limited due to hardware restrictions, it allows better quality.
* It enables the usage of anti-aliasing in conjunction with Multiple Render Targets, which is specially useful for deferred engines.
* It can provide better quality when HDR is used, as anti-aliasing is performed after tone mapping.
* Anti-aliasing quality can be dynamically adjusted on the fly, depending on the available resources at each frame.
* MLAA is not incompatible with MSAA: this leads to hybrid MSAA-MLAA approaches.


Here is the MLAA in action:

[video:youtube]http://www.youtube.com/watch?v=Z8UG7g8NRcw[/video]



Some helpful links:
http://www.realtimerendering.com/blog/morphological-antialiasing/
http://www.iryokufx.com/mlaa/index.html
Posted By: Hummel

Re: MLAA (Morphological Anti-Aliasing) - 10/28/10 15:13

thx for the hint, was looking for something like this wink
Posted By: Toast

Re: MLAA (Morphological Anti-Aliasing) - 10/28/10 15:22

Well it's going to be a graphics cards provided feature anyway (at least I don't think NVIDIA will allow AMD as the only one with this feature). I also wouldn't hype this too much. The visual quality really differs from game to game and it's nothing more than a blur shader with some minor intelligence. First tests also showed that it's not as free in terms of performance as it got advertised recently...
Posted By: Hummel

Re: MLAA (Morphological Anti-Aliasing) - 10/28/10 16:15

Quote:
Well it's going to be a graphics cards provided feature anyway

It´s simply a pp-effect, the type(nVidia/AMD/whateva) of graphics card running on is irrelevant.
Posted By: Joey

Re: MLAA (Morphological Anti-Aliasing) - 10/28/10 18:22

That's interesting. I'll try to implement that.
Posted By: Joozey

Re: MLAA (Morphological Anti-Aliasing) - 10/28/10 20:56

The different is not exactly noticeable... especially in the video.
Posted By: Quad

Re: MLAA (Morphological Anti-Aliasing) - 10/28/10 21:17

it's not as good as MSAA but if it's 11x faster as they said... why not.
Posted By: Toast

Re: MLAA (Morphological Anti-Aliasing) - 10/28/10 21:31

Originally Posted By: Hummel
It´s simply a pp-effect, the type(nVidia/AMD/whateva) of graphics card running on is irrelevant.

Sure but checking if there's a simple way to tell the graphic card's driver to add it in would be less work than rewriting it all over again. I mean in my opinion it's not like 3DGS should give its dev time away so easily when there might be such a solution...
Posted By: jcl

Re: MLAA (Morphological Anti-Aliasing) - 10/29/10 13:38

A post processing antialiasing filter is interesting because DirectX antialising does not work together with postprocessing. All the better when users are already implementing it.
Posted By: painkiller

Re: MLAA (Morphological Anti-Aliasing) - 10/29/10 18:00

for using also PP shaders you can use the FSAA plugin in resources
Posted By: Hummel

Re: MLAA (Morphological Anti-Aliasing) - 10/29/10 18:12

Quote:
The different is not exactly noticeable... especially in the video.
of course not, since the vid itself is already in a downscaled format.

Quote:
for using also PP shaders you can use the FSAA plugin in resources
which can be really slow for longer pp-chains.

Quote:
That's interesting. I'll try to implement that.
let us know when it succeeds wink
Posted By: HeelX

Re: MLAA (Morphological Anti-Aliasing) - 10/29/10 19:33

That is funny :-) if I remember the specs right, the N64 had a hardwired antialiasing processing included, because in that era the output was smaller than TV resolution (either PAL or NTSC). They compared the dark-/brightness distribution in the direct neighbourhood around each pixel - and smeared then the pixel along the most prominent staircase-line.

Go for it!
Posted By: rojart

MLAA on the GPU using Direct3D9 (DEMO) - 10/31/10 01:19

Originally Posted By: Joey
That's interesting. I'll try to implement that.

I Would be very happy to see it in action into A8. smile

I found a demo with sourcecode, some of them might be of interest to you.

Links to other sites of interest:
http://www.vizerie3d.net/
http://igm.univ-mlv.fr/~biri/mlaa-gpu/index.php
http://www.gamedev.net/community/forums/topic.asp?topic_id=580517
http://www.adobe.com/cfusion/exchange/index.cfm?event=extensionDetail&extid=2230024



Thank you (maybe) all, for the positive reaction!


Posted By: Nowherebrain

Re: MLAA on the GPU using Direct3D9 (DEMO) - 10/31/10 06:12

@heelX, and somewhat off topic....I was honestly going to bring up that exact point, as I thought I was one of the only people out there who drooled over the old N64 tech....at the time it was really very advanced, using mip maps, anti aliasing etc....it was interesting to see you brought that up....kinda made my day...thanks.
Posted By: Joey

Re: MLAA on the GPU using Direct3D9 (DEMO) - 12/05/10 10:39

Okay, in principle I was finished two weeks ago but I'm incredibly busy these weeks. Here is what I got so far:

45°-angles seem to be smoothed quite well.

high contrast edges are smoothed better than low contrast ones; also, non-45° edges are somewhat ragged. also note the weird artifacts.

again, weird artifacts, but it does look smoother.

The good news is, it works! It is extremely cheap on resources (render time some miliseconds on a GF 8600m GT) and independent of scene complexity.
I have to work on the artifacts, though, and I'm still curious on other implementations. It all depends on the edge detection algorithm you use, propagation and composition is quite straightforward.

Joey.
Posted By: rojart

Re: MLAA on the GPU using Direct3D9 (DEMO) - 12/05/10 11:28

Hi Joey!
Awesome news and the screens looks very impressive for me, any chance to see it in action dynamically?
I'll pm you about edge detection algorithms that I found on the web, but You've reached the limit of your Private Topics.
Posted By: Joey

Re: MLAA on the GPU using Direct3D9 (DEMO) - 12/05/10 11:52

Hey rojart,

thanks for your comment. I emptied my inbox. What I'm really interested in is this approach:
http://www.iryokufx.com/mlaa/
the results are way better than mine. But I find no technical paper describing their technique.
You'll get a demo of it when it's working properly.

Joey.

edit: the shaders are in GLSL, so you'd have to convert them anyway.
Posted By: HeelX

Re: MLAA on the GPU using Direct3D9 (DEMO) - 12/05/10 13:11

Originally Posted By: Joey
But I find no technical paper describing their technique.


That is maybe because it will appear in the "GPU Pro 2" book which is apparently not on sale yet.
Posted By: Joey

Re: MLAA on the GPU using Direct3D9 (DEMO) - 12/05/10 13:32

Ah, good to know. Well, if the book contains more than only that I'll buy it; GPU Gems 3 was a good investment, too. Does "GPU Pro" has to do something with the ShaderX-series?
Posted By: HeelX

Re: MLAA on the GPU using Direct3D9 (DEMO) - 12/05/10 15:18

Afaik, it is a different series at a different publishing company, but with Engel as author/coauthor/whatever. It seems his name is like a golden seal to a shader programming book wink Both books cover obviously the same field (GPU programming), but don't relate to each other. I'm afraid, the "first" GPU Pro Book didn't received well recommendations on Amazon, anyone here owning that book?
Posted By: Hummel

Re: MLAA on the GPU using Direct3D9 (DEMO) - 12/05/10 20:14

me - it´s as awesome as the ShaderX stuff and actually GPU Pro is the successor series to SX.
Posted By: rojart

Re: MLAA on the GPU using Direct3D9 (DEMO) - 12/07/10 22:57

Originally Posted By: HeelX
I'm afraid, the "first" GPU Pro Book didn't received well recommendations on Amazon, anyone here owning that book?

Also, I do not have this book, but you can check each of the GPU Pro examples and source code here.
And the GPU Pro 2 should be released in mid-March next year.

Originally Posted By: Joey
What I'm really interested in is this approach:
http://www.iryokufx.com/mlaa/

Hmm, strange that the Website is down, but this publication may it be useful to you.

Some new MLAA examples can be found here.

EDIT: The Site Works Again!
Posted By: rojart

Re: MLAA on the GPU using Direct3D9 (DEMO) - 01/30/11 20:16

Quote:
Do you remember the MLAA (Morphological Anti-Aliasing)? In short, MLAA is a shape-based anti-aliasing method that uses post processing filters to reduce aliasing. Like the SSAO, MLAA can be hand-coded in a 3D app or added in graphics drivers.

During the next I3D 2011, NVIDIA will talk about Subpixel Reconstruction Anti-Aliasing or SRAA, a potential competitor of AMD’s MLAA:

Subpixel Reconstruction Antialiasing (SRAA) combines single-pixel (1x) shading with subpixel visibility to create antialiased images without increasing the shading cost. SRAA targets deferred-shading renderers, which cannot use multisample antialiasing. SRAA operates as a post-process on a rendered image with superresolution depth and normal buffers, so it can be incorporated into an existing renderer without modifying the shaders. In this way SRAA resembles Morphological Antialiasing (MLAA), but the new algorithm can better respect geometric boundaries and has fixed runtime independent of scene and image complexity. SRAA benefits shading-bound applications. For example, our implementation evaluates SRAA in 1.8 ms (1280×720) to yield antialiasing quality comparable to 4-16x shading. Thus SRAA would produce a net speedup over supersampling for applications that spend 1 ms or more on shading; for comparison, most modern games spend 5-10 ms shading. We also describe simplifications that increase performance by reducing quality.


Offical page @ NVIDIA: Subpixel Reconstruction Antialiasing.

http://www.geeks3d.com/20110129/sraa-sub...y-to-amds-mlaa/
http://berc.yonsei.ac.kr/files/journal/E...ng%20Inaccu.pdf
http://www.jstor.org/pss/1390930
http://www.antigrain.com/doc/introduction/introduction.agdoc.html
http://anteru.net/projects/research/subpixel-reconstruction-antialiasing/
Posted By: rojart

Re: MLAA on the GPU using Direct3D9 (DEMO) - 03/07/11 00:49

The original GPU Pro 2 MLAA source code was released.

Does anyone know, how to convert it?
Click to reveal..
/**
* Copyright (C) 2010 Jorge Jimenez (jorge@iryoku.com)
* Copyright (C) 2010 Belen Masia (bmasia@unizar.es)
* Copyright (C) 2010 Jose I. Echevarria (joseignacioechevarria@gmail.com)
* Copyright (C) 2010 Fernando Navarro (fernandn@microsoft.com)
* Copyright (C) 2010 Diego Gutierrez (diegog@unizar.es)
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice,
* this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the following statement:
*
* "Uses Jimenez's MLAA. Copyright (C) 2010 by Jorge Jimenez, Belen Masia,
* Jose I. Echevarria, Fernando Navarro and Diego Gutierrez."
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS
* IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
* THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL COPYRIGHT HOLDERS OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*
* The views and conclusions contained in the software and documentation are
* those of the authors and should not be interpreted as representing official
* policies, either expressed or implied, of the copyright holders.
*/


// Just for checking syntax at compile time
#if !defined(PIXEL_SIZE)
#define PIXEL_SIZE float2(1.0 / 1280.0, 1.0 / 720.0)
#define MAX_SEARCH_STEPS 8
#define MAX_DISTANCE 32
#endif

/**
* Here we have an interesting define. In the last pass we make usage of
* bilinear filtering to avoid some lerps; however, bilinear filtering
* in DX9, under DX9 hardware (but not in DX9 code running on DX10 hardware)
* is done in gamma space, which gives sustantially worser results. So, this
* flag allows to avoid the bilinear filter trick, changing it with some
* software lerps.
*
* So, to summarize, it is safe to use the bilinear filter trick when you are
* using DX10 hardware on DX9. However, for the best results when using DX9
* hardware, it is recommended comment this line.
*/

#define BILINEAR_FILTER_TRICK


/**
* Input vars and textures.
*/

float threshold;
texture2D colorTex;
texture2D depthTex;
texture2D edgesTex;
texture2D blendTex;
texture2D areaTex;


/**
* DX9 samplers hell following this.
*/

sampler2D colorMap {
Texture = <colorTex>;
AddressU = Clamp; AddressV = Clamp;
MipFilter = Point; MinFilter = Point; MagFilter = Point;
SRGBTexture = true;
};

sampler2D colorMapL {
Texture = <colorTex>;
AddressU = Clamp; AddressV = Clamp;
MipFilter = Point; MinFilter = Linear; MagFilter = Linear;
SRGBTexture = true;
};

sampler2D depthMap {
Texture = <depthTex>;
AddressU = Clamp; AddressV = Clamp;
MipFilter = Point; MinFilter = Point; MagFilter = Point;
SRGBTexture = false;
};

sampler2D edgesMap {
Texture = <edgesTex>;
AddressU = Clamp; AddressV = Clamp;
MipFilter = Point; MinFilter = Point; MagFilter = Point;
SRGBTexture = false;
};

sampler2D edgesMapL {
Texture = <edgesTex>;
AddressU = Clamp; AddressV = Clamp;
MipFilter = Point; MinFilter = Linear; MagFilter = Linear;
SRGBTexture = false;
};

sampler2D blendMap {
Texture = <blendTex>;
AddressU = Clamp; AddressV = Clamp;
MipFilter = Point; MinFilter = Point; MagFilter = Point;
SRGBTexture = false;
};

sampler2D areaMap {
Texture = <areaTex>;
AddressU = Clamp; AddressV = Clamp; AddressW = Clamp;
MipFilter = Point; MinFilter = Point; MagFilter = Point;
SRGBTexture = false;
};


/**
* Typical Multiply-Add operation to ease translation to assembly code.
*/

float4 mad(float4 m, float4 a, float4 b) {
#if defined(XBOX)
float4 result;
asm {
mad result, m, a, b
};
return result;
#else
return m * a + b;
#endif
}


/**
* This one just returns the first level of a mip map chain, which allow us to
* avoid the nasty ddx/ddy warnings, even improving the performance a little
* bit.
*/

float4 tex2Dlevel0(sampler2D map, float2 texcoord) {
return tex2Dlod(map, float4(texcoord, 0.0, 0.0));
}


/**
* Same as above, this eases translation to assembly code;
*/

float4 tex2Doffset(sampler2D map, float2 texcoord, float2 offset) {
#if defined(XBOX) && MAX_SEARCH_STEPS < 6
float4 result;
float x = offset.x;
float y = offset.y;
asm {
tfetch2D result, texcoord, map, OffsetX = x, OffsetY = y
};
return result;
#else
return tex2Dlevel0(map, texcoord + PIXEL_SIZE * offset);
#endif
}


/**
* Ok, we have the distance and both crossing edges, can you please return
* the float2 blending weights?
*/

float2 Area(float2 distance, float e1, float e2) {
// * By dividing by areaSize - 1.0 below we are implicitely offsetting to
// always fall inside of a pixel
// * Rounding prevents bilinear access precision problems
float areaSize = MAX_DISTANCE * 5.0;
float2 pixcoord = MAX_DISTANCE * round(4.0 * float2(e1, e2)) + distance;
float2 texcoord = pixcoord / (areaSize - 1.0);
return tex2Dlevel0(areaMap, texcoord).ra;
}


/**
* 1 S T P A S S ~ C O L O R V E R S I O N
*/

float4 ColorEdgeDetectionPS(float2 texcoord : TEXCOORD0) : COLOR0 {
float3 weights = float3(0.2126,0.7152, 0.0722); // These ones are from the CIE XYZ standard.

float L = dot(tex2Dlevel0(colorMap, texcoord).rgb, weights);
float Lleft = dot(tex2Doffset(colorMap, texcoord, -float2(1.0, 0.0)).rgb, weights);
float Ltop = dot(tex2Doffset(colorMap, texcoord, -float2(0.0, 1.0)).rgb, weights);
float Lright = dot(tex2Doffset(colorMap, texcoord, float2(1.0, 0.0)).rgb, weights);
float Lbottom = dot(tex2Doffset(colorMap, texcoord, float2(0.0, 1.0)).rgb, weights);

/**
* We detect edges in gamma 1.0/2.0 space. Gamma space boosts the contrast
* of the blacks, where the human vision system is more sensitive to small
* gradations of intensity.
*/
float4 delta = abs(sqrt(L).xxxx - sqrt(float4(Lleft, Ltop, Lright, Lbottom)));
float4 edges = step(threshold.xxxx, delta);

if (dot(edges, 1.0) == 0.0)
discard;

return edges;
}


/**
* 1 S T P A S S ~ D E P T H V E R S I O N
*/

float4 DepthEdgeDetectionPS(float2 texcoord : TEXCOORD0) : COLOR0 {
float D = tex2Dlevel0(depthMap, texcoord).r;
float Dleft = tex2Doffset(depthMap, texcoord, -float2(1.0, 0.0)).r;
float Dtop = tex2Doffset(depthMap, texcoord, -float2(0.0, 1.0)).r;
float Dright = tex2Doffset(depthMap, texcoord, float2(1.0, 0.0)).r;
float Dbottom = tex2Doffset(depthMap, texcoord, float2(0.0, 1.0)).r;

float4 delta = abs(D.xxxx - float4(Dleft, Dtop, Dright, Dbottom));
float4 edges = step(threshold.xxxx / 10.0, delta); // Dividing by 10 give us results similar to the color-based detection.

if (dot(edges, 1.0) == 0.0)
discard;

return edges;
}


/**
* Search functions for the 2nd pass.
*/

float SearchXLeft(float2 texcoord) {
// We compare with 0.9 to prevent bilinear access precision problems.
float i;
float e = 0.0;
for (i = -1.5; i > -2.0 * MAX_SEARCH_STEPS; i -= 2.0) {
e = tex2Doffset(edgesMapL, texcoord, float2(i, 0.0)).g;
[flatten] if (e < 0.9) break;
}
return max(i + 1.5 - 2.0 * e, -2.0 * MAX_SEARCH_STEPS);
}

float SearchXRight(float2 texcoord) {
float i;
float e = 0.0;
for (i = 1.5; i < 2.0 * MAX_SEARCH_STEPS; i += 2.0) {
e = tex2Doffset(edgesMapL, texcoord, float2(i, 0.0)).g;
[flatten] if (e < 0.9) break;
}
return min(i - 1.5 + 2.0 * e, 2.0 * MAX_SEARCH_STEPS);
}

float SearchYUp(float2 texcoord) {
float i;
float e = 0.0;
for (i = -1.5; i > -2.0 * MAX_SEARCH_STEPS; i -= 2.0) {
e = tex2Doffset(edgesMapL, texcoord, float2(i, 0.0).yx).r;
[flatten] if (e < 0.9) break;
}
return max(i + 1.5 - 2.0 * e, -2.0 * MAX_SEARCH_STEPS);
}

float SearchYDown(float2 texcoord) {
float i;
float e = 0.0;
for (i = 1.5; i < 2.0 * MAX_SEARCH_STEPS; i += 2.0) {
e = tex2Doffset(edgesMapL, texcoord, float2(i, 0.0).yx).r;
[flatten] if (e < 0.9) break;
}
return min(i - 1.5 + 2.0 * e, 2.0 * MAX_SEARCH_STEPS);
}


/**
* Checks if the crossing edges e1 and e2 correspond to a _U_ shape.
*/

bool IsUShape(float e1, float e2) {
float t = e1 + e2;
return abs(t - 1.5) < 0.1 || abs(t - 0.5) < 0.1;
}

/**
* S E C O N D P A S S
*/

float4 BlendWeightCalculationPS(float2 texcoord : TEXCOORD0) : COLOR0 {
float4 areas = 0.0;

float2 e = tex2Dlevel0(edgesMap, texcoord);

[branch]
if (e.g) { // Edge at north

// Search distances to the left and to the right:
float2 d = float2(SearchXLeft(texcoord), SearchXRight(texcoord));

// Now fetch the crossing edges. Instead of sampling between edgels, we
// sample at -0.25, to be able to discern what value has each edgel:
float4 coords = mad(float4(d.x, -0.25, d.y + 1.0, -0.25),
PIXEL_SIZE.xyxy, texcoord.xyxy);
float e1 = tex2Dlevel0(edgesMapL, coords.xy).r;
float e2 = tex2Dlevel0(edgesMapL, coords.zw).r;

if (-d.r + d.g + 1 > 1 || IsUShape(e1, e2)) {
// Ok, we know how this pattern looks like, now it is time for getting
// the actual area:
areas.rg = Area(abs(d), e1, e2);
}
}

[branch]
if (e.r) { // Edge at west

// Search distances to the top and to the bottom:
float2 d = float2(SearchYUp(texcoord), SearchYDown(texcoord));

// Now fetch the crossing edges (yet again):
float4 coords = mad(float4(-0.25, d.x, -0.25, d.y + 1.0),
PIXEL_SIZE.xyxy, texcoord.xyxy);
float e1 = tex2Dlevel0(edgesMapL, coords.xy).g;
float e2 = tex2Dlevel0(edgesMapL, coords.zw).g;

if (-d.r + d.g + 1 > 1 || IsUShape(e1, e2)) {
// Get the area for this direction:
areas.ba = Area(abs(d), e1, e2);
}
}

return areas;
}


/**
* T H I R D P A S S
*/

float4 NeighborhoodBlendingPS(float2 texcoord : TEXCOORD0) : COLOR0 {
// Fetch the blending weights for current pixel:
float4 topLeft = tex2Dlevel0(blendMap, texcoord);
float bottom = tex2Doffset(blendMap, texcoord, float2(0.0, 1.0)).g;
float right = tex2Doffset(blendMap, texcoord, float2(1.0, 0.0)).a;
float4 a = float4(topLeft.r, bottom, topLeft.b, right);

// There is some blending weight with a value greater than 0.0?
float sum = dot(a, 1.0);
[branch]
if (sum > 0.0) {;
float4 color = 0.0;

// Add the contributions of the possible 4 lines that can cross this pixel:
#ifdef BILINEAR_FILTER_TRICK
float4 o = a * PIXEL_SIZE.yyxx;
color = mad(tex2Dlevel0(colorMapL, texcoord + float2( 0.0, -o.r)), a.r, color);
color = mad(tex2Dlevel0(colorMapL, texcoord + float2( 0.0, o.g)), a.g, color);
color = mad(tex2Dlevel0(colorMapL, texcoord + float2(-o.b, 0.0)), a.b, color);
color = mad(tex2Dlevel0(colorMapL, texcoord + float2( o.a, 0.0)), a.a, color);
#else
float4 C = tex2Dlevel0(colorMap, texcoord);
float4 Cleft = tex2Doffset(colorMap, texcoord, -float2(1.0, 0.0));
float4 Ctop = tex2Doffset(colorMap, texcoord, -float2(0.0, 1.0));
float4 Cright = tex2Doffset(colorMap, texcoord, float2(1.0, 0.0));
float4 Cbottom = tex2Doffset(colorMap, texcoord, float2(0.0, 1.0));
color = mad(lerp(C, Ctop, a.r), a.r, color);
color = mad(lerp(C, Cbottom, a.g), a.g, color);
color = mad(lerp(C, Cleft, a.b), a.b, color);
color = mad(lerp(C, Cright, a.a), a.a, color);
#endif

// Normalize the resulting color and we are finished!
return color / sum;
} else {
return tex2Dlevel0(colorMap, texcoord);
}
}


/**
* Time for some techniques!
*/

technique ColorEdgeDetection {
pass ColorEdgeDetection {
VertexShader = null;
PixelShader = compile ps_3_0 ColorEdgeDetectionPS();
ZEnable = false;
SRGBWriteEnable = false;

// We will be creating the stencil buffer for later usage.
StencilEnable = true;
StencilPass = REPLACE;
StencilRef = 1;
}
}

technique DepthEdgeDetection {
pass DepthEdgeDetection {
VertexShader = null;
PixelShader = compile ps_3_0 DepthEdgeDetectionPS();
ZEnable = false;
SRGBWriteEnable = false;

// We will be creating the stencil buffer for later usage.
StencilEnable = true;
StencilPass = REPLACE;
StencilRef = 1;
}
}

technique BlendWeightCalculation {
pass BlendWeightCalculation {
VertexShader = null;
PixelShader = compile ps_3_0 BlendWeightCalculationPS();
ZEnable = false;
SRGBWriteEnable = false;

// Here we want to process only marked pixels.
StencilEnable = true;
StencilPass = KEEP;
StencilFunc = EQUAL;
StencilRef = 1;
}
}

technique NeighborhoodBlending {
pass NeighborhoodBlending {
VertexShader = null;
PixelShader = compile ps_3_0 NeighborhoodBlendingPS();
ZEnable = false;
SRGBWriteEnable = true;

// Here we want to process only marked pixels.
StencilEnable = true;
StencilPass = KEEP;
StencilFunc = EQUAL;
StencilRef = 1;
}
}

by the way:
GPU Pro 2 Example Programs and Source Code
Posted By: 1234David

Re: MLAA on the GPU using Direct3D9 (DEMO) - 01/07/15 18:36

Hello,
I know this thread is a bit old, but I want to know what's new about the MLAA-Shader and the implementation in 3d gamestudio?
Posted By: Kartoffel

Re: MLAA on the GPU using Direct3D9 (DEMO) - 01/07/15 19:52

by now there's already smaa (the successor of mlaa) wink

also, like with all post processing shaders you can't simply combine them without doing some shader coding yourself.
so if you're already using postprocessing shaders, mlaa will most likely not work in combination with your current shaders.
© 2024 lite-C Forums