I do have the ability to pre-process. The question is, what file formats support openGL compression and how do I take them from jpeg to these formats? As for mipmapping, you mentioned that it can be done CPU side. How do I initiate this? Since the texture load is happening in a separate thread, I can afford CPU time to do this rather than pushing more on to the GPU. I can test out to see if it is worthwhile.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Robert Osfield Sent: Friday, August 24, 2012 11:40 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Hi Karl, On 24 August 2012 14:40, Cary, Karl A. <[email protected]> wrote: > I have an application that loads several 2048x2048 textures in a > separate thread before passing off to the main to be applied to the > geometry. I am trying to do anything and everything I can to improve > performance on them as the number of textures will increase from > several to quite a lot. So I am looking at every option I can and have > run in to several questions that I was hoping to get some advice on. I > am creating osg::Texture2D and loading them with an osg::Image read in from a jpg file. Excatly how many textures are you talking about? Will of the texture reside in memory and be rendered at the same time? Do you have an flexibility w.r.t pre-processing the image data into other file formats? What pixel format do the textures have? RGB? > 1) Is mipmapping enabled by default? Or do I need to call > allocateMipmapLevels? By default the osg::Texture* will use trilinear mipmapping, if the osg::Image doesn't contain the mipmaps then it'll either generate them on demand in the rendering thread either done by the GL driver or GPU using OpenGL extensions for generating mipmaps, or on the CPU using GLU functions when the driver doesn't support the generate mipmap extensions. You can switch the mipmapping off by just setting the texture->setFilter(Texture::MIN_FILTER, Texture::LINEAR); > 2) If it is enabled, how many levels are created by default? osg::Texture* will automatically work out how many levels are required based on the dimensions of the texture. > 3) Would changing the internal format mode to one of the compression > formats actually perform the compression or does that need to be done > manually? If the source imagery is not in an OpenGL compressed format then the driver will do the compression for you, however this is an expensive operation so generally not one you'd during rendering, rather OpenGL compression is something you'd want to do in pre-processing step. > > 4) If I do need to do the compression, how can I do it without applying > it to geometry in my separate thread? I have only seen it done via the > CompressTexturesVisitor applied to a node (as in osgconv), would I > have to make some empty node and apply the texture to it to do this? To compress in a background thread you can use the OSG's now support for compressing textures using NVTT (there is plugin for this when you compile the OSG when the NVTT SDK is available). You'll need OSG-3.x for this. > 5) Is there any way to send a texture down to the graphics card prior > to applying it to geometry? You can pre-compile objects using the IncrementalCompileOperator, however, this is still done as part of the rendering thread so depending upon your requirements might not make a difference. > 6) Any other efficiency things I should be looking at? Pre-processing data so that it's pre-mipmapped and using OpenGL compressed texture is the best way if you want to maximize performance throughput of textures as this reduces how much work the CPU and GPU need to do to download and use the data. OpenGL compression is less aggressive than compression supported by conventional image formats so the files on disk will be bigger. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
