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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > > 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
