[Humus]

I have a new demo which illustrates a simple but effective technique for dealing with aliasing on thin wires.

Results:

Normal size:


Zoomed:


Download from my site

[Alexko]

Nice. Going by the description on your website, that sounds very cheap computationally.

[Humus]

Yes, it's very cheap. To core of this technique is basically a handful of ALU instructions in the vertex shader.

[fellix]

Is this clamping method applicable to any type of geometry, that nears the sub-sample boundary size?

[homerdog]

"A similar approach could likely be used on other aliasing prone geometry based on thin geometry, such as antenna towers, pipes and railings."

http://www.humus.name/index.php?page=3D&ID=89

[Humus]

Originally Posted by fellix

Is this clamping method applicable to any type of geometry, that nears the sub-sample boundary size?

It should be quite straightforward to apply the same idea to anything cylindrical or spherical. So pipes and railings should be straightforward and if you build your antenna towers out of metal bars it should just work. I don't know how well the idea would extend to non-round objects, like rectangular shapes etc. You would probably need to take orientation into account. Intuitively my guess is that it should work, but I can't guarantee that before I've tried.

[Malo]

"Our new title does in fact support MSAA + FXAA and even SSAA for you PC fanatics!"

"Yeah but does it support WAA!?!??"

[micron]

I saw this demo linked at the Chinese technology site expreview.com. The translation used the term "Force of God" to describe how awesome it is

[Acert93]

Awesome--and the solution sounds so simple that going forward there is no excuse. Kudos Humus!

[Dominik D]

Originally Posted by Malo

"Yeah but does it support WAA!?!??"

You wanted to SAY WHAA?! I guess.

[Barbarian]

It seems like this can be generalized via contour detection similar to the cell shading methods, then expanding the edges and converting coverage to alpha.
Proper sorting will still remain a problem, but perhaps with DX11 there might be efficient ways to sort per fragment.

[reptile]

Interesting approach. We solved this problem by drawing the wires again as a linelist, this way nearby portions would get hidden by the actual geometry, and far away segments would never go below 1 pixel in size.

[3dcgi]

Originally Posted by Barbarian

It seems like this can be generalized via contour detection similar to the cell shading methods, then expanding the edges and converting coverage to alpha.
Proper sorting will still remain a problem, but perhaps with DX11 there might be efficient ways to sort per fragment.

Here's one method to sort per fragment.
http://www.slideshare.net/hgruen/oit...1-linked-lists

[CeeJay.dk]

A quick idea : During development apply this to everything in your scene, and then only show (or highlight) the pixels that were affected, to detect good candidates to apply this technique to in the final product - rather than guessing what geometry it might be good for.

[CeeJay.dk]

Humus, is the texture lookup in the pixelshader really necessary?

Since the phonelines are only 1 pixel wide, it seems to me that you could simply use an already defined color .. perhaps the vertex color.

[CeeJay.dk]

I did some tests on my own and you can indeed skip the texture lookup whenever In.Fade.x goes below 1, without being able to tell the difference.

However seeing is this is already such a simple shader it's bottleneck is the export and not the texture lookup on most platforms, so you really don't save anything by this.

You'd have to not run the pixelshader at all, to do it faster - perhaps an alpha test might work?

[digitalwanderer]

Well I've known all along Humus was a programming god, but it is nice to see the Chinese finally getting around to admitting it.

Good job Humus, thank you!!!!

[Humus]

Originally Posted by CeeJay.dk

A quick idea : During development apply this to everything in your scene, and then only show (or highlight) the pixels that were affected, to detect good candidates to apply this technique to in the final product - rather than guessing what geometry it might be good for.

Well, the technique is designed for this particular type of geometry, i.e. cylinder shape. So it will work on bars, railings etc. also, but can't just be applied to "everything". I'm sure you can come up with similar solutions for other types of geometry, but this case is one of the most commonly occurring source of aliasing in real games and also relatively straightforward to solve. I think this technique will work relatively well with a square cross-section as well, but I haven't tested that. Might need to clamp to a wider line, like sqrt(2) width to ensure there are no dropped pixels in all angles, alternatively take view angle into account.

Originally Posted by CeeJay.dk

I did some tests on my own and you can indeed skip the texture lookup whenever In.Fade.x goes below 1, without being able to tell the difference.

Sure. I'm not concerned with performance here though, so I stayed with a single pass. In a real game engine you may want to split the fully opaque parts from the translucent ones. Not so much for performance, just to better work with deferred rendering etc. May also want to sort the translucent parts if that makes a visual difference somewhere. If you do split you would probably do the translucent parts with a simpler shader, without texture lookups or lighting. Probably just a constant color. In the demo I used quite harmless half-lambertian lighting with no specular or anything to avoid getting shader aliasing introduced that way. If you do more fancy (or more correct) lighting you probably want to start fading out the lighting earlier, in particular specular, say at several pixels width, and transition to a constant color.