OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

Support for loading cubemap images in DDS files


 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> Submission
View previous topic :: View next topic  
Author Message
Farshid Lashkari
Guest





PostPosted: Wed May 09, 2018 5:56 pm    Post subject:
Support for loading cubemap images in DDS files
Reply with quote

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

------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11910

PostPosted: Fri May 11, 2018 8:40 am    Post subject:
Support for loading cubemap images in DDS files
Reply with quote

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 <> wrote:
Quote:
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





------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
donvito
Newbie


Joined: 23 Jun 2011
Posts: 11

PostPosted: Fri May 11, 2018 10:26 am    Post subject:
Support for loading cubemap images in DDS files
Reply with quote

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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

_______________________________________________
osg-submissions mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11910

PostPosted: Fri May 11, 2018 1:23 pm    Post subject:
Support for loading cubemap images in DDS files
Reply with quote

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 <> wrote:
Quote:
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 <>
wrote:
Quote:

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 <> wrote:
Quote:
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











------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
donvito
Newbie


Joined: 23 Jun 2011
Posts: 11

PostPosted: Fri May 11, 2018 2:50 pm    Post subject:
Support for loading cubemap images in DDS files
Reply with quote

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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)>
wrote:
Quote:

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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)

http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

_______________________________________________
osg-submissions mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)

http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org



_______________________________________________
osg-submissions mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

_______________________________________________
osg-submissions mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Farshid Lashkari
Guest





PostPosted: Fri May 11, 2018 3:36 pm    Post subject:
Support for loading cubemap images in DDS files
Reply with quote

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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:

Quote:
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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)>
wrote:
Quote:

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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)

http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

_______________________________________________
osg-submissions mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)

http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org



_______________________________________________
osg-submissions mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

_______________________________________________
osg-submissions mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org




_______________________________________________
osg-submissions mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org


------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11910

PostPosted: Fri May 11, 2018 3:56 pm    Post subject:
Support for loading cubemap images in DDS files
Reply with quote

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 <> wrote:
Quote:
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
<> wrote:
Quote:

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 <>
wrote:
Quote:

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 <>
wrote:
Quote:
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
<>
wrote:
Quote:

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 <> wrote:
Quote:
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



















------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
NEIL HUGHES
Guest





PostPosted: Fri May 11, 2018 8:15 pm    Post subject:
Support for loading cubemap images in DDS files
Reply with quote

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" <>
To: "OpenSceneGraph Submissions" <>
Sent: Friday, 11 May, 2018 9:39:31 AM
Subject: Re: 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.


On 9 May 2018 at 18:56, Farshid Lashkari <> wrote:
Quote:
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






------------------
Post generated by Mail2Forum
Back to top
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> Submission All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts Support for paletted images in dds pl... psi29a Plugins [osgPlugins] 1 Fri Jun 22, 2018 10:14 am View latest post
No new posts error while loading .iv file in opens... Rj@123 General 0 Wed Jun 20, 2018 10:52 am View latest post
No new posts Writing .osg files: how to set colors... eMiliano General 0 Tue Jun 19, 2018 2:02 pm View latest post
No new posts osgDB::readRefNodeFiles() crashes wit... peter_k General 4 Fri Jun 08, 2018 9:18 am View latest post
No new posts CMake can not find include files peter_k Build system [build] 8 Sun Jun 03, 2018 10:51 am View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP