Fill Ellipse from a fragment shader

In this case it’s perfect fine. The only problem would be if smoothstep didn’t fullfill its contract. To cover that hypothetical situation the compare really should be <= 0 rather than some ad-hoc constant.

But again, the discard doesn’t buy you any quality. In either case (with or without) if you render anything behind…it will be wrong. The advantage of the bounding rectangle wrong is that it will be immediately obvious what the problem is. The “jaggy” depth buffer wrong could take awhile to figure out…esp if it pops up at a much later date. (aliased looking thing behind with a strangely colored edge of the forward).

On fwidth: The problem is that it’s a misleading function name. You expect it to be L2 when it’s in fact Linf. Want you really want is some approximation of pixel coverage, for cheapish I’d go for (L2)2: dFdx2+dFdy2

i dont know. fwidth^2 isn’t going to work out of the box due to the projection.

after all fwidth works window space so it wont return correct values when the surface partially covered by something drawn before. for best result such AA should be handled the same way transparent surfaces are handled.

Hi,

I’m not on the “AA” feature (that seems to be another complete topic :persecutioncomplex:)
But the discard() is not mandatory if you play with glBlend function by example if you set an equivalent than AlphaComposite.SRC ?

yes, you’re right. discard here is good cos’ it avoids writing invisible pixels to the depth-buffer. visually it’s the same.

I’m not talking about fwidth squared: (|dx|+|dy|)2 And like I said…the invisible pixels don’t matter…you render behind and it’s broken. If the argument becomes performance then you have Pi ab vs. 4ab. So ~79% of the time you’re inside (and the compare and not taking discard hurts you) and the rest you’ve already performed all the work you’re going to do and are only skipping on some writes.

NOTE: I said LInf when I meant L1 above.

yes i know. dfdx^2+dfdy^2 has the same issues with projections tho’.

in the end if you want a antialiased shape rendered correctly with msaa buffer, early z, any draw-order and blending then you need polygons anyway.

shading it like that is the same as using a texture with alpha. gotta use alpha-to-coverage or sample-shading (which is defeating the idea of analytic AA).

Don’t use discard() directly. It’s more flexible to simply output the alpha to the alpha channel and then do the rest using glEnable()s. Want fast but aliased result? Enable the alpha test. Want alpha-to-coverage? Just enable it. Want supersampling? Enable alpha test+sample shading. If you discard in the shader, you can’t use it for alpha-to-coverage. Even discarding on alpha==0.0 is slower, as the if-statement is more expensive than the writing.

aah, good to know.

That would imply that gpu’s still have special alpha test unit? Do they? Dx11 does not have alpha testing stage anymore which I have taken as hint that gpu’s might have get rid of that too.