"There's a saying that states: 'The road to hell is paved with good intentions'. There's hardly anything that better describes communism than that. All good hopes and dreams of justice and equality have ended in oppression and dictatorship."
- Peter Eriksson, Green Party of Sweden
More pages: 1 ... 11 ... 21 ... 31 ... 37 38 39 40 41 42 43 44 45 46 47 ... 51 ... 61 ... 71 ... 81 ... 91 ... 101 ... 111 ... 121 ... 131 ... 141 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 365
Query FailedRich
Tuesday, March 15, 2011

Could the technique be used on console? Any idea on performance and memory implications in comparison to Sony's MLAA?

Humus
Tuesday, March 15, 2011

zhugel_007: Well, alpha-test doesn't work with MSAA either so it's not a new problem. However, I think something like the technique I used in this demo might work:
http://www.humus.name/index.php?page=3D&ID=61

If you have the alpha-slope in screen-space you could do the same kind of smoothing as a post-process. But you'd have to render the whole surface again, not just the edges.

Henk
Tuesday, March 15, 2011

Thnx for this demo

zhugel_007
Tuesday, March 15, 2011

Actually, because the depth buffer is not used, this method would not work for alpha-test object.

zhugel_007
Tuesday, March 15, 2011

Actually, because the depth buffer is not used, this method would not work for alpha-test object.

Zhugel_007
Monday, March 14, 2011

Actually, there are something going bizarre if linear depth is used. looks like the per pixel depth is not interpolated correctly.

Zhugel_007
Monday, March 14, 2011

Really nice article. it explains lots of questions in my head. One more question though I understand what you've explained in your article, but what if i force the Z to be linear. (play with the projection matrix by dividing fFar:
mProj._33/=fFar;
mProj._43/=fFar;
and multiply W in vertex shader:
float4 vPos = mul(Input.Pos,worldViewProj);
vPos.z = vPos.z * vPos.w;
Output.Pos = vPos
Would there be any visual difference compared with using the hyperbolic Z in the final rendering result? I did this test, and visually, it looks the same as using the hyperbolic Z. Also, would this break the Hi-Z? (looks ok in pix though)

Humus
Sunday, March 13, 2011

TomF: Forgot to answer the copying question ... it needs the backbuffer as an input while also rendering to it. If the hardware could read from and write to the same surface in the same draw call there wouldn't have to be a copying needed. In DX10 it's explicitely disallowed, but I guess it might work on same hardware in DX9 and I suppose it might work on consoles.

WheretIB: Well, antialiasing edges of transparent surfaces should work fine I think (haven't tested though). However, background edges behind a transparent surface would smear pixels on the transparent surface. This may not be so visible though. But in any case it should be possible to separate the rendering into two passes, one for opaque followed by its GPAA pass, then transparent surfaces on top of that and then GPAA of that.

More pages: 1 ... 11 ... 21 ... 31 ... 37 38 39 40 41 42 43 44 45 46 47 ... 51 ... 61 ... 71 ... 81 ... 91 ... 101 ... 111 ... 121 ... 131 ... 141 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 365