I have been evaluating the use of FTGL (most likely the SVN trunk version) with
OpenSG 2, and I was wondering if anyone has recommendations for the integration
process. I looked at what OpenSG 1.8 has for FTGL support, and it seems fairly
straightforward. Is that approach still fairly reasonable for OpenSG 2?
While reviewing the 1.8 code, I noticed that there was some hope many years ago
that OpenSG 2 would include revamped support for text display. Did that work
get done, or is there still interest in refining that area of OpenSG? We need
something that I believe requires more flexibility than is currently offered by
the OpenSG text features. I am no expert with text display, but I may be able
to contribute something to OpenSG when my work is complete.
To summarize, my goals for the work that I need to do are as follows:
Support all rendering techniques implemented by FTGL while allowing custom
rendering through user-supplied subclasses of FTGlyph. Custom glyph rendering
is the main thing that we need beyond what seems possible with OpenSG's current
text support.
Full Unicode support using UTF-8 as the input encoding—unless ICU4C or
something equivalent were added as a dependency. I do not want to get into the
mess of wchar_t and std::wstring as that has not worked out well for me in the
past. This will most likely require multi-font support to allow for fallbacks
when a needed glyph is not supplied by the primary font in use.
Provide good performance and scalability. In our use cases, we could very
easily have hundreds or thousands of text billboards, and we need to make
efficient use of texture memory. While I have no plans to limit things to
texture-mapped text, that will be our focus. Nevertheless, FTGL already
implements multiple techniques, and I see no need to apply limitations in that
regard.
Basically, we want to be able make use of what FreeType, FTGL, and OpenSG offer
without being impeded by abstraction layers. That does not necessarily mean
that the API will be harder to use than what OpenSG provides now, but my
conclusion is that we need something new to do what we want.
I don't know yet if this will be too ambitious. If there is an opportunity to
provide an enhancement to OpenSG, I would be happy to do that. Otherwise, if
anyone has tips, I would be equally happy to hear those.
-Patrick
--
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/
The information transmitted in this communication is intended only for
the person or entity to which it is addressed and contains proprietary
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please destroy any copies, contact the sender
and delete the material from any computer.
------------------------------------------------------------------------------
RSA® Conference 2012
Save $700 by Nov 18
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
