creating subclasses of osg::Array that referenced data
stored an application's internal data structures. I took
a stab at implementing that and ran into a couple of
downcasts in Geometry.cpp. Enclosed is my take at fixing
those along with a simple example of how to do this."
in the DatabasePager. The practical effects of these are to greatly reduce startup time
and the time to load an individual scenery tile in FlightGear.
- From my log message:
Minimize the number of StateSets and drawables that are compiled by checking
if they have already been compiled or will be elminated by the
SharedStateManager.
Move the sorting of the dataToCompile queue out of compileGLObjects
into the man pager run function.
Change the SharedStateManager to use maps instead of vectors."
- Get or set the target number of PagedLOD children to remove per frame.
- Get or set the minimum number of inactive PagedLOD to keep.
Corresponding environment variables have been added too.
The default values reproduce the previous DatabasePager behavior."
"" for all platforms except Cygwin where its set to "cygwin_" and Mingw where
it is set to "mingw_". Updated osgDB::Registry to look for these for the plugins.
Updated the osgintrospection example to search for these names as well.
src/osgDB/FileUtils.cpp to implement the official Windows DLL search
order as described on the page
http://msdn2.microsoft.com/en-us/library/ms682586.aspx . As mentioned,
the search order is now:
1. The directory from which the application loaded.
2. The system directory. (C:\Windows\System32 by default, gotten using the
GetSystemDirectory function)
3. The 16-bit system directory. (C:\Windows\System by default, gotten by
adding "\System" to the path gotten in the next step...)
4. The Windows directory. (C:\Windows by default, gotten using the
GetWindowsDirectory function)
5. The current directory. (".")
6. The directories that are listed in the PATH environment variable. (as
before)
The first four directories are obtained using Win32 API calls, so they
should work correctly even on non-standard Windows installs.
The changes are well commented and should be clear, even to someone
not familiar with the Win32 API.
I have tested in a few scenarios and it works as expected. Serge Lages
has also tested the changes and confirmed they worked as described. I
have not had any other reports though (positive or negative).
I also fixed the issue with a trailing semicolon on the PATH adding an
empty string to the end of the search paths, as this was an
inconsistent side effect rather than a desirable effect. This change
will take effect on other platforms as well, but since it tests for an
empty string in the last item added to the search paths, it should
have no adverse effect.
"
Created a new GraphicsThread subclass from OperationThread which allows the
GraphicsContext specific calls to be moved out of the base OperationThread class.
Updated the rest of the OSG to respect these changes.
Added and cleaned up DeleteHandler calls in osgViewer to help avoid crashes on exit.
Changed DatabasePager across to dynamically checcking osg::getCompileContext(..)
Updated wrappers.
according to the OpenSceneGraph/CMakeLists.txt and the include/osg/Version settings.
These changes mean that the 1.9.5 release will have a libs/osgPlugins-1.9.5 directory.
"By repurpose, I'm creating a new plugin that uses much of the .osg fileformat,
but with some changes. Specifically, I'm creating a ".osgfs" plugin, which
represents the scenegraph hierarchy as a filesystem of nested subdirectories and
individual files for each node, rather than nested braces with everything in a
single monolithic file. I intend to incorporate file alteration monitor events
to watch the filesystem for modifications and automatically reload.
The problem I'm running into is osgDB is too tightly coupled to the .osg format.
osgDB::Output::writeObject() contains literal .osg format-specific strings like
"{" to represent the Object hierarchy at too low a semantic level. I propose
using virtual methods; my plugin can then derive from osgDB::Output and
represent Object hiearchy differently.
"
~~~~~~~~~~~~~~~~~~~~~~~~~
This is a simple change to permit databases other than those named
"*.osga" to be used. It is hardcoded in read() at present.
It is non-critical and does not affect existing program functionality.
Registry and Registry.cpp
~~~~~~~~~~~~~~~~~~~~~~~~~
Added a new typedef: typedef std::vector< std::string>
ArchiveExtensionList;
a list of extensions: ArchiveExtensionList _archiveExtList;
and an "add" method: addArchiveExtension(const std::string ext)
This is initialised by adding "osga" in Registry() and used in
Registry::read() where the list is searched for the extension used.
Archive.cpp
~~~~~~~~~~~
This submission is a little more tentative. openArchive() is modified to
automatically add the filename extension to the Registry extension list.
"
so I' ve set up a macro that uses the variable name expanded for linking, and test if a variable ${LINK_VAR_NAME}_DEBUG
like OPENTHREADS_LIBRARY_DEBUG exists and in case uses it for linking in debug mode.
I' ve also set up FindOpenThreads to set up these variables.
I had to edit the core libraries CMakeLists to add the calls to the macros used.
I' ve tested under MSVC"
To set up extension aliases using a config file, an app calls:
osgDB::Registry::instance()->readPluginAliasConfigurationFile(), passing in the file name as the parameter. (Of course this should be done before loading any files whose names depend on the mapping.) osgDB will search for the file using OSG_FILE_PATH.
The file should contain a line for each mapping, with the "map" extension first, followed by a space or tab, then the plugin identifier. For example, a file containing this line:
flt OpenFlight
would map the ".flt" extension to the OpenFlight plugin."
Tweaks by Robert Osfield - Moved methods to FileNameUtils, added unix
implementation of getRealPath add extern and OSGDB_EXPORT to function declarations.
default Registry Options object, but it would be useful to be able to
request loading with a different Options object. The attached files
allow you to do that (based off the OSG 1.2 source).
For example, I'm implementing a loader that requires context information
when it pages in subgraphs, which becomes significantly complicated when
multiple scenegraphs are requesting subgraph loads with different
contexts (the loader needs to know which context to use, and the
Registry Options needs to be carefully managed so the context settings
don't clobber each other, especially in multithreaded situations). Being
able to pass an Options instance along with the Node request resolves
this problem."
Fixed bug osgDB::Registry::Registry::read(const ReadFunctor& readFunctor) relating to
the handling of failed loads with the ReadResult::_message value being lost, this changes
ensure that the original ReadResult from the plugin, with message intact, is returned correctly.
the user can override existing alias'. The change allowed for circular
references, so the createLibraryNameForExtension would get caught in
an endless loop. The following fix will catch circular references."
