HI Roland, On Fri, May 15, 2009 at 4:40 PM, Roland Smeenk <[email protected]> wrote: > I've originally contributed the .dds cubemap loading capability that you > rejected. From that time I've been merging my changes with the latest head. > Cubemaps can still be loaded succesfully, but I agree that it may be better > to split osg::Image into multiple classes for the different osg::Textures > that it feeds. Are you envisioning a separate Image class for each Texture > class?
No, my proposal of an osg::ImageArray class would need to be compatible with all Texture types. Not all would know enough about it to make use of it. My thought was the the osg::Image base classes sizes/type data pointers would be assigned to one of the osg::Image that the ImageArray manages so that a simple Texture2D texture would just select one of them, but a TextureCubeMap could go look for images 0,1,2,3,4,5, etc. > Side note: > Last week I ran into a problem with cubemaps in the osgOcean example which > turned out to be a pixelformat problem. The osgOcean example uses 6 separate > images of which one image has a different pixel format. My osg::Image class > supporting cubemaps has only one pixelformat for all 6 data planes and this > caused a problem when copying the six images into the single cubemap image. In the context of the osg::ImageArray class you'd probably want a function for querying of all the images are compatible, and perhaps a function for making them all the same. Possible texture cube map would also need to be written to cope between with different pixel formats. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
