Hi Sukender,

On Wed, Dec 16, 2009 at 5:14 PM, Sukender <[email protected]> wrote:
> Yes there may be things to do about those points. I'll wait for your next
> post (after the night ;) )... you'll surely have wiser ideas than mine.

Night past, and I'm afraid I've been pondering and tackling other
tasks... so don't have nice fully formed ideas to blow you away
with...

On the topic of avoiding recursion one thought I did have was in the method:

  void ProxyLoadImageCallback::load(osg::Image & image) const {
  ..
  }

One could just replace the line:

    osg::ref_ptr<osg::Image> loadedImage =
osgDB::readImageFile(filename, localOptions);

With:

    osg::ref_ptr<osg::Image> loadedImage =
osgDB::Registry::instance()->readImageImplementation((filename,
localOptions);

And by doing this we wouldn't invoke any of the callbacks that you'd
otherwise get, so there would be no need to modify Options or the
Registry and thus keep things thread safe.

>> W.r.t 3ds plugin, I don't understand why you say the noTextures
>> options is useless.  Could you please explain.
>
> Well I think disabling the loading of images in each reader is too much job,
> and it adds too much maintenance in case we find a bug. The solution I used
> was the "NoTextureReadFileCallback" (in the file I submitted). It:
> - exactly does the same thing,
> - is valid for all readers,
> - may be replaced by other reader callback (such as for proxy images),
> - and does not require to tweak the OSG source code.
> Thus the "noTexture" option should be replaced by this simple callback.
> Does that sounds right for you? Do you think the NoTextureReadFileCallback
> should be available somewhere in OSG?

OK, I understand now.  I am correct in reading the svn changesets that
the "noTexture" option can in as part of your recent 3ds submission?
I just want to double check that we won't be removing an option that
others are relying upon.

And I do agree the callback is the better way to switch off textures.

As for a place for these callbacks, a header to declare them in osgDB
would be the place.  One could possibly just place them in
include/osgDB/Callbacks, or in a companion
HelperCallbacks/UtilityCallbacks oooo I can't think of a sensible
name.  Perhaps just sticking them in Callbacks would be the easiest
place to stick them...

Robert.

Robert.
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

Reply via email to