One last thought about the existing backdrop implementations: I have use for them. I was getting some artifacts using the now-default DelayedDepthWrite method, and reverting to the Stencil Buffer method fixed the problem. Please keep the alternatives around.
Eric On Thu, Sep 16, 2010 at 8:47 PM, Mark Sciabica <[email protected]> wrote: > 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 >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
