Hi Jeremy, osgText doesn't really know anything about pixels, it just works in its own local coordinate frame rendering text as textured quad in a 3D space - its very much like all OSG geometry in this respect.
What you are after is a mode in osgText that is purely for screen aligned text and can make decisions based on this, I can't say how complicated this might get though. As for your blending issue, sort order and blending modes are what you can use to control. I'm afriad I've been too busy to be able to go investigate, its quick replies only right now. Robert. On Jan 17, 2008 3:44 PM, Jeremy Moles <[EMAIL PROTECTED]> wrote: > (This is a separate issue from my blending question which I posted > earlier this week) > > In osgHUD, it is very convenient for me for various reasons to set the > osgText alignment mode to: > > osgText::Text::CENTER_CENTER > > ...which allows me to put a bit of text in the center of a quad and > delegate the responsibility of positioning to my osgHUD::Widget API. > This is all fine and well, and works exactly as advertised. > > However, with regards to quality, there is no guarantee (at least that I > can see) that osgText won't set the position internally of the text to > values that do not map 1:1 to pixels on the screen--that is to say, the > position isn't necessarily "pixel aligned." I looked at the code for > osgText::computePositions() a bit, but figured I'd ask here first in > case I'm missing something obvious. > > My question then is: is there a way to coerce osgText to use > CENTER_CENTER alignment but enforce that the text itself is never > positioned (at least as far as the X and Y planes are concerned) with a > value that isn't pixel aligned? > > Attached are two screenshots of the "osghudmenu" example I'm working on > (which is in SVN if anyone would like to see it!) at the moment. The > first screenshot uses CENTER_CENTER and the second uses LEFT_BOTTOM. Of > course, when I use LEFT_BOTTOM I have to position the text manually > myself (which isn't hard, but certainly creates more code). In both > cases I enforce that the X and Y values to pass to ->setPosition() are > floor()'d, but that doesn't mean that osgText itself won't add 0.5f or > so to the position, especially in CENTER_CENTER mode. To the discerning > eye, you'll see a MAJOR difference... > > Hope I'm making sense. :) > > P. S. Anyone who has any advice on my question from earlier this week > gets a cookie or something. :) > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
