Re: Antialiassing in an FxPlug
Re: Antialiassing in an FxPlug
- Subject: Re: Antialiassing in an FxPlug
- From: Pete Warden <email@hidden>
- Date: Mon, 4 Feb 2008 10:28:36 -0800
Super-sampling is the simplest way of reducing aliasing but you're
right there's more advanced techniques you can use. I can't discuss
Motion's implementation and I'm not sure what the typical content of
your scene is but here are some general pointers on anti-aliasing:
- For the best results, work in linear space, not gamma-corrected. The
resampling will look better with fewer samples. This means using 16-
bit float buffers at least, and converting to and from 8 bit gamma
corrected inputs and outputs. We're currently trying to prepare some
documentation on the recommended way to do this in FxPlugs.
- If you're drawing large images scaled down, or with perspective
transforms, make sure you're using a good down-sampling algorithm,
like rip-maps and anisotropic filtering.
- With polygons, an old game trick is to get a cheap quality boost by
drawing anti-aliased lines along the edges of your geometry as an
initial pass before drawing the filled shapes. One thing to watch out
for with this is that anti-aliased lines require blending support and
that's not available on many cards at float bit depths.
I'm not sure about your FCP question, maybe Paul could answer that?
Pete
On Feb 4, 2008, at 5:23 AM, Gary Fielke wrote:
Thanks Pete,
I draw my scene into a double-sized FBO, then draw the attached
texture as a quad to my single-sized FBO. With a half pixel offset
in texture coordinates the aliasing is certainly reduced.
It's just not as good as Motion seems to do it. How does Motion do
its antialiasing?
Also, does the FxPlug need to de-interlace frames prior to
performing this antialiasing in FCP? With interlaced frames, the
output seems a little untidy around the edges.
Cheers,
Gary
On 01/02/2008, at 6:40 AM, email@hidden wrote:
Message: 4
Date: Thu, 31 Jan 2008 11:02:07 -0800
From: Pete Warden <email@hidden>
Subject: Re: Antialiassing in an FxPlug
To: email@hidden
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
One trick you can use is to just use the default bilinear filtering
to
resample four pixels to one without a shader. You need to set up your
texture coordinates so that the sample point is at the corner of four
pixels when drawing to the final output, but it's an efficient way of
using the hardware. Doing an extra pass is always costly though.
Back when I was coding plugins for another app that shall remain
nameless, I used the same general over-sampling technique to reduce
aliasing, and offered it as an extra user control, as a filter
parameter. If you're worried about the performance hit, that might be
an option.
Pete
On Jan 31, 2008, at 5:56 AM, Gary Fielke wrote:
Thanks Pete, just what I was after (the tiling tip will undoubtedly
be useful also)
Re the "scale down and resample result into the output" stage is it
preferable to use GLSL to average neighbour pixels in a frag shader?
Or is there a better option?
Out of curiosity I just tested out CILanczosScaleTransform to scale
down from a 2x2 FBO. It seemed to work well but a bit slow on my G4
PowerBook. This might be suitable for the rendering stage but I'm
not sure yet how well it would play if tiling of image buffers was
required.
Thanks again
Gary
Hi Gary,
you're right, there are a lot of mines to step on when
trying to get multisampling working in an FxPlug. Since as you
discovered PBuffers don't support them, and I'm not sure of the
state
of FBO support, we've tended to do the same operations manually. I
don't have much information on the state of hidden windows, since
it's
been a long time since we used them, but it's a pretty unusual path
to
be using these days and I wouldn't recommend it.
Basically, allocate a pbuffer or FBO that's several times larger
than
the final output, and draw into it scaled up. Then as a final pass,
scale down and resample the result into the output.
One thing to watch out for with this is that you may hit card
limits
to the maximum texture size, or even how many textures will fit in
VRAM at 16 and 32 bit float bit depths. FCP and Motion have
checks to
limit the output size they request to stay within those limits.
Rather
than allocating one large buffer, you may instead want to allocate
several smaller buffers at the output size, draw separately into
them
as tiles, and then join them together by rendering them into the
final
output.
Is that any help?
Pete
*********************************
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
@apple.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden