Discussion:
[osg-submissions] Support for loading cubemap images in DDS files
Farshid Lashkari
2018-05-11 15:34:43 UTC
Permalink
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
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
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.
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
{
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();
virtual ~ImageCubeMap() { deallocateData(); }
ImageCubeMap& operator = (const ImageCubeMap&) { return *this; }
std::vector<osg::ref_ptr<osg::Image> > mOtherFaces;
};
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 <
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.
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
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
NEIL HUGHES
2018-05-11 20:14:09 UTC
Permalink
Hi Robert,
Sorry to bother you but could you remove my details from your mailing list please? I have tried but I still seem to be getting them.

Thanks

Neil Hughes.

----- Original Message -----
From: "Robert Osfield" <***@gmail.com>
To: "OpenSceneGraph Submissions" <osg-***@lists.openscenegraph.org>
Sent: Friday, 11 May, 2018 9:39:31 AM
Subject: Re: [osg-submissions] Support for loading cubemap images in DDS files

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.
Post by Farshid Lashkari
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
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
Robert Osfield
2018-05-11 15:55:12 UTC
Permalink
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.
Post by Farshid Lashkari
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
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
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.
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
{
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();
virtual ~ImageCubeMap() { deallocateData(); }
ImageCubeMap& operator = (const ImageCubeMap&) { return *this; }
std::vector<osg::ref_ptr<osg::Image> > mOtherFaces;
};
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
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.
Post by Farshid Lashkari
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
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
Loading...