On Nov 1, 2011, at 7:01 PM, Carsten Neumann wrote: > Hello Patrick, > > On 11/01/2011 06:03 PM, Patrick Hartling wrote: >> 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? > > if you mean, "will it still work this way" then yes, perhaps with some > small adjustments. > >> 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. > > Someone please correct me if I get the history wrong here, but I think > the revamped text support mentioned in the Contrib/FTGLText readme is > actually what is in OpenSG today. > >> 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. > > what does custom glyph rendering mean in this context? Do you want to be > able to render glyphs that are not part of a font? Apologies if this is > a term with a specific meaning in "FTGL speech", I don't know that lib > very well.
Our current need is to be able to apply borders to the glyphs in order to improve readability. I haven't been able to figure out how to do that with OSG::TextTXFFace, but I may not have looked at the code thoroughly enough. Borders are our starting point, and we may need to manipulate the glyphs further in the future. >> * 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. > > AFAIK you can just feed a UTF-8 string to the OpenSG font functions and > as long as there are appropriate glyphs in the font it will work. I > don't think there is any fallback atm, but that would be an interesting > addition. That was my understanding as well, but I have not been able to make it work. I can only get code points in the range 0x20 to 0x7E (ASCII) to render correctly. One thing that I have run up against is that I cannot determine what encoding is produced by utf8Char2Unicode() in Source/System/Text/OSGTextFace.cpp. It looks like it might be UTF-16, but that would mean that this implementation does not support code points beyond 0xFFFF. It can't be treated as UTF-32 on Windows because wchar_t is only 16 bits wide on that platform. This makes it very difficult to know how to interact with the various text-related objects except through the use of UTF-8. Perhaps I am just spoiled because I have gotten used to ICU4C dealing with encoding details in our code. That said, the FTGL demo program was able to display whatever I threw at it with no special effort, and that was a big selling point for me. >> * 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. > > with the current text code you should need only have on TextTXTFace > object per font (meaning one texture) and can have arbitrary amounts of > text generated from it. So, I'm not sure what causes you to be concerned > about memory usage with the existing text implementation, can you give > more details? I meant that what we do must be at least as efficient as what OSG::TextTXFFace provides now. > I'm not sure if anyone strongly cares for anything other than texture > mapped text these days. > A really nice addition would be to support something like > <http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf> > > which from the images in the paper would improve the looks of magnified > text quite a bit. I can take a look at that. Anything that will improve readability is of interest to me. On that note, another thing that FTGL supports is kerning. >> 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. > > Hmm, I'm not sure I've fully understood where you are expecting large > obstacles in making OpenSG's text support do what you want. I hope that my answers above have clarified things. > As far as > FTGL is concerned I'm somewhat indifferent about it, a downside is that > is manages its own OpenGL state so is somewhat doing it's own thing > besides OpenSG. Then again I don't know it well and it may have features > that easily compensate for this? I see that as a downside as well. I don't yet know just how much of a problem that will be. -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
