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
> > [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
>
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
