a way that when CMAKE_INSTALL_PREFIX contains something along the lines
of
/usr/x86_64-linux-gnu/
it gets substituted as
/usr/x86_64-1-gnu/
that is, the string is preprocessed again, thereby making changes to
anything that matches any defined symbol, as "linux" in this example
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763816).
Quoting that path directly in CMake scripts solves that problem.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14522 16af8721-9629-0410-8352-f15c8da7e697
The problem is that the readObjectFields method will add the object to the _identifierMap. So all the other instances of that image in the same file will be replaced by the created dummy object. In my fix this was an dummy image and I didn't notice it in our scene's, probably because it covered a small part of an object. In your fix the dummy object was not an image and that leads to a crash when something tries to use it as an image. I have attached a small fix for this bug.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14471 16af8721-9629-0410-8352-f15c8da7e697
databasePager->setUpThreads(16, 1);
We experienced problems with multiple databasepagers loading files in parallel, when two threads start to load the same file (usually a texture referenced by multiple models). The second thread to add the file to the cache (sometimes) manages to do so while the refcount from the cached object still is zero, causing the object loaded to be destroyed.
Sometimes the second thread manages to ref() the object before Referenced::signalObserversAndDelete does the final recount check, causing a warning:
"Warning Referenced::signalObserversAndDelete(,,) doing delete with _refCount=1"
With a deleted object added to the scenegraph we get some undesired results, I think the program only crashes if the object was a Node, and just has some untextured surfaces if it was a texture, but I'm not completely sure.
Attached is a modified version of the Registry.cpp, returning the object in cache and let the duplicate loaded object to be destroyed.
A more efficient option would be to add some sort of blocking entry to the objectcache to stop the second thread from reading the file, and just wait until the first thread added it to the cache. If you think that's worthwile we would be happy to implement that version. A bit tricky to implement and test, that's why I submit a simple version that stops my program from crashing."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14300 16af8721-9629-0410-8352-f15c8da7e697
debug message it prints out on the console.
Around line 1040 of Registry.cpp (see code below) the method returns
"simpleFileName" but prints about returning "filename".
In attachment the modified file, based on osg 3.2.0
ricky
<code>
if(fileExists(simpleFileName))
{
OSG_DEBUG << "FindFileInPath(" << filename << "): returning " <<
filename << std::endl;
return simpleFileName;
}
</code>
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14285 16af8721-9629-0410-8352-f15c8da7e697
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.
"
Updated lua plugin to use new osgDB::PropertyInterface to run methods.
Added addChild/removeChild() etc to Group.cpp, and addDrawable/removeDrawable() etc. to Geode.cpp serializers.
* osgDB::FileUtils uses now the Cocoa-API to determine the paths of the application-support-folder
* DarwinUtils uses now modern functions of the quartz-api to get and set screen-resolutions. Removed some of the osg-deprecated stuff.
"
I'm not sure if the IVE was simply generated incorrectly, or if the Image::getTotalSizeInBytesIncludingMipmaps() was modified since the file was generated. Either way, I added a simple check in the IVE loader so that it clears the mipmap offsets if the actual data size does not match the computed data size. This seems like a safe fallback since the mipmap data can be automatically generated, and it fixes the problem in my case.
Also, while looking into this issue, I noticed that the osgDB::InputStream class applies the serialized image allocation mode. However, since the serializer is allocating the image data itself, it seems like it should force the allocation mode to USE_NEW_DELETE.
"
the wrappers it contains. The registration creates a prototype
object for all of the wrapped classes. For some of the higher-level
classes this can be a bit heavy.
I noticed a problem with a model which required a single class from
osgSim. When osgdb_serializers_osgsim.so was loaded it registered
wrappers and created prototype objects for all of the osgSim classes,
including osgSim::ScalarBar. The constructor for that class creates
several drawables, and loads arial.ttf using the freetype plugin. I
don't need that, and don't even ship the font or plugin with my
application, resulting in an unexplained warning message loading
the model.
I've modified the ObjectWrapper class to defer the prototype object
creation until if & when actually required."
I've also checked the modified files still build ok with other
compilers (Linux gcc, Windows Visual Studio).
osgDB/OutputStream.cpp and osgPlugins/lws/SceneLoader.cpp require
stdlib.h for atoi use.
In osg/Uniform.cpp the compiler complains that base_class is unknown
unless I add a class name qualifier.
Not a build fix, but I spotted a typo in osgUtil/SceneView."
Provided are lua, python and V8 (for javascript) plugins that just open up enough of a link to the respective libs to run a script, there is no scene graph <-> script communication in current implementation.
