Hi Sherman, Comments interspersed below.
On 2/4/07, sherman wilcox <[EMAIL PROTECTED]> wrote:
About a week ago I posted a couple of questions relating to the display of city names on an earth model is OSG. While I was working on the problems I posed in that thread, I discovered a new problem: my approach to displaying city names doesn't scale very well. I'm hoping someone here can offer me some suggestions as to how best to approach this problem. Here's some background info: - there are a total of 158,526 labels
As point of reference, when I first developed osgText I had the goal of 10's of thousands of text labels being an reasonable upper bound. So you pushing things by an order of magnitude.
- all labels have a total character count of 1,731,844 characters not counting zero termination - another note: these labels are unicode (UTF-16), each character will consume 2 bytes - each label has the following data associated with it: --latitude (float) --longitude (float) --show range (double) --cut off range (double) If my math is correct then each label should consume about 48 bytes on average. All the labels (stored in unicode UTF-16) and associated data should consume about 8MB.
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.
My current method (the one that doesn't scale well) consists of a quadtree (about 4 levels deep) using a LOD to hold all the geodes. Each geode holds all the labels (labels are stored as osgText::Text objects) in a given node in the quadtree that have the same show and cutoff range. There are two main problems with this method: memory usage and performance. The memory usage is enormous. For these approximately 150,000 labels the memory usage is about 500MB (to see what I mean, modify the osgHUD example and add 100,000 text objects, each holding a single character.) The performance isn't terrible, mainly the update traversal lags on occasion. Someone told me that performance issues might be related to the high memory load. Either way, I'm most concerned with the memory usage at this point.
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.
I'm not quite sure why the memory numbers are so high. A simple sizeof(osgText::Text) reveals that each osgText::Text object consumes about 544 bytes all by itself. 150,000+ osgText::Text objects would consume about 100MB all by themselves. That's more than I can afford just for text. Enough background, here's my question: what's the best way to approach this? Simple enough huh? :) I've written these types of apps before. First time I've used OSG to do something like this. If I was writing straight C++/OpenGL code I would know what to do, I've done it before. But this, using OSG, I'm not sure which direction to go. I ***think*** I need to store each label in a stripped down custom object to conserve memory. The question then becomes how to handle culling and rendering of the text @ runtime. I'm convinced (could be wrong here) that I can't store these labels as osgText::Text objects. Too much memory is consumed. Is it possible to re-use a single osgText::Text object? I'd like to take advantage of the facilities provided by OSG as much as possible. I'm left wondering how else to do this? How can I draw these text labels @ runtime without storing each label in the scenegraph as an osgText::Text object? I want to take advantage of the features that osgText::Text offers like auto rotation to screen, etc. I also need to adjust the altitude of a displayed label @ runtime so it doesn't sink and become obscured by the terrain. What to do?
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. Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
