Just a note, The osgText::String uses ints rather shorts for each
character, I did this so that we could map any character sets beyond even unicode two byte format.
Noted.
The memory load is indeed way overboard. osgText hasn't so far been an issue, and its design and evolution has focused at all on keep memory overhead down to enable 100's of thousands of labels. For your own purposes all the fancy feature probably don't mean much, and could probably get away with a much lighter weight osgText::Text implementation.
Actually, there are a lot of features in osgText::Text that I find appealing. In fact, I'd like to use osgText::FadeText in the future. I'd like to re-use a single osgText::Text object. More on that below.
I think the cleanest approach would be to have a more lightweight osgText text implementation - you really shouldn't have to go round jumping through hoops trying to do what you are doing. Would such a text implementation compliment the exiting implementation? Have a base text class then a text + fancy features subclass from it? One of the most effective ways of reducing the overhead would be to dynamically compute all the character quads on the fly. This would be slower to render, but probably fast enough for most purposes. It'd be interesting to see just what throughput you could achieve. If you only have say a couple of hundred text labels on screen at any one time things might work just fine. Another element to reducing the load would be sharing the text options, rather than have each osgText::Text have all its own settings. Such a new class obviously takes some coding to implement. The actual rendering part would be easy - its just a set of quads with tex coords into one or more texture atlas', the positioning of the quads requires support for kerning.
I thought about implementing my own lightweight version of osgText::Text, but the more I considered it the more I realized I'd probably end up re-inventing osgText::Text. There's a lot of functionality of osgText::Text that I'd like to preserve. I think if I go the lightweight text class route I will end up right where I'm at now. I did a quick test this afternoon. I modified my simple quadtree class to store GL_POINT primitives instead of osgText::Text for a label. Memory usage was negligable and performance was outstanding. Admittedly storing/rendering basic points instead of osgText::Text objects isn't quite comparing apples to apples, but it was encouraging to see all those points pop into view on cue as I hopped around the planet. What I'd like to do is use a single osgText::Text object when I need to render a given label. I may have 150,000+ labels in memory, but I don't believe there will be more than a few dozen (< 100) on screen at any moment. I'm wondering if I can insert one proxy for each label into the scenegraph. This proxy object would be hold the bare essentials information wise. Perhaps positional information for culling, etc. and that would be all. When one of these proxy objects are not culled (most will be), render an osgText::Text object @ runtime. Sort of like the osgteapot example only instead of rendering raw OpenGL code, render an osgText::Text object. Does this make sense? Possible? Advisable? I'd like to use osgText to render my text but I obviously can't use one osgText object per label.
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
