[osg-users] osgWidget Remaining Issues

Jeremy Moles jeremy at emperorlinux.com
Mon Jul 14 13:45:16 PDT 2008


As you've probably noticed, osgWidget development has been extremely
stagnant of late. This is somewhat due to my lack of personal time, but
in large part is due to a small number of remaining hurdles that I do
not have a good solution to. Robert has sent me a few e-mails, and I've
been encouraged to bring these issues up here for discussion. Hopefully,
with the next release pending, we can work out solutions for these--even
if they don't make it into the next release. :)

My MAIN concerns at the moment are font-related. It's unfortunate that
you have someone like me writing this NodeKit, because a different
person probably wouldn't care as much. However, I am an absolute font
crackhead, and I will settle for nothing less than the very best font
quality possible using OSS. The following are some of the things I'm
encountering with osgText as it exists in SVN; any and all input is
welcome.



1. [ Font Clarity ]
----------------------------------------------------------------------
	
Getting crisp, consistent, arbitrarily-sized 2D fonts using osgText is
proving very difficult. I have posted many times in the past on this,
and have had varying amounts of success using the responses given.
However, to this date, I cannot get a version of OSG--patched or
otherwise--that will provide the font quality I'm used to seeing. I
really wish I could give more info, or more in-depth technical details,
but unfortunately my knowledge of the subject doesn't allow me to
describe my observations any more intelligently. Robert accepted my
"osgfont" example into SVN, so I would encourage anyone curious to take
a look at that and run it with an invocation such as the following:

	# osgfont fonts/arial.ttf 10 11 12 13 14 15

You'll notice that at some sizes and locations, the text appears crisp
and sharp. You'll also notice that at other places the text is blurry
and smudged. Why this occurs I can't be sure, but I'll need to be able
to identify those situations in which it does so that I can avoid them.



2. [ Low-level Font API ]
----------------------------------------------------------------------

In order to create a proper Input widget, I will need a low-level API
for interfacing with the individual text "elements" (glyphs, characters,
or whatever you refer to them as). At the minimum I will need a way to
access the individual width, height, and baseline offset. I'm not quite
sure how best to accomplish this, nor will I claim to be capable enough
to hack osgText's current implementation and add it myself. However,
there's no way I can personally conceive of to create an "editable"
osgText object without knowing exactly what (preferrably integer)
coordinates a particular glyph occurs at. Again, I care only about
working with pixel-aligned 2D text.



3. [ 3D Widgets ]
----------------------------------------------------------------------

osgWidget has been designed from day one to be a HUD; in fact, it was
originally named osgHUD to make this point clear. :) The entire API has
been designed under this assumption, but it would behoove me to at least
address the issue of a 3D widget. I'm not even entirely sure what this
will or should entail, to be quite honest. I make extensive use of
GL_SCISSOR and assume 2D coordinates only when performing picking. At
any rate, the initial release of osgWidget won't support this, but I'd
like to get some discussion going as to it's importance and possible
implementations.



-----------------------------------------------------------------------



That's it for now, but I'd like to say a few things in summary.

I've been playing a lot of World of Warcraft lately and I've spent a
great deal of time playing with their UI modding API--which exposes
itself via a slightly modified embedded Lua interpreter in the WOW
client. They have a few clever ideas to be sure, but in general I'm not
really all that impressed. Given the popularity of WOW, I'm assuming
that 2D interface "solutions" for games aren't something that there is a
a superbly solid solution for, so I'm not that discouraged at some of my
own idiosyncrasies in osgWidget. :) This doesn't really mean much to
you guys, I'm sure, but it does help put some perspective on the issue.

Secondly, I've been playing with the Pango library (which abstracts
FreeType, ATSUI, and Win32) for rendering and aligning text. I'm getting
some really great results, but introducing this into osgWidget would
mean introducing the Pango dependency chain (Pango, Cairo, and glib). Is
this an option worth exploring?




More information about the osg-users mailing list