Hi Sherman,

On 2/4/07, sherman wilcox <[EMAIL PROTECTED]> wrote:
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.

Yes this is the problem with going lightweight, once you add all the
features you want you end... back where you started.

Unless you use a different tack to the actual implementation.  Perhaps
osgText::Text itself could be slimed down a bit without changing its
functionality.  Once you have an implementation its actually easier to
come back and write a better implementation.

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.

Well this is how the scene graph should be... nice and scalable, its
just unfortunate that osgText is not quite a scalable as text.

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?

Its certainly possible.  One downside is that with my recent work on
adding stats to the osgViewer::Viewer I found that the updating of
text labels on each frame was taking a surprising amount of time -
about 1/3rd a millisecond per text label.  This is enough to effect
measured frame rates.

I'd like to use osgText to render my text but I obviously can't use one
osgText object per label.

Indeed, as things stand its not viable with the number of labels you have.

I wonder if refectoring osgText so that the text set up could
implement in class separate from osgText::Text and make it possible to
reuse this is different text implementations - i.e give it the text
parameters and string you want and have it fill in details like
vertex/tex coords arrays and primitives to draw, perhaps even just do
this on the fly if required.

Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to