Re: FxPlug / OpenGL Smooth Line Artifact
Re: FxPlug / OpenGL Smooth Line Artifact
- Subject: Re: FxPlug / OpenGL Smooth Line Artifact
- From: George King <email@hidden>
- Date: Thu, 23 Oct 2008 12:47:47 -0700
Hi Darrin,
Here is a repro of the issue that i am seeing (sorry it took so
long!). It contains an FxPlug and a test app, which call the same
render() function with differing results. Let me know if you want me
to file a bug on this, or if you think I'm making a mistake somewhere.
Problem Description:
The render function clears the context to yellow, then draws a white
line using line smoothing and blending. the blending mode is
GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, which comes out of the OpenGL
red book example.
In the NSOpenGLContext, the result looks as expected. In FCE however,
a dark border appears around the white line. This becomes more visible
if blending is turned off.
Theory (admittedly vague!):
The renderer in FCE is premultiplying the RGB components with the
alpha, which causes the color to fade to black as it gets more
transparent. Not sure if FCE uses its own renderer, if this is a bug
in the Apple software renderer, or what. This notion is supported by
the fact that when I turn blending off, but leave GL_LINE_SMOOTH on,
the smooth line rasterization produces gradients fading from white to
black. In the test context, these appear as solid white lines.
I am not sure if this is a real bug. It's quite possible that there is
some OpenGL state that is different between my text context and the
FxPlug context, but thus far I have been unable to detect it. There is
a bunch of code below the rendering function that prints out OpenGL
state, but it's by no means conclusive.
Bonus: there is a second glClearColor() call in the render code. When
this is uncommented, clearing in the FxPlug context has no effect,
while it works correctly in the test app.
Thanks,
George
Attachment:
FxPlugTest.zip
Description: Zip archive
On Oct 20, 2008, at 10:03 AM, Darrin Cardani wrote:
On Oct 17, 2008, at 5:56 PM, George King wrote:
On Oct 17, 2008, at 5:12 PM, Darrin Cardani wrote:
On Oct 17, 2008, at 5:10 PM, George King wrote:
glClearColor(1,1,1,1);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
I think the above is your problem. Since colors in OpenGL are
already premultiplied, I think you want to use:
glBlendFunc (GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
That fixes my test case, but unfortunately it introduces a similar
problem elsewhere. Now my lines are getting white 'feathers'
instead of black. Below is a screenshot from my project; I'll have
to work at a better test case.
Without knowing how you drew what's in the screenshot, it's hard to
say what the problem could be.
Remember that using (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) works
fine in a fresh NSOpenGLContext.
How are you creating the NSOpenGLContext?
I'm not sure what you mean about premultiplication. My limited
understanding of that term is that when a function requires
premultiplied color data, the color must multiply each color
component by the alpha component ahead of time. So the quadruple
for 100% red at 50% transparency is (.5, 0, 0, .5).
Yes, that's correct.
When I want that color in OpenGL I call glColor4f(1, 0, 0, .5).
Please let me know if I am misunderstanding the concept.
I think you're understanding it correctly. I was under the
impression (though I may be wrong) that you specify colors using
straight alpha, but internally, OpenGL premultiplies them. Maybe I'm
wrong about that. Needless to say, though, Motion and FCP do expect
your plugin to produce premultiplied output, and they give you
premultiplied input.
Darrin
--
Darrin Cardani
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