Hi Neil, The osgViewer by default will compile texture and display lists on the first frame of rendering, but if you add textures later these won't be pre-compiled.
You can only compile texture objects from within a valid graphics context, so you can't just do it a construction time. The only things you can do at construction time is ensure that your source data doesn't need to be resized of mipmaps generated for it, or source data that uses OpenGL texture compression. This all really entails pre-processing of data to be in form that is good for uploading to the graphics card. In the case of non power of two imagery set the resize of non power of two textures will help a lot, but you'll need hardware and drivers that support non power of two textures. Robert. On Thu, Jun 25, 2009 at 12:29 PM, <[email protected]> wrote: > Hi All, > > Is there a way I can get a Texture to perform its preparation at construction > time, rather than when it is first required for rendering? > > Essentially I'm noticing a significant lag on the first frame that requires a > Texture to be rendered. I've tracked it down to the Texture::apply() where it > checks to see if it has a textureobject for the contextID. If it doesn't, > then it goes off and does some work (I presume for sending the texture to the > render pipeline). This is done once per context per Texture. What I would > like to do is to take this hit when first constructing the Texture object, > rather than when flying in space, as it causes a significant lag in frame > rate (the simulation appears to stagger). > > Does anyone have any suggestions please ? > > Many thanks > > Neil. > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
