Hi Robert,
After a short study, I found that the default option object can work for my
present situation,
osgDB::Registry::instance()->setOptions(new osgDB::Options("flip_dds"));
And reading and writing calls can benifit from it until the global option is
set back to default. So I don't think my previous suggestion that adds a
setGlobalOption() is worthy of implementing at once.
I'm not sure if a global PluginStringData is required for storing settings
of ALL plugins. It may cause confusing when the PluginStringData
interface can be used to record something like map["dds"]="flip_dds=true" in
the global field, and map["flip_dds"] = "true" for specified plugin. I
personally think current inheritance is enough in most cases right now. :-)
But it is still interesting to discuss about configuring plugin settings.
The PluginStringData mechanism is good for handling all kinds of options
and referenced values, but most plugins still make heavy use of
getOptionString() and have to parse parameters from a long sentence like
"key1=value1 key2=value2". I wonder if we could have the whole option string
automatcailly parsed into 'key and value' map? Plugins can read them then
with getPluginStringData() while reading/writing objects, for example:
In the user level:
readNodeFile(somefile, new osgDB::Options("max_num=1000
texture_path=somepath enable_light"));
In the osgDB::Options constructor, we can output the string to the data map
for use:
setPluginStringData("max_num", "1000");
setPluginStringData("texture_path", "somepath");
setPluginStringData("enable_light", "true");
Will it a little convenient for development?
Wang Rui
2010/10/19 Robert Osfield <[email protected]>
> Hi Wang Rui,
>
> Having a more formal ReaderWriter option control would be a good
> thing, the current osgDB::Option::OptionString usage is rather
> overstretched and inflexible. The already exists the
> Options::PluginStringData which is newer and more flexible but not
> used extensively, making more use of this for this type of control
> would be sensible.
>
> Inheritance of settings is something that is something that would need
> to be handled, we already have a default osgDB::Options object in
> osgDB::Registry. Could one also have an optional Options object
> defined per ReaderWriter? Which would take precedence? If we are
> using the PluginStringData might it be enough just to stick with the
> Registry::Options object?
>
> Perhaps as a simple step we could put options for the "dds" plugin
> into PluginStringData fields as "dds" i.e.
> osgDB::Options::setPluginStringData("dds","flip_dds=true") or better
> simplified
> osgDB::Options::setPluginStringData("dds","flip")
>
> Thoughts?
> Robert.
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
