Hi all, I've also experienced the "font chopping" problem and have also observed that the order of initialisation definately makes a difference to the output.
My latest 'fix' was to use different fonts for the two sizes of text I want to display. jp Robert Osfield wrote: > Hi Jeremy, > > It shouldn't really matter which order you do things in. The > GlyphTexture will be populated in a different order but it shouldn't > make any difference beyond this. The fact you are observing a > difference suggests that GlyphTexture population order is affecting > things in some way. I can't think off hand what this might be - the > only very vague guess would that the tex coords are different in some > way, perhaps this is related to the clipping you've observed. > > FYI, I might be doing some refactoring work of the rendering code > inside osgText in the not too distant future. At this point I will > need to review the lots of code internally with osgText so it'd be a > good time to have some unit tests to utilise - osgWidget might well be > a good way to generate unit tests ;-) > > Robert. > > On Wed, Mar 5, 2008 at 10:33 PM, Jeremy Moles <[EMAIL PROTECTED]> wrote: >> I'd like to add another bit of info to this thread; attached are two >> screenshots (good.png & bad.png) rendered using almost identical code: >> >> good.png (sharp, crisp) >> -------------------------------------------------------------------- >> >> text->setFontResolution(...) >> text->setCharacterSize(...) >> text->setText(...) >> >> >> >> bad.png (very blurry) >> -------------------------------------------------------------------- >> >> text->setText(...) >> text->setFontResolution(...) >> text->setCharacterSize(...) >> text->update() >> >> >> >> Is there something wrong with my 2nd usage of osgText::Text such that I >> get the poorer quality? I understand that in the first usage the font >> sizes are already set before the initial text is rendered internally, >> but shouldn't the 2nd usage produce identical results, given that I call >> update after setting the new values? (My assumption here, however, could >> be woefully wrong, but will be useful information either way. :)) >> >> >> >> >> On Wed, 2008-03-05 at 16:10 -0500, Jeremy Moles wrote: >> > I've attached a screenshot of some text rendered in a very standard way >> > using osgText: >> > >> > text->setFont(std::string("fonts/monospace.ttf")); >> > text->setCharacterSize(size); >> > text->setFontResolution(size, size); >> > text->setText(label); >> > text->setColor(osg::Vec4(1.0f, 1.0f, 1.0f, 1.0f)); >> > >> > In the screenshot, a the very bottom, you'll see a bit of text called >> > "label 6 (copy)". Take a close look at the following characters: >> > >> > a, e, 6, ( >> > >> > ...and you'll notice that the glyphs are 1 (perhaps 2) pixels "chopped" >> > off at the left. >> > >> > I've been hunting this down forever--in fact, I've made a lot of similar >> > posts in the past--but I simply cannot prevent this occurrence in a >> > predictable way. If I play with the font sizes I can sometimes achieve >> > nearly perfect font quality, but it's all guess-work. >> > >> > So I've decided to go back to square one and ask the mailing lists: can >> > anyone with any heavy osgText experience give me any hints as to what is >> > going on? I've tried all of the KERNING options (though this is a >> > monospace font), I've tried hacking Text/TextBase.cpp so that each Glyph >> > absolutely is "pixel aligned", I've tried all manner of different >> > fonts--but nothing seems to give predictable rendering results. My >> > suspicion is that the GlyphQuads object's _texcoords values are getting >> > calculated slightly wrong in some cases, but I'm not sure. >> > >> > Having precise font quality in osgWidget will be really important, so >> > I'm willing to make any code changes necessary to facilitate this... >> > _______________________________________________ >> > osg-users mailing list >> > osg-users@lists.openscenegraph.org >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org