Robert,
I agree with your points but I don't like the idea of 2 functions with
the same name, same goal but different code. I would suggest merging
them into one.
I think packing is something trasparent in current OSG and should not
cause problems.
As for the 0 size this is something I overlooked. I think that check for
0 can be added to both Image and DDS plugin without problems. Perhaps
Wojtek can comment on this, as he's the author of DDS plugin version as
far as I remember.
Sorry for late reply, but I'm very busy with non OSG work these days. I
can think of next version with 0 size check but cannot gurantee it will
be ready this week
Best,
Marcin
W dniu 2013-02-13 19:11, Robert Osfield pisze:
Hi Marcin,
I am currently reviewing your changes to Image.cpp and
ReaderWriterDDS.cpp. There a few things that jump out at me as being
a little odd with the changes.
First up is the addition of the slice_packing and image_packing
parameters to the computeImageSizeInBytes(..) method. I realize these
additions exist in the original function embedded in
ReaderWriterDDS.cpp but all the calls invoking the
ComputeImageSizeInBytes() don't set the packing for even the rows, let
alone the slice_packing and image_packing, so it also assumes all the
packing settings are set to 1 in all instances. This means that the
additionally packing parameters and the code associated with them are
entirely redundant. In OpenGL there is only a row packing parameters
so the others are irrelevant and misleading in the context of
osg::Image. I believe the correct osg::Image implementation should
just have the packing parameters supported by OpenGL. If the DDS
plugin supports other forms of packing then this is something will
have to investigate and find some workaround, such as repacking the
loaded data into the appropriate OpenGL friendly form.
The second oddity is that removing of the check of any of the image
dimensions being 0, instead forcing the values less than 1 to be 1,
this will mean that an image with dimensions defined as 0,0,0 won't
have a zero size. An image with any of its dimensions set to 0 is
always invalid and should return an image size of 0, I can't see a
reason to change this. If the dds format has an implicit change a 0
to 1 then this needs to be done in the plugin and not mapped onto the
core OSG.
Thoughts?
Robert.
On 8 February 2013 19:41, <[email protected]> wrote:
Posted again
On Mon, 07 Jan 2013 15:13:59 +0100, Marcin Prus wrote:
Hi Robert,
attached is change for Image::computeImageSizeInBytes (image.zip)
that should fix problem with wrong size computation for rectangular
dxt textures. I replaced the method with the one from
ReaderWriterDDS.cpp that handles block compressions correctly.
If the change is accepted it can be used inside ReaderWriterDDS.cpp
too, instead of internal one. Change attached in dds.zip.
Best Regards,
Marcin Prus
_______________________________________________
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
