Hey guys, I'm bumping this as I posted it over a holiday weekend and it may have fell through the cracks. I'm also about to submit the first rough draft of osgText::TextNode.
It will build standalone, but you'll need to replace Style/Style.cpp in your real OSG trunk first with the files from the "patches" directory. So, I don't expect many people to do this (quite yet). :) What I'm really looking for are ideas on how to continue doing drop shadow and outline in 2D text. osgPango does this by rasterizing two textures and then multitexturing... I was trying to think of way to do it just GLSL, but I can't quite come up with anything. On Fri, 2011-07-01 at 13:19 -0400, Jeremy Moles wrote: > Hello all! In just a few days (I will finish the code over the holidays) > I'm going to be submitting a bit of code to Robert to evaluate for > inclusion into OSG proper. It is a continuation of his experimentation > with a new text interface called TextNode. > > TextNode diverges a great deal from what you might be used to with Text > and Text3D objects, but in the end the transition (if Robert accepts > it :)) will be worth it. The API has been cleaned up, internal data is > much easier to get at, and the rendering and layout backends have become > pluggable. > > Before I finish up the last bits so that a first beta version can be > submitted and people can begin experimenting with it, I'd like to > solicit some input. > > 1) I'm dropping all support for the FFP. I mean, c'mon. It makes the > code substantially harder to maintain and understand. If this causes the > code to be rejected (or perhaps results in Text and Text3D staying > around for a bit longer to support FFP), then so be it. :) In lieu of > this, however, I'd like some opinions on which version of GLSL I should > target and how well that version is currently supported by OSG. > > 2) TextNode (3D) glyph support is working quite well; it wasn't hard, > since most of the code was already there in the backend. Each glyph is > cached based on its Style and Font, put into a PAT, and then finally all > of the text is squished into a top-level MatrixTransform. I continue to > use the setAlignment() and setAxisAlignment() API, but obviously you're > free to do whatever you like. How does this sound to everyone? > > 3) TextNode (2D) is still going to require a bit of work at the time of > the first submission. In the new API, osg::Geometry objects are > constructed using quads textured with the 2D glyphs and, again, packaged > into a top-level MatrixTransform. A remaining (serious) question is how > to do drop-shadows and outlines? > > 4) As some of you may know, I am also the author of osgCairo and > osgPango. Both of these nodekits came to be as I was working on > osgWidget, which--combined with getting sick--seriously sidetracked that > project. :) (I haven't forgot about osgWidget though--hang in there!) > This isn't an attempt to plug that software, but rather me posing a > question I've asked before: > > 4.a) The 2D quality provided by osgPango simply cannot be > matched by anything any of us could do by hand. This is > partly due to osgPango's massive user base and its main > developers, but it is also due to the fact that the Glyph > rasterizer is Cairo. Now, I won't be so bold as to ask OSG > to accept osgPango (yet :)), but what I would like to do is > provide a way for Cairo to do the glyph rasterization instead of > doing it manually with Freetype. This is the approach osgPango > takes, and it lets osgPango provide a very powerful glyph > "effect" API. Let me elaborate below... > > In current 2D OSG, you request a string of text. Each > character is iterated over and the backend calls FT_Load_Char > to render each glyph at a particular resolution, at which > point that glyph is put into a texture atlas to be reused > later. > > If we supported Cairo as a rasterizing backend, we would instead > be given the glyph information for each character as a vector > path and would have the freedom to do whatever Cairo's drawing > API allows with it. In the most basic case, this would be a > simple fill() operation, but as you can see from the osgPango > screenshots: http://www.jeremymoles.com/osgPango , a lot of > interesting things can be done when you have a vectorized > path of a glyph. :) > > Don't misunderstand me though: osgPango isn't going anywhere! The layout > support alone provided by osgPango is incredible, and it is able to > provide additional information to the rasterizer for higher quality > fonts (it also supports more than just Freetype; Atsui and the Windows > font backend, for example). It also understands just about every > language and locale out there, so text is always positioned properly. > But I would like to at least like to pose the idea of using Cairo as the > rasterizer, or at least providing a plugin (since it is the freetype > plugin in the osgPlugins directory that actually is responsible for > building the glyph atlas) to do this. > > ----------------------------------------------------------------------- > > I TRULY feel like if we can get this UI stuff under control (which is > why I started working on osgWidget, osgCairo, osgPango) we can > absolutely establish OSG as the premiere OpenGL toolkit. Hopefully I can > make enough strides in this area in my freetime so that one day I can do > it FULL TIME for a living. :) If anyone is familiar with Scaleform (and > if you've played any games made in the last 5 years, you can't have > missed it), something of that visual quality and style is what I > envision for OSG one day (minus the Flash absurdity)... > > > _______________________________________________ > 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
