HI Farshid, Ooo, returning a TexrureCubeMap might just work well, just call readObjectFile, you could even use the template version to get the cast. I don't recall the API off the top of my head but it'll be something like readFile<TextureCubeMap>(file);
Robert. On 11 May 2018 at 16:34, Farshid Lashkari <fla...@gmail.com> wrote: > Hi Robert, > > I agree it’s not very clean. I just wanted a solution that maintains > compatibility and doesn’t change the ABI. > > If you’re willing to return a different type of object, then why not just > return an osg::TextureCubeMap directly? No need to create an intermediary > object. > > Cheers, > Farshid > > On Fri, May 11, 2018 at 7:49 AM Giuseppe Donvito > <giuseppe.donv...@gmail.com> wrote: >> >> The problem is that osg::Image wraps 3d images in a single buffer, and >> here I think it's useful having at the end different images to easily fill >> afterwards a TextureCubeMap. >> >> Giuseppe >> >> On Fri, May 11, 2018 at 3:22 PM, Robert Osfield <robert.osfi...@gmail.com> >> wrote: >>> >>> Hi Giuseppe, >>> >>> Rather than subclass from osg::Image, perhaps one could just leverage >>> the face that osg::Image supports 3D images, so just store it as a >>> stack of 6 images. >>> >>> Robert. >>> >>> On 11 May 2018 at 11:25, Giuseppe Donvito <giuseppe.donv...@gmail.com> >>> wrote: >>> > What about extend the Image class, creating a storage for all faces >>> > where >>> > the face0 is the Image base implementation? >>> > the DDS reader will instantiate ImageCubeMap if found more than 1 face. >>> > >>> > BR, >>> > Giuseppe >>> > >>> > >>> > /** ImageCubeMap class for encapsulating the storage texture cubemap >>> > image >>> > data. */ >>> > class OSG_EXPORT ImageCubeMap : public Image >>> > { >>> > public: >>> > virtual Object* cloneType() const { return new ImageCubeMap(); } >>> > virtual Object* clone(const CopyOp& copyop) const { return new >>> > ImageCubeMap(*this, copyop); } >>> > virtual osg::ImageCubeMap* asImageCubeMap() { return this; } >>> > virtual const osg::ImageCubeMap* asImageCubeMap() const { return >>> > this; } >>> > >>> > void addFace(osg::Image* image); >>> > std::vector<osg::Image*> getAllFaces(); >>> > >>> > protected: >>> > >>> > virtual ~ImageCubeMap() { deallocateData(); } >>> > ImageCubeMap& operator = (const ImageCubeMap&) { return *this; } >>> > std::vector<osg::ref_ptr<osg::Image> > mOtherFaces; >>> > }; >>> > >>> > in Image class: >>> > >>> > class OSG_EXPORT Image : public BufferData >>> > { >>> > virtual osg::Image* asImage() { return this; } >>> > virtual const osg::Image* asImage() const { return this; } >>> > virtual osg::ImageCubeMap* asImageCubeMap() { return NULL; } >>> > virtual const osg::ImageCubeMap* asImageCubeMap() const { >>> > return >>> > NULL; } >>> > } >>> > >>> > >>> > On Fri, May 11, 2018 at 10:39 AM, Robert Osfield >>> > <robert.osfi...@gmail.com> >>> > wrote: >>> >> >>> >> Hi Farshid, >>> >> >>> >> I've done a first pass review and don't feel comfortable with adding a >>> >> series of images on the back of one. This trick is something you will >>> >> be aware of as the author but I can't imagine many other users being >>> >> able to spot that it's even supported let alone how to use it. >>> >> >>> >> I think the correct approach would be to return back a container for >>> >> all of the images. Ideally osg::ImageList would be a full osg::Object >>> >> so we'd be able to have a ReaderWriterDDS::readObject() method that >>> >> could return an object containing all the images. Perhaps have an >>> >> osg::Images object that subclasses from osg::Object and ImageList. >>> >> >>> >> Thoughts? >>> >> Robert. >>> >> >>> >> >>> >> On 9 May 2018 at 18:56, Farshid Lashkari <fla...@gmail.com> wrote: >>> >> > Hi Robert, >>> >> > >>> >> > I've added an option to the DDS plugin to support loading all >>> >> > cubemap >>> >> > images. The loader accepts an optional data parameter >>> >> > "dds_image_list" >>> >> > that >>> >> > is a pointer to an osg::ImageList. When this is specified and the >>> >> > DDS >>> >> > file >>> >> > contains multiple cubemap images, the loader will add the additional >>> >> > images >>> >> > to the list. This can also be used in the future if someone decides >>> >> > to >>> >> > add >>> >> > 2d image array support to the dds plugin. >>> >> > >>> >> > I also added some meta data to the main image that specifies how >>> >> > many >>> >> > images >>> >> > are in the file and whether it is a cubemap. I also set the default >>> >> > origin >>> >> > to TOP_LEFT. It was previously setting the origin to BOTTOM_LEFT >>> >> > only if >>> >> > the >>> >> > flip option was set, but not to TOP_LEFT when the option was not >>> >> > present. I >>> >> > believe this should now be the correct behavior. >>> >> > >>> >> > Cheers, >>> >> > Farshid >>> >> > >>> >> > _______________________________________________ >>> >> > osg-submissions mailing list >>> >> > osg-submissions@lists.openscenegraph.org >>> >> > >>> >> > >>> >> > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >>> >> > >>> >> _______________________________________________ >>> >> osg-submissions mailing list >>> >> osg-submissions@lists.openscenegraph.org >>> >> >>> >> >>> >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >>> > >>> > >>> > >>> > _______________________________________________ >>> > osg-submissions mailing list >>> > osg-submissions@lists.openscenegraph.org >>> > >>> > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >>> > >>> _______________________________________________ >>> osg-submissions mailing list >>> osg-submissions@lists.openscenegraph.org >>> >>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> >> >> _______________________________________________ >> osg-submissions mailing list >> osg-submissions@lists.openscenegraph.org >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > _______________________________________________ > osg-submissions mailing list > osg-submissions@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > _______________________________________________ osg-submissions mailing list osg-submissions@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org