We were running into issues occasionally in osgEarth where multiple threads were writing out files like /1/2/3.jpg and /1/3/4.jpg. Both threads would try to create the /1 directory and only one of them would succeed. So the first thread would write out the full /1/2/3.jpg while the second thread wouldn't create the /1/3 directory b/c /1 was already created and the writing of /1/3/4.jpg would fail.
"
a few modifications to these files:
- applications/present3D/Cluster.cpp
- src/osgDB/FileUtils.cpp
The changes are needed to fix a few platform specific things such as the
absence of stat64, int/socklen_t differences, etc... and are in the same
line as Linux, Apple and FreeBSD specific checks.
I have attached the modified files; the original patches to 3.0.1 are
also visible here if you find it more convenient:
http://dl.wolfpond.org/dports/graphics.osg/dragonfly/patch-applications_present3D_Cluster.cpphttp://dl.wolfpond.org/dports/graphics.osg/dragonfly/patch-src_osgDB_FileUtils.cpp
With these changes, osg 3.0.1 is able to be built and packaged on DragonFly
whereas it previously failed to compile."
* support for NPOT-textures on IOS
* support for FBOs (only renderToTexture for now) on IOS (should work
for other OpenGL ES 1/2 targets, too)
* FileUtils-support for IOS"
I have added the missing call to FreeLibrary in osgDB::FileUtils., and now my the runtime unload of MY dll is working properly. It has also cured some related problems I was having with memory leak checks being reported.
I have attached a fix to osgDB/FileUtils.cpp based on version 2.9.5 svn revision 10374
"
Introduced a new FindFileCallback to Registry to compliement the existing ReadFileCallback and WriteFileCallback.
Added support for assign Find, Read and WriteFileCallbacks to osdDB::Options to enable plugins/applications to override the callbacks just for that
read/write call and any nested file operations
"the latest SVN revision cannot be build under Windows if ?OSG_USE_UTF8_FILENAME? config option is enabled. The error occurs in ?FileUtils.cpp? file, line 663, since there is no UNICODE-capable version of the ?GetProcAddress? function. The ?OSGDB_WINDOWS_FUNCT_STRING? makro is defined as follows in that case
#define OSGDB_WINDOWS_FUNCT_STRING(x) L ## #x L"W"
Thus the second parameter cannot be converted from wchar_t to LPCSTR. Should we convert the second parameter from wchar_t* to LPCSTR or use the same definition for the ?OSGDB_WINDOWS_FUNCT_STRING? makro in both cases?
The second error occurs in the same file, line 669. The second parameter for the ?pGetModuleHandleEx? function should be defined as wchar_t, but it?s defined as ?static char static_variable? in the line 667."
osgDB/FileUtils.cpp:
Needed this extra code to allow a true case-insensitive search. This is because the HL2 map and model files are often sloppy with case. For example, the file might look for materials/models/alyx/alyx_sheet.vtf, but the file is actually in materials/Models/Alyx/alyx_sheet.vtf. In case-insensitive mode, the new code recursively disassembles the path and checks each path element without regard to case. In case-sensitive mode, the code behaves exactly as it used to. The new code is also mostly skipped on Windows because of the case-insensitive file system. Previously, I did all of this with custom search code in the .bsp plugin, but this allows the user to tailor the search using OSGFILEPATH. There are some instructions in the plugins' README files about this.
osgPlugins/mdl:
This is a new plug-in for Half-Life 2 models (as opposed to maps). This allows you to load Source models individually, as well as allowing the .bsp plugin to load models (props) that are embedded into maps. Mdl files can contain simple object (crates, barrels, bottles), as well as fully articulated characters with skeletal animations. Currently, it can load the simple objects. It can also load the characters, but it can't load the skeletons or animations.
osgPlugins/bsp:
This contains all of the changes needed to load props along with the basic map geometry. There are also
several bugs fixed.
osgPlugins/vtf:
This is the loader for Valve's texture format. Previously, we had agreed to put this in with the bsp plugin, but I didn't think of the .mdl plugin at that time. It's conceivable that a user might want to load models individually (not as part of a map), so the vtf reader does have to be separate. I also fixed a rather significant bug.
I tested all of this code on RHEL 5.2 (32-bit), and Fedora 9 (64-bit). I'll be testing on Windows soon.
I also attached a simple .mdl file, along with it's associated files and textures. Just extract the tarball into it's own directory, set your OSGFILEPATH to point at that directory, and load the model like this:
osgviewer models/props_junk/gascan001a.mdl"
filesystem is case-sensitive. Here are the modifications needed to make
the compiler happy. These are only some include lines rewritten (Io.h to
io.h, Windows.h to windows.h etc.) for version 2.3.7."
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.
"
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.
Tweaks by Robert Osfield - Moved methods to FileNameUtils, added unix
implementation of getRealPath add extern and OSGDB_EXPORT to function declarations.
"My patch is a slight refactoring of the mac specific code in
Registry.cpp and FileUtils.cpp, specifically around the library and
resource file path initilialization methods. This patch cleans up a
lot of the mac specific code by moving repeated code into separate
local functions in FileUtils.cpp that are only compiled on mac builds.
It also adds one function to the API,
appendPlatformSpecificResourceFilePaths in FileUtils. This function
will mirror the already existing
appendPlatformSpecificLibraryFilePaths except for resource file paths.
Currently this function is empty except when built on the mac, in
which case it will add the application bundle's internal Resources
folder and the bundle's parent folder. Previously this code was
implemented as a separate mac specific #ifdef block in Registry.cpp
around the initDataFilePathList method. However, it now is implemented
in appendPlatformSpecificResourceFilePaths in FileUtils.cpp and the
initDataFilePathList method is now the same on all platforms. This
patch should behave the same as before on non-mac platforms.
This patch already includes the fix that Eric mentioned earlier. This
patch is based off of the 0.99 release code. I have tested this patch
using the following testing scheme:
Make a proper bundled application.
While Run from the Finder:
Test that it finds plugins in its internal plugins path.
Test that it finds resources in its internal resources path.
Test that it finds resources in the bundle's parent directory
Test that it finds plugins in the user's Application Support Directory
Test that it finds plugins in the system's Application Support Directory
Test that it finds plugins in the Network Application Support Directory
Check the plugin and resource path lists after they have been
initialized to see if they are in the correct order
While Run from the command line (both from it's parent directory and
from inside the /Contents/MacOS directory) and repeat the above tests.
Check that it also finds plugins and resources within the paths
defined by various environment variables.
Now, Make an application that is NOT bundled/command line only
Test that it does NOT try to look in an internal bundle
plugin/resource directory for plugins or resources.
Test that it finds plugins/resources in the paths defined by the
environment variables.
"
