On 07/06/2011 01:32 PM, Christian Buchner wrote:
Hi,
I've just tested our app against OSG 3.0.0, mostly because it has some
rudimentary Multitouch support which I hope to extend on. During the
upgrade we only stumbled across a renamed header file
(MatrixManipulator to CameraManipulator). No big deal - some extra
preprocessor macros in the code fixed that.
My application features some hundred or thousand walking persons
(implemented as animated billboards) that read their texture data from
a DDS file. It seems handling of transparencies has changed though.
Where previously the billboards had a transparent background, the
walking persons now appear in inside solid black squares. So the
entire billboard is opaque.
Would anyone know if there was a breaking change in the DDS plug-in
between OSG 2.8.2 and 3.0.0 regarding transparency handling? Before I
start digging into documentation, maybe someone here knows.
It most likely has to do with this thread:
http://forum.openscenegraph.org/viewtopic.php?t=8168
Briefly, there was some confusion on how DXT1 files with alpha were
detected and handled. My original fix was to assume that all DXT1
blocks with a particular bit pattern were transparent. However, another
(arguably more complete) interpretation is that the bit pattern means
either transparent or black, with the deciding factor being the image
format. This is the behavior that Robert has now implemented. Of
course, the .dds format header doesn't identify the image format
completely, so it's not really possible to distinguish between DXT1a and
DXT1c in a .dds file.
In short, there are a new set of options that will let you alter the
behavior to work with your data. You probably want to use the
dds_dxt1_detect_rgba option.
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
