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 >> > >> > >> > _______________________________________________ >> > osg-submissions mailing list >> > [email protected] >> > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> > >> > >> _______________________________________________ >> osg-submissions mailing list >> [email protected] >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > ________________________________ > 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 > > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
