OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

Identify files in object cache by filename and optional provided options.

Goto page 1, 2  Next
 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> Submission
View previous topic :: View next topic  
Author Message
Ralf Habacker
Guest





PostPosted: Mon May 30, 2016 10:09 am    Post subject:
Identify files in object cache by filename and optional provided options.
Reply with quote

Hi Robert,

the appended file contains a patch fixing an object cache issue, we had
in an application
(http://www.openscenegraph.org/index.php/gallery/use-cases/189-fm-profil)

Objects with the same filename may be different from others based on the
provided plugin options. Using filename *and* the provided options as
object cache key helps to avoid fetching the wrong object.


related commit
https://github.com/rhabacker/osg/commit/b41f6dd905df2a39c97bbde8d9f986572c80f285

Regards
Ralf




------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12264

PostPosted: Tue May 31, 2016 3:51 pm    Post subject:
Identify files in object cache by filename and optional provided options.
Reply with quote

Hi Ralf,

I have just done a first pass review and understand the motivation
behind the change but feel that it's not general purpose enough to be
robust, so while an improvement on the current approach it doesn't
full address the possibility of different Options object mapping to
different loaded models.

I think the right approach would be to use the filename string and
Options object as a key rather than just attempting to reuse the
filename to encode extra information.

To be robust I think one would need to clone the Option object when
creating the key and compare on the contents rather than the pointers.
This would also require a comparison operator to be added to the
Options object.

I feel solving the problem properly is the right way to go, even if it
does mean more parts of the OSG have to be adapted for the task.

Cheers.
Robert.

On 30 May 2016 at 11:00, Ralf Habacker <> wrote:
Quote:
Hi Robert,

the appended file contains a patch fixing an object cache issue, we had
in an application
(http://www.openscenegraph.org/index.php/gallery/use-cases/189-fm-profil)

Objects with the same filename may be different from others based on the
provided plugin options. Using filename *and* the provided options as
object cache key helps to avoid fetching the wrong object.


related commit
https://github.com/rhabacker/osg/commit/b41f6dd905df2a39c97bbde8d9f986572c80f285

Regards
Ralf






------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Ralf Habacker
Guest





PostPosted: Thu Jun 02, 2016 10:25 am    Post subject:
Identify files in object cache by filename and optional provided options.
Reply with quote

Am 31.05.2016 um 17:42 schrieb Robert Osfield:
Quote:
Hi Ralf,

I have just done a first pass review and understand the motivation
behind the change but feel that it's not general purpose enough to be
robust, so while an improvement on the current approach it doesn't
full address the possibility of different Options object mapping to
different loaded models.

I think the right approach would be to use the filename string and
Options object as a key rather than just attempting to reuse the
filename to encode extra information
So you suggest to change addEntryToObjectCache() to

void addEntryToObjectCache(const std::string& filename, osg::Object*
object, double timestamp = 0.0, Options *options = NULL);

and to implement as

void ObjectCache::addEntryToObjectCache(const std::string& filename,
osg::Object* object, double timestamp, Options *options)
{
OpenThreads::ScopedLock<OpenThreads::Mutex> lock(_objectCacheMutex);
if (options)
{
std::string key = filename + options->getContentHash();
_objectCache[key]=ObjectTimeStampPair(object,timestamp);
}
else
_objectCache[filename]=ObjectTimeStampPair(object,timestamp);
}

where Options::getContentHash() is a method to get a unique hash for the
content of the Options instance (may be the string representation of the
Options instance address) ?

and for searching to extend getRefFromObjectCache() to

osg::ref_ptr<osg::Object> getRefFromObjectCache(const std::string&
fileName, const Options *options = NULL);

with an optional options parameter and to implement it as


osg::ref_ptr<osg::Object> ObjectCache::getRefFromObjectCache(const
std::string& fileName, const Options *options)
{
OpenThreads::ScopedLock<OpenThreads::Mutex> lock(_objectCacheMutex);
ObjectCacheMap::iterator itr;
if (options)
itr = _objectCache.find(fileName + options.getContentHash());
else
itr = _objectCache.find(fileName);
if (itr!=_objectCache.end())
{
// OSG_NOTICE<<"Found "<<fileName<<" in ObjectCache
"<<this<<std::endl;
return itr->second.first;
}
else return 0;
}

Ralf



------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12264

PostPosted: Thu Jun 02, 2016 10:37 am    Post subject:
Identify files in object cache by filename and optional provided options.
Reply with quote

Hi Ralf,

I don't think an extra method getContextHash() would be required. I'd
just implement an == operator in Options and then clone the Options
object that is passed into addEntryToObjectCache.

Robert.

On 2 June 2016 at 11:17, Ralf Habacker <> wrote:
Quote:
Am 31.05.2016 um 17:42 schrieb Robert Osfield:
Quote:
Hi Ralf,

I have just done a first pass review and understand the motivation
behind the change but feel that it's not general purpose enough to be
robust, so while an improvement on the current approach it doesn't
full address the possibility of different Options object mapping to
different loaded models.

I think the right approach would be to use the filename string and
Options object as a key rather than just attempting to reuse the
filename to encode extra information
So you suggest to change addEntryToObjectCache() to

void addEntryToObjectCache(const std::string& filename, osg::Object*
object, double timestamp = 0.0, Options *options = NULL);

and to implement as

void ObjectCache::addEntryToObjectCache(const std::string& filename,
osg::Object* object, double timestamp, Options *options)
{
OpenThreads::ScopedLock<OpenThreads::Mutex> lock(_objectCacheMutex);
if (options)
{
std::string key = filename + options->getContentHash();
_objectCache[key]=ObjectTimeStampPair(object,timestamp);
}
else
_objectCache[filename]=ObjectTimeStampPair(object,timestamp);
}

where Options::getContentHash() is a method to get a unique hash for the
content of the Options instance (may be the string representation of the
Options instance address) ?

and for searching to extend getRefFromObjectCache() to

osg::ref_ptr<osg::Object> getRefFromObjectCache(const std::string&
fileName, const Options *options = NULL);

with an optional options parameter and to implement it as


osg::ref_ptr<osg::Object> ObjectCache::getRefFromObjectCache(const
std::string& fileName, const Options *options)
{
OpenThreads::ScopedLock<OpenThreads::Mutex> lock(_objectCacheMutex);
ObjectCacheMap::iterator itr;
if (options)
itr = _objectCache.find(fileName + options.getContentHash());
else
itr = _objectCache.find(fileName);
if (itr!=_objectCache.end())
{
// OSG_NOTICE<<"Found "<<fileName<<" in ObjectCache
"<<this<<std::endl;
return itr->second.first;
}
else return 0;
}

Ralf




------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Ralf Habacker
Guest





PostPosted: Thu Jun 02, 2016 10:56 am    Post subject:
Identify files in object cache by filename and optional provided options.
Reply with quote

Am 02.06.2016 um 12:29 schrieb Robert Osfield:

Hi Robert,
Quote:
I don't think an extra method getContextHash() would be required. I'd
just implement an == operator in Options
to use the == operator on iterating through the cache entries in
getRefFromObjectCache ?

getRefFromObjectCache() uses find() for fetching the key, which requires
a string representation of a unique key for the related Options
instance. On inserting there is also a string key required.

Quote:
and then clone the Options object that is passed into addEntryToObjectCache.
what should I do with the cloned instance, save in the object cache ?

Can you explain ?

Ralf




------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12264

PostPosted: Thu Jun 02, 2016 11:09 am    Post subject:
Identify files in object cache by filename and optional provided options.
Reply with quote

On 2 June 2016 at 11:48, Ralf Habacker <> wrote:
Quote:
Am 02.06.2016 um 12:29 schrieb Robert Osfield:

Hi Robert,
Quote:
I don't think an extra method getContextHash() would be required. I'd
just implement an == operator in Options
to use the == operator on iterating through the cache entries in
getRefFromObjectCache ?

getRefFromObjectCache() uses find() for fetching the key, which requires
a string representation of a unique key for the related Options
instance. On inserting there is also a string key required.

The map inside ObjectCache would need to change from:

typedef std::map<std::string, ObjectTimeStampPair >
ObjectCacheMap;

To something like:

typedef std::pair<std::string, osg::ref_ptr<osgDB::Options>>
FileNameOptionsPair;
typedef std::map<FileNameOptionsPair, ObjectTimeStampPair >
ObjectCacheMap;

We'd need to pass in a less operator for the map as well to test
against contents of the Options object rather than rely upon pointer
comparison.

Quote:

Quote:
and then clone the Options object that is passed into addEntryToObjectCache.
what should I do with the cloned instance, save in the object cache ?

Can you explain ?

One would simply use a osg::clone(options) to generate the options
object to store in the cache, this would insulate the cache from being
invalidated by changes to the original Options object passed in,

Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Ralf Habacker
Guest





PostPosted: Fri Jun 03, 2016 9:38 am    Post subject:
Identify files in object cache by filename and optional provided options.
Reply with quote

Am 02.06.2016 um 13:01 schrieb Robert Osfield:
Quote:
One would simply use a osg::clone(options) to generate the options
object to store in the cache, this would insulate the cache from being
invalidated by changes to the original Options object passed in,
Got it, thanks :-)

I added initial support to class ObjectCache, see
https://github.com/rhabacker/osg/commit/e3539ea0185a4013514850c3577180aaa38c895d

While trying to test the implementation with osgviewer it turns out that
it is not possible to setup a testcase using command line.

I used

osgviewer -O convertToFeed test-file1.flt -O convertToKilometers
test-file2.flt

and got always empty options.


Adding test1.flt with options '' to ObjectCache 0x15fadb0

A quick check shows that in Registry::readCommandLine() all -O options
are read and saved in one Options instance in Registry::_options.

void Registry::readCommandLine(osg::ArgumentParser& arguments)

...
while(arguments.read("-O",value))
{
setOptions(new Options(value));
}

So I thought there may be a change to get options using one file:

osgviewer -O convertToFeed test-file1.flt


but still got

adding test1.flt with options '' to ObjectCache 0x12b9db0

Any idea what's going wrong and how to fix ?

Cheers
Ralf



------------------
Post generated by Mail2Forum
Back to top
Ralf Habacker
Guest





PostPosted: Mon Jun 06, 2016 10:37 am    Post subject:
Identify files in object cache by filename and optional provided options.
Reply with quote

Am 03.06.2016 um 11:30 schrieb Ralf Habacker:
Quote:
Am 02.06.2016 um 13:01 schrieb Robert Osfield:
Quote:
One would simply use a osg::clone(options) to generate the options
object to store in the cache, this would insulate the cache from being
invalidated by changes to the original Options object passed in,
Got it, thanks :-)

I added initial support to class ObjectCache, see
https://github.com/rhabacker/osg/commit/e3539ea0185a4013514850c3577180aaa38c895d

While trying to test the implementation with osgviewer it turns out that
it is not possible to setup a testcase using command line.

I used

osgviewer -O convertToFeed test-file1.flt -O convertToKilometers
test-file2.flt

and got always empty options.


Adding test1.flt with options '' to ObjectCache 0x15fadb0

A quick check shows that in Registry::readCommandLine() all -O options
are read and saved in one Options instance in Registry::_options.

void Registry::readCommandLine(osg::ArgumentParser& arguments)

...
while(arguments.read("-O",value))
{
setOptions(new Options(value));
}

So I thought there may be a change to get options using one file:

osgviewer -O convertToFeed test-file1.flt


but still got

adding test1.flt with options '' to ObjectCache 0x12b9db0

Any idea what's going wrong and how to fix ?
Beside the that the mentioned command line should be

osgviewer -O convertToFeed test.flt

to match to debug output


and an incomplete patch from my side, which is fixed in https://github.com/rhabacker/osg/commit/33aca40d00b8de692bc5858a15f8a53833c7d85c


it looks that there are conflicts in osgviewer command line handling relating to the object cache.


On command line the object cache is enabled with --enable-object-cache, which is handled in osgviewer.cpp:89 ff [2]

// Enable caching?
while (arguments.read("--enable-object-cache"))
{
if (osgDB::Registry::instance()->getOptions()==0) osgDB::Registry::instance()->setOptions(new osgDB::Options());
osgDB::Registry::instance()->getOptions()->setObjectCacheHint(osgDB::Options::CACHE_ALL);
}


Adding -O <options> to command line in frot of a filename is handled in

void Registry::readCommandLine(osg::ArgumentParser& arguments)

...
while(arguments.read("-O",value))
{
setOptions(new Options(value));
}

The problem here is that the newly created option overwrites CACHE_ALL setting from [2].

Second this code only adds the latest -O option and overwrites the previous one, which breaks command line using multiple -O options like

osgviewer -O <options1> file1 -O <option2> <file2>

The appended sequence diagram shows the related calls.

Do you have any advice how to fix this issue(s) ?

Cheers
Ralf





------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12264

PostPosted: Tue Jun 14, 2016 10:09 am    Post subject:
Identify files in object cache by filename and optional provided options.
Reply with quote

Hi Ralf,

I'm just catching up on submissions again after a Coverity squishing
expedition at the end of last week.

I'm currently look at your commit:

https://github.com/rhabacker/osg/commit/33aca40d00b8de692bc5858a15f8a53833c7d85c

Most of the changes look fine to me, the only odd thing is that the
date for the commit on this page is "committed on 15 Jan 2014" rather
than 4th of June it looks like it was pushed to your osg github
repository.

Something odd going on with dates?

--

On the issue about osgviewer not robustly handling -O, the options is
something that has been of add on rather than a full blown
implementation. The command line parsing that osgviewer and the rest
of the example provide is not meant to be a be all and end of command
line parsing. Even osgviewer is really just an example. Given this
I'm not too worried about it not supporting all the combination you
might be able to come up with w.r.t individual O options.

Personally I'd not try to make things too sophisticated, examples are
example not full blown applications. The main issue I see with the
examples not handling complex combinations of option usage is in
testing of the new feature of pairing objects in the cache with
Options. This feature is very specific to your application so far -
perhaps down the line others will start taking advantage of this
extended capability but for now it's not something that will affect
other users.

I believe the code changes in your commit are the best way to hand the
object cache so am happy to merge, but changes to the command line
parsing I'm happy to leave as it is originally, not general purpose
but at least provides a crude means of passing in options.

Robert.

On 6 June 2016 at 11:28, Ralf Habacker <> wrote:
Quote:
Am 03.06.2016 um 11:30 schrieb Ralf Habacker:
Quote:
Am 02.06.2016 um 13:01 schrieb Robert Osfield:
Quote:
One would simply use a osg::clone(options) to generate the options
object to store in the cache, this would insulate the cache from being
invalidated by changes to the original Options object passed in,
Got it, thanks :-)

I added initial support to class ObjectCache, see
https://github.com/rhabacker/osg/commit/e3539ea0185a4013514850c3577180aaa38c895d

While trying to test the implementation with osgviewer it turns out that
it is not possible to setup a testcase using command line.

I used

osgviewer -O convertToFeed test-file1.flt -O convertToKilometers
test-file2.flt

and got always empty options.


Adding test1.flt with options '' to ObjectCache 0x15fadb0

A quick check shows that in Registry::readCommandLine() all -O options
are read and saved in one Options instance in Registry::_options.

void Registry::readCommandLine(osg::ArgumentParser& arguments)

...
while(arguments.read("-O",value))
{
setOptions(new Options(value));
}

So I thought there may be a change to get options using one file:

osgviewer -O convertToFeed test-file1.flt


but still got

adding test1.flt with options '' to ObjectCache 0x12b9db0

Any idea what's going wrong and how to fix ?
Beside the that the mentioned command line should be

osgviewer -O convertToFeed test.flt

to match to debug output


and an incomplete patch from my side, which is fixed in https://github.com/rhabacker/osg/commit/33aca40d00b8de692bc5858a15f8a53833c7d85c


it looks that there are conflicts in osgviewer command line handling relating to the object cache.


On command line the object cache is enabled with --enable-object-cache, which is handled in osgviewer.cpp:89 ff [2]

// Enable caching?
while (arguments.read("--enable-object-cache"))
{
if (osgDB::Registry::instance()->getOptions()==0) osgDB::Registry::instance()->setOptions(new osgDB::Options());
osgDB::Registry::instance()->getOptions()->setObjectCacheHint(osgDB::Options::CACHE_ALL);
}


Adding -O <options> to command line in frot of a filename is handled in

void Registry::readCommandLine(osg::ArgumentParser& arguments)

...
while(arguments.read("-O",value))
{
setOptions(new Options(value));
}

The problem here is that the newly created option overwrites CACHE_ALL setting from [2].

Second this code only adds the latest -O option and overwrites the previous one, which breaks command line using multiple -O options like

osgviewer -O <options1> file1 -O <option2> <file2>

The appended sequence diagram shows the related calls.

Do you have any advice how to fix this issue(s) ?

Cheers
Ralf







------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12264

PostPosted: Tue Jun 14, 2016 11:41 am    Post subject:
Identify files in object cache by filename and optional provided options.
Reply with quote

Hi Ralf,

I have now merged your changes and checked them into git master.

I have spotted an issue though, the FileNameOptionsPair key will do a
pointer comparison on the Options objects rather than comparing
contents. This means that simply using std::pair or not providing a
custom comparison operator to the map won't be sufficient we'll need
to provide a custom comparison operator that dereferences the Option
object.

Thoughts?
Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Ralf Habacker
Guest





PostPosted: Tue Jun 14, 2016 12:58 pm    Post subject:
Identify files in object cache by filename and optional provided options.
Reply with quote

Am 14.06.2016 um 13:33 schrieb Robert Osfield:
Quote:
Hi Ralf,

I have now merged your changes and checked them into git master.

I have spotted an issue though, the FileNameOptionsPair key will do a
pointer comparison on the Options objects rather than comparing
contents. This means that simply using std::pair or not providing a
custom comparison operator to the map won't be sufficient we'll need
to provide a custom comparison operator that dereferences the Option
object.

Thoughts?
I just prepared an additional osgobjectcache example to have a valid
object cache related test environment and stumbled also over this issue.

The initial patch contains already comparing operaters in Options
class, but they are not called :-(

-
+ bool operator < (const Options &rhs) const;
+ bool operator == (const Options &rhs) const;
virtual ~Options() {}


Quote:
From
http://stackoverflow.com/questions/3277172/using-pair-as-key-in-a-map-c-stl
it looks that a operator < for the complete key type is required.


Ralf


------------------
Post generated by Mail2Forum
Back to top
Ralf Habacker
Guest





PostPosted: Tue Jun 14, 2016 1:00 pm    Post subject:
Identify files in object cache by filename and optional provided options.
Reply with quote

Am 14.06.2016 um 12:00 schrieb Robert Osfield:
Quote:
Hi Ralf,

Most of the changes look fine to me, the only odd thing is that the
date for the commit on this page is "committed on 15 Jan 2014" rather
than 4th of June it looks like it was pushed to your osg github
repository.

Something odd going on with dates?
This date came from the time I wrote the initial patch.


Quote:

--

On the issue about osgviewer not robustly handling -O, the options is
something that has been of add on rather than a full blown
implementation. The command line parsing that osgviewer and the rest
of the example provide is not meant to be a be all and end of command
line parsing. Even osgviewer is really just an example. Given this
I'm not too worried about it not supporting all the combination you
might be able to come up with w.r.t individual O options.

Personally I'd not try to make things too sophisticated, examples are
example not full blown applications. The main issue I see with the
examples not handling complex combinations of option usage is in
testing of the new feature of pairing objects in the cache with
Options.
How to test the implementation otherwise ?

Ralf



------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12264

PostPosted: Wed Jun 15, 2016 6:26 pm    Post subject:
Identify files in object cache by filename and optional provided options.
Reply with quote

Hi Ralf,

On 14 June 2016 at 13:52, Ralf Habacker <> wrote:
Quote:
How to test the implementation otherwise ?

A dedicate example is what I'd used, I'm guessing the osgobjectcache
example you are working fits this bill.

Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Ralf Habacker
Guest





PostPosted: Fri Jun 17, 2016 4:20 pm    Post subject:
Identify files in object cache by filename and optional provided options.
Reply with quote

Am 14.06.2016 um 12:00 schrieb Robert Osfield:
Quote:
--
On the issue about osgviewer not robustly handling -O, the options is
something that has been of add on rather than a full blown
implementation. The command line parsing that osgviewer and the rest
of the example provide is not meant to be a be all and end of command
line parsing. Even osgviewer is really just an example. Given this
I'm not too worried about it not supporting all the combination you
might be able to come up with w.r.t individual O options.

Personally I'd not try to make things too sophisticated, examples are
example not full blown applications.
Unfortunally osgviewer is build and installed by all distributions as
default in the opposite to examples from example subdirs, which need to
be enabled on cmake configure time and are packaged separately.
For example opensuse shows:

i | Application:Geo |
OpenSceneGraph
| 3.4.0-15.8 | x86_64
i | Application:Geo |
OpenSceneGraph-examples
| 3.4.0-15.8 | x86_64
i | Application:Geo |
OpenSceneGraph-plugins
| 3.4.0-15.8 | x86_64

xxx@yyy:~/src/openscenegraph> rpm -q -l OpenSceneGraph
/usr/bin/osg2cpp
/usr/bin/osgarchive
/usr/bin/osgconv
/usr/bin/osgfilecache
/usr/bin/osgversion
/usr/bin/osgviewer
/usr/bin/present3D
/usr/share/doc/packages/OpenSceneGraph
/usr/share/doc/packages/OpenSceneGraph/AUTHORS.txt
/usr/share/doc/packages/OpenSceneGraph/ChangeLog
/usr/share/doc/packages/OpenSceneGraph/LICENSE.txt
/usr/share/doc/packages/OpenSceneGraph/NEWS.txt
/usr/share/doc/packages/OpenSceneGraph/README.txt

osgviewer --help prints out the following text for object cache support

--enable-object-cache

Enable caching of objects, images, etc.

Caused by the recent implementation of handling -O this command line
switch is broken and does not work. (The switch is parsed in
Viewer::Viewer(osg::ArgumentParser& arguments) and is overwritten in
osgDB::Registry::readCommandLine().)

Ralf



------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12264

PostPosted: Fri Jun 17, 2016 5:52 pm    Post subject:
Identify files in object cache by filename and optional provided options.
Reply with quote

Hi Ralf,

I am just heading offline as I have a crazy weekend ahead - I'm racing
a 95 mile trail running race, the West Highland Way Race, tomorrow :-)

I'll catch up on Monday.

Robert.

On 17 June 2016 at 17:10, Ralf Habacker <> wrote:
Quote:


Am 14.06.2016 um 12:00 schrieb Robert Osfield:
Quote:
--
On the issue about osgviewer not robustly handling -O, the options is
something that has been of add on rather than a full blown
implementation. The command line parsing that osgviewer and the rest
of the example provide is not meant to be a be all and end of command
line parsing. Even osgviewer is really just an example. Given this
I'm not too worried about it not supporting all the combination you
might be able to come up with w.r.t individual O options.

Personally I'd not try to make things too sophisticated, examples are
example not full blown applications.
Unfortunally osgviewer is build and installed by all distributions as
default in the opposite to examples from example subdirs, which need to
be enabled on cmake configure time and are packaged separately.
For example opensuse shows:

i | Application:Geo |
OpenSceneGraph
| 3.4.0-15.8 | x86_64
i | Application:Geo |
OpenSceneGraph-examples
| 3.4.0-15.8 | x86_64
i | Application:Geo |
OpenSceneGraph-plugins
| 3.4.0-15.8 | x86_64

xxx@yyy:~/src/openscenegraph> rpm -q -l OpenSceneGraph
/usr/bin/osg2cpp
/usr/bin/osgarchive
/usr/bin/osgconv
/usr/bin/osgfilecache
/usr/bin/osgversion
/usr/bin/osgviewer
/usr/bin/present3D
/usr/share/doc/packages/OpenSceneGraph
/usr/share/doc/packages/OpenSceneGraph/AUTHORS.txt
/usr/share/doc/packages/OpenSceneGraph/ChangeLog
/usr/share/doc/packages/OpenSceneGraph/LICENSE.txt
/usr/share/doc/packages/OpenSceneGraph/NEWS.txt
/usr/share/doc/packages/OpenSceneGraph/README.txt

osgviewer --help prints out the following text for object cache support

--enable-object-cache

Enable caching of objects, images, etc.

Caused by the recent implementation of handling -O this command line
switch is broken and does not work. (The switch is parsed in
Viewer::Viewer(osg::ArgumentParser& arguments) and is overwritten in
osgDB::Registry::readCommandLine().)

Ralf




------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> Submission All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts adding object models in osgEarth best... Db80 General 10 Tue Apr 30, 2019 6:12 pm View latest post
No new posts Recent mods to XmlParser giving error... Trajce Nikolov NICK General 0 Wed Apr 17, 2019 11:09 am View latest post
No new posts Make an object linked to camera moove... GiacomoB General 0 Wed Mar 20, 2019 9:45 am View latest post
No new posts Deleting still referenced object RichardHarrison General 59 Tue Jan 08, 2019 12:16 am View latest post
No new posts Scale object based on camera distance Moohasha General 3 Fri Jan 04, 2019 4:57 pm View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP