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