Hi Robert,
It should be possible to move the quad adjustment into the Glyph object
since the geometry manipulation being performed is relative to the
character size and texture coordinates which are known by the Glyph at
creation time. I didn't notice that glyphs already stored positioning
information in addition to cell sizes or I may have put the code there
to begin with. I may look into making that update this weekend.
I found it difficult to produce text that overlapped in a way that
produced issues with the depth buffer. It is the likelihood of
occurrence rather than visual results produced that led me to prefer the
faster method of disabling depth writes. In order to see artifacts, the
following must occur:
1. Text must be drawn on the same pixels (obviously).
2. Depth sorting must fail - usually because text strings intersect.
(not an issue for screen-aligned text)
3. Text must be in different colors. (or depth writing is on)
I think this will occur mostly in contrived examples so I would prefer
the fast method to the method that looks better on the rare situation
that it fails. The other point of view is that we can just let the user
turn off the depth writes if they want more performance. If most users
have graphics power to burn then this looks like a much better option. I
for one am always pushing too much data to the video card and am
constantly looking for ways to speed things up and would prefer if osg
always chose the high performance option by default so I could just
change settings when I found unacceptable artifacts in my model. But
your judgment as to the average user osg user would want is better than
mine.
Regarding the backdrops: I see little reason to keep the existing
backdrop implementations. People who get/set the backdrop implementation
will have to change their code so you won't have 100% source code API
compatibility with earlier versions. (I didn't know if that is a goal.)
There are slightly different trade offs between performance and
appearance in the different methods but I don't think they're
significant enough that anyone relies on them. I don't see anyone
complaining that a method was dropped, only that they have to edit their
code to get it to compile if they were explicitly choosing a method to use.
Mark
On 9/16/2010 2:10 AM, Robert Osfield wrote:
Hi Mark,
I've just merged and tested your changes and things look good to me.
I do wonder of the quad adjustment could be pushed back into
osgText::Glyph, something for me to reflect on later.
One thing I did find is that testing with osgtext is that the text
would not render correctly when different text labels were overlapping
in deth and screen space. I change _enableDepthWrites to default to
true and found the that which artifacts still occurred around the
alpha blended edges the artifacts where better than issue with
occlusion of nearer pixels that was happening with _enableDepthWrites
set to false. I therefore set the _enableDepthWrites to true as I
feel it's the lesser of the two artefacts. With this change I've now
checked it into svn/trunk.
As for the techniques that can be depracted. Perhaps just dropped
completely... Thoughts?
Robert.
On Mon, Sep 13, 2010 at 9:38 PM, Mark Sciabica<[email protected]> wrote:
Hi Robert,
Here is the solution I coded up over the weekend. For improved
performance option, I added a flag to control whether the depth writing
pass is performed.
Since text is alpha-blended when rendering, it is placed in the
transparent bin and rendered back to front. Writing to the depth buffer
should therefore be unnecessary. Indeed, rendering something behind text
(or any blended object) after that object is drawn will give incorrect
results whether the depth buffer is written or not. I therefore think it
is safe to keep this option off by default. Users can turn it on for any
special needs they have.
I did not fix the existing backdrop implementations to work with the new
code since this new method of rendering intrinsically handles backdrops
correctly. Its results are more accurate than all of the existing
backdrop implementations. Its only downside is that it requires two
passes if depth buffer updates are desired, whereas DEPTH_RANGE and
POLYGON_OFFSET achieve their (less accurate) results in one pass. The
NO_DEPTH_BUFFER method also only uses one pass, but it disables depth
tests and not depth writes so will have serious problems if anything is
drawn in front of the text before OR after the text is drawn.
Given the better all-around behavior of the new method, I believe the
other backdrop implementations can be safely removed. Code that adjusts
the backdrop implementation will of course be broken if the member
functions are removed. For this reason I left them in, but set the new
rendering method as the default backdrop implementation. At the very
least I think the old backdrop implementations should be deprecated and
removed at a later date.
Mark Sciabica
On 9/10/2010 3:23 AM, Robert Osfield wrote:
Hi Mark and Eric,
I like the idea of two passes, depth write off + depth test on, then a
second depth write on + colour write off + depth test on. This does
sounds like a workable solution.
Can anyone think of any gotcha's with this two pass approach? Could
someone code up such a solution ontop of the OSG in svn/trunk?
Robert.
On Fri, Sep 10, 2010 at 2:41 AM, Mark Sciabica<[email protected]>
wrote:
Hi Robert and Eric,
Perhaps I can try to explain the limitations of my solution more clearly
so
a more informed decision may be made whether to include some version of
it
in OSG.
Because each glyph is rendered to an area larger than the glyph size,
there
is some overlap between adjacent glyphs. Depending on the glyphs being
rendered, depth test settings, view angles, and resulting round off error
can cause one glyph to prevent some of its neighbor's pixels from
rendering.
The solution to this problem is to prevent each glyph's pixels from being
depth tested against neighboring glyphs' pixels.
In my usage, I do this by disabling depth writes (depth test is not
disabled) for text since my text is always drawn against some background
object - I have no need for text floating in space occluding other
objects.
This means that free-floating text can be overwritten by objects behind
it.
However, it can be argued that antialiased text, as a semi-transparent
object, ought to be rendered after all objects behind it anyway.
If desired, support for the current style of free-floating text can be
achieved by using multiple passes: Drawing the text first with depth
writes
off, then rendering again, but writing only to the depth buffer. Some
text
styles (using backdrops) already use multiple pass rendering so I would
guess that this variant would be acceptable for inclusion in OSG.
In my particular case, I draw enough text that performance is an issue so
I
stuck with the the single pass technique for my application. The two-pass
method does not look difficult, though, so if it's desired for inclusion
in
a future OSG release, I can find the time to write the code.
It sounds like Robert is proposing subdividing glyphs and choosing a
depth
test so that equal depth glyphs will not prevent each other from
rendering.
This sounds like a workable solution to the problem. I would even think
it
preferable if all of our character cells were the same dimension, but
with
varying width and height characters on multiple lines, we're talking
about a
fairly complex algorithm that even if it is fast enough to execute, will
take quite a bit of time to develop.
Mark Sciabica
On 9/9/2010 1:13 PM, Eric Sokolowsky wrote:
Robert,
I'm not doing anything to the depth test. If you actually look at the
change
being proposed, it is just copying a bit larger of an area for each glyph
so
that the anti-aliased edges aren't clipped off.
-Eric
On Thu, Sep 9, 2010 at 11:56 AM, Robert Osfield<[email protected]>
wrote:
HI Eric,
My issue with this approach hasn't changed - it's simply not
acceptable to disable depth test indiscriminately for Text as it'll
force text to always appear on top of everything except things
rendered after it. Once can workaround this issue by using a
multi-pass stencil buffer technique.
The proper solution will be to not render simple quads for each glyph
but compute the intersection between adjacent quads and render the
glyph as a series of quads so that the overlap share exactly the same
vertices so will render at the same depth. Once this is done you can
keep depth test on, but get fragments with the same depth to pass the
depth test.
I have some of the design work done for this approach but haven't
tackled any of the implementation.
Robert.
On Thu, Sep 9, 2010 at 3:50 PM, Eric Sokolowsky<[email protected]>
wrote:
I have long been annoyed by osg::Text clipping characters at random
times.
Way back in March 2008, Mark Sciabica wrote:
My solution was to modify osgText to draw larger quads for the
character cells (by one texel in each direction), adjusting texture
coordinates accordingly. Side effects are that character cells now
overlap so depth testing needs to be disabled (or some sort of
stenciling operation performed), and extra margin should be allocated
for each character in the texture (using Font::setGlyphImageMargin).
Mark wrote a patch to osg/src/osgText/Text.cpp which fixes the problem
for
me, but this change was never incorporated into OSG proper. In his
original
message, Mark wrote that this solution required the depth test to be
disabled when drawing glyphs to avoid clipping. I did not encounter any
problems with clipping when applying his patch. The attached Text.cpp
is
based on OSG 2.8.3, and I propose it be added and Mark Sciabica be
given
due
credit for its inclusion. I am also including a screen shot of some
text
not
using the patch (broken-cropped.png) and the same screen using the
patch
(fixed-cropped.png). The difference is most noticeable on the left edge
of
certain characters such as 'G', but the change also fixes some of the
hard
left edges such as '['. With the fix, all of the left edges are nice
and
anti-aliased.
I'm not sure if the other statement Mark made (extra margin should be
allocated for each character in the texture) is needed or not.
I'm aware that Robert is doing some fixes to osgText so if these
changes
do
not work for the trunk then I'd like to at least have them
incorportated
into the 2.8 branch.
-Eric
This message and any attachments are solely for the intended recipient and may
contain confidential or privileged information. If you are not the intended
recipient, any disclosure, copying, use, or distribution of the information
included in this message and any attachments is prohibited. If you have
received this communication in error, please notify us by reply e-mail and
immediately and permanently delete this message and any attachments. Thank you.
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
