absolute filenames for the texture images.
The attached change should fix this by at first looking at the absolute file
name to load a texture and then, if that fails, strip away any paths to try
that again with the bare file name.
The change also fixes a possible exception that could be triggered by an out
of bounds std::string access which is now avoided by using functions from
osgDB/FileUtils.
The change is based on rev 11161."
The semantic change that went into the ac loader with the past patch was
incorrect wrt the document describing the behaviour of ac files and
inconsistent with what ac3d itself displays for that files.
This attached change reverts the behaviour to the original one. The
infrastructure to change this is left in place.
The change is based on rev 9045."
Attached is a change that is able to provide shared textures for the clamp and
the repeat case.
So this appears to be the best fix I guess ...
Also it additionaly shares the TexEnv StateAttribute in a whole ac3d model."
"texture" paths. This is to drop absolute paths that some
3d editors export (even AC3D itself!). But this also strips
directories of relative paths, which is wrong and contradicts
the ac3d reference implementation. (The reference implementation
doesn't strip anything, though, and so takes the absolute paths
as they are. Definitely not what we want.)
The attached solution checks absolute paths and only strips
those:
(1) A:\\foo\\bar.png -> bar.png (as before)
(2) /foo/bar.png -> bar.png (as before)
(3) foo/bar.png -> foo/bar.png (new)
(4) ../foo/bar.png -> ../foo/bar.png (new)
"
completed the new registration of the plugin-readerwriters
("REGISTER_OSGPLUGIN") according to your osgstaticviewer-example (see
attachment, based on today's svn)."
