Hi Jeremy, On Tue, Oct 7, 2008 at 3:00 PM, Jeremy Moles <[EMAIL PROTECTED]> wrote: >> But does it render properly from the back? > > Well, no matter what I do I can't get it to render properly from both > sides using my current method.
I suspected this would be the case. > However, as long as I make sure the > geometry's Z values are properly ascending (that is, the first quad has > a z == -1.0f, and each quad increments z by 0.001f) then it renders > properly from the front at least. > > The real way to do it, I think, is to have an UpdateCallback that sorts > the Geometry based on each quad's size somehow, switching to > DrawElements instead of DrawArrays... One could possibly use glPolygonOffset but this is has problems of its own. One approach I have contemplated for osgText is to allow for the glyphs quads to overlap, but whether there is an overlap break the quads up into non overlapping and overlapping chunks. Then when the glyphs are rendered the parts that overlap use exactly the same coords so all fragments on the overlap have the same coordinates which in turn means that you can the depth test mode that allows fragments through when their z value is the same or less. While I'm not at a point that I can dive into osgText right now, me feeling is that osgPango and osgText functionality need to be brought all under osgText, with us learning from when Pango and osggPango do above the existing osgText library and coding this directly into osgText, whilest at the same time taking advantage of some more robust rendering approach such as the one I suggest above. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
