[osg-users] Some issues with osgText / Signed Distance Field rendering
OpenSceneGraph Users
osg-users at lists.openscenegraph.org
Fri Feb 7 02:45:36 PST 2020
Hello Robert,
I toyed around with SDF and discovered some problems in the fragment shader
that I managed to solve.
There seems to be a bug in the multisampling/blending code. Affected are
semi-transparent texts. It’s most obvious for glyphs with a big fill area,
like e.g. for the bullet character. In the attached picture, the upper
bullet character was rendered with the original shader and an alpha value
of 0.2. It looks totally wrong. For comparison, the second line was
rendered with an alpha value of 1 and is fine.
In order to find out what’s wrong I rewrote the code applying the basic
blending “trick” – doing linear combinations of colours with premultiplied
alpha only. (Let’s call them colours in pma format, the transform function
being pma[ (r,g,b,a) ] -> (r*a,g*a,b*a,a).) This resolved the issue for me,
semi-transparent characters now render visually correct.
So, what I did, is:
1. Apply pma transformation to the source colours (vertex colour, border
colour)
2. Do the multisampling. Simply calculate the mean of the sampled
colours. Each sampled colour is a linear combination of the source colours,
so too in pma format.
3. Apply inverse pma transformation for to get the resulting fragment
colour (to be blended with default blend mode (GL_SRC_ALPHA,
GL_ONE_MINUS_SRC_ALPHA)).
This algorithm can be simplified. Obviously, the resulting fragment colour
too is just a linear combination of the source colours. So, I changed the
multisampling loop to only sample the coefficients for the source
colours.(It’s applying distributive law.) This in turn made me get rid of
the pma and inverse pma transformations.
And it also helped resolving the second issue that I had with the shader:
Shadow backdrops were not rendered correctly. The problem was caused but
following lines of code:
total_color.rgb /= total_color.a;
total_color.a *= scale;
return total_color;
I think the division could turn out to be 0.0 / 0.0 which may have produced
NaNs or unspecified results.
A minor issue I encountered that prevented the shader to compile on my GLSL
ES 1.0 system.
The function texture2DLod is specified by the GLSL ES 1.0, GLSL 1.1, GLSL
1.2 specifications only for use in vertex shader. It may be available
though. In my case it wasn’t, but the extension texture2DLodEXT was.
So I made an extra check to prefer that extension, if available, for GLSL
ES 1.0 only.
I experienced another issue that I wasn’t able to solve so far.
On my embedded ES 2.0 system, the GL_OES_standard_derivatives extension is
available but the functions dFdx / dFdy just seem to deliver bad results.
I don’t know why. Could it be non-conforming usage? A driver or GPU bug? As
a workaround, I’ve switched to using a simpler shader for that system only,
which doesn’t do multisampling. The result seems still fine.
Please check out my changes. I’ll do a pull request. I hope this is
helpful, SDF is really a cool feature.
The shader could surely further be simplified when adapting it to blend
mode (GL_ONE, GL_ONE_MINUS_SRC_ALPHA), which would be a bit easier to deal
with.
I also wondered if the extensive bounds checking for smoothstep when
sampling the colours/coefficients is still adequate for performance.
Regards,
Hannes
--
You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osg-users+unsubscribe at googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/575dbd7a-cac9-418f-86da-a9f14ff1d9f3%40googlegroups.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20200207/84bf1cf6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sdf bug.png
Type: image/png
Size: 10036 bytes
Desc: not available
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20200207/84bf1cf6/attachment.png>
More information about the osg-users
mailing list