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 <[email protected]>
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 <[email protected]>
> 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 <[email protected]>
>> 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 <
>> [email protected]>
>> > 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 <[email protected]> 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
>> >> > [email protected]
>> >> >
>> >> >
>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>> >> >
>> >> _______________________________________________
>> >> osg-submissions mailing list
>> >> [email protected]
>> >>
>> >>
>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>> >
>> >
>> >
>> > _______________________________________________
>> > osg-submissions mailing list
>> > [email protected]
>> >
>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>> >
>> _______________________________________________
>> osg-submissions mailing list
>> [email protected]
>>
>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>>
>
> _______________________________________________
> osg-submissions mailing list
> [email protected]
>
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

Reply via email to