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
