slow rendering of large quantities of text

34 views
Skip to first unread message

Robert Kiser

unread,
Apr 29, 2021, 2:22:13 PM4/29/21
to OpenSceneGraph Users
Hello All

A question about how to improve the performance of rendering a lot of small pieces of text.

For example, I am rendering a point cloud of 5014 points (rendered as small spheres).  On my machine, this takes about 0.86 seconds.  Very acceptable.  But when I add a text object to note the point number (for each of the 5014 points), the runtime shoots up to 26.03 seconds.  That was a bit surprising.

While the initial rendering calculations are slow, once that's done though, manipulating the model (zooming, panning, rotating) works beautifully and is very responsive.

I am running OSG 3.6.5 on a Windows 10 machine using MS VS 2019 (Latest Version) on a 3.6Ghz Intel i9 with 32 Gb of memory and an NVIDIA GeForce GTX 1080 card. 
Font file was: arial.ttf

I've tried several things to speed up the initial calculating process (all to no avail):

1. Using simpler fonts, i.e., simplex.ttf
2. Using other font formats like dosapp.fon  (seemed to ignore that)
3. Rendering in either SCREEN_COORDS and OJBECT_COORDS
4. Turning ON or OFF the option: AutoRotateToScreen
5. Setting data variance to STATIC

Nothing seems to make much noticable difference.

I am wondering if there is some switch I am not setting or some procedure that I am not implementing that would help me out.  (Perhaps a noob goof?)

Failing that, I was wondering if it would be possible to kick off the rendering of the text on a separate thread so that the point cloud could be viewed quickly and the text could become visible later whenever its rendering finished.

Anyone have any idea(s) that I might could try out?

Thanks in advance,

Bob Kiser




Robert Osfield

unread,
Apr 29, 2021, 4:47:49 PM4/29/21
to OpenSceneGraph Users
Hi Bob,

Are you doing your tests with debug or release build of the OSG?

How long are the labels and how what is the range of characters that they labels have?

What properties do you set on the text labels? i.e. autoscale/autorotation etc?

Robert.

Robert Kiser

unread,
Apr 29, 2021, 5:12:06 PM4/29/21
to OpenSceneGraph Users
Thanks for the quick reply!

1. I believe I am using the release build of OSG, in Release|x64 mode.
2. The labels are just numbers, like: "1", "387", or "5014".  (without the quote marks.)  All are unique, corresponding to the number of the point in the point cloud.
3. I have tried it with AutoRotateToScreen both true and false.
4. I did not know there was an AutoScale, so am not using that.
5. I am setting: Color, Font, CharacterSizeMode, Alignment, DataVariance, and Text.  Anything else is defaulted.
6. I am invoking the text object like so:  osgText::Text* pText = new osgText::Text in a function, returning it to the caller as:  osg::ref_ptr<osg::Node>

Does this help any?  Anything else I can do to make the issue clearer?

Thanks in advance for your assistance,

Bob Kiser

Robert Osfield

unread,
Apr 29, 2021, 6:00:30 PM4/29/21
to OpenSceneGraph Users
Hi Bob,

The performance of creating the labels is an oddity, 5000 labels is quite a few but surprised it's taking that long.  I don't have any suggestions as to what is causing things to be so long. 

For the type of task you have a general purpose text class like osgText::Text will not be the most efficient way to implement what you need.  It will be possible to implement it with custom shaders and osg::Geometry and use the osgText::Font to provide the Texture.  You can do a lot of text setup in vertex shader, and even look up glyph coords in the vertex shader and map an index value to all the glyphs required.

The custom approach will be really light weight but it requires more knowledge of shaders and how to set everything up in the scene graph, so it'll be a lot more work.

The most effective use of your time would probably be to profile your application when it's setting up the text, there could be something happening that is cause a big bottleneck.  If it turns out the bottleneck is within the OSG then creating an example that illustrates the bottleneck would be useful as it'll enable others to try it out and provide insight to what could be done differently.

Cheers,
Robert.
Reply all
Reply to author
Forward
0 new messages