Robert Osfield wrote:
> Hi Guys,
>
> I'm just reviewing Andreas latest changes and still am stuck just
> accepting the change, in particular the first one where it adds
> in.forward(4) in front of many accessors. This change suggests that
> the OSG's attr plugin has been badly broken since its inception for
> all .attr files, and will have been reading the wrong value for the
> majority of attributes being read from a .attr file. Is this really
> true? If so why has no one picked up on this before? It seems odd
> that something could have been so badly broken for so long without
> users complaining.
>
Currently, very little ATTR data is actually used. It seems that most
of the attr parameters after that extra read are not used anywhere
else. The one that is used (intFormat, which sets the internal format
of the image) probably defaults to doing nothing in most cases (line 401
in PaletteRecords.cpp), and ends up using the image's default internal
format.
> What problems would one expect to see without this fix, and what
> results should I expect with it? Is there any tests fails available
> that reproduce this problem?
>
The only possible problem would only show up if someone relies on the
internal texture format for some reason.
My guess would be that if you merge this fix, nothing will happen in
most cases (the results will only change if a file is explicitly setting
an internal format).
However, the fix it will be necessary if any of the extended attributes
are used in the future. For example, the old OpenFlight loader emulated
SGI detail textures. We would need the ATTR reader working properly if
we were to implement that in the new loader.
--
--"J"
"I'm a castaway stranded in a desolate land,
I can see the footprints in the virtual sand."
--Neil Peart
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
