[osg-users] Detecting when a texture is to big for graphics memory

Werner.Modenbach at texion.eu Werner.Modenbach at texion.eu
Wed Nov 30 11:28:30 PST 2016

Hi Allister,
I have a comparable situation  in my software. Displaying huge textures.
I got help from the list recently and now it works like a charm.
I split the texture in small tiles and assign them to textured quads. The quads are arranged to form a huge plane. The trick is arranging them in a PagedLOD Structure as a quad tree. Always 4 tiles create a tile of the same size in the next distance level with lower resolution. The tiles are loaded dynamically on whatever distance they appear. This way the total load of textures is not so high and manageable by the hardware.
Send me a private mail if you need more details. 

On 30. November 2016 15:42:17 MEZ, Alistair Baxter <alistair at mve.com> wrote:
>Our application is using osgVolume to render 3D texture data that is
>provided by users. This means the data can be very large, and can
>exceed the amount of available graphics memory on some machines.
>I was looking for a way to detect whether a texture has failed to load
>in this way, so that we can alert the user, or react to the problem in
>some other way. But I'm having trouble finding anything in code that
>will help.
>OpenSceneGraph responds with   "Warning: detected OpenGL error 'out of
>memory' at after RenderBin::draw(..)"   but I'm not seeing anything in
>the scene graph data that can indicate that the texture in question is
>at fault. The TextureObject representing the 3D texture, for example
>declares that it is allocated, and reports the correct size and a
>positive id.
>Is there any way to tell whether a texture is too big for graphics
>memory, other than by just knowing how much there is in total  (a
>feature that only seems to work for me on NVidia hardware anyway) and
>checking whether the known size of your texture will fit?
>osg-users mailing list
>osg-users at lists.openscenegraph.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20161130/a823168e/attachment-0003.htm>

More information about the osg-users mailing list