is based on suggested fix from Marco for fixing a crash due to lack of
thread safety in std::ofstream("/dev/null"); The fix is to use a custom stream
buffer that just discards all data. The implementation is also twice as fast
as the old /dev/null based approach.
calling wglMakeCurrent twice.
This bug has been reported to NVidia, confirmed and fixed by NVidia but awaits verifiaction and release if a driver which fixes this bug.
is an example). This can happen in circumstances that are not
manageable by the OSG itself (e.g. 3rd party buggy program) but one
would expect the plugin to be able to recover by returning
ReadResult::ERROR_IN_READING_FILE.
libpng provides two callbacks for warnings and errors - those are
currently unused. By default, they point to function that call exit()
or something similar (the default error callback never returns). This
patch registers the callbacks using libpng's mechanisms, makes the
warning callback emit an osg::notify(osg::WARN) message and the error
callback throw an error. The reading process is enclosed in a
try...catch block. Upon error, the memory is freed and
ReadResult::ERROR_IN_READING_FILE is returned.
"
osgViewer::GraphicsWindow::setCursor() the new cursor type is recorded
but not applied until windows sends another WM_SETCURSOR message. This
delays the application of the cursor to the next mouse event.
The attached file fixes this by setting the new cursor with a call to
::SetCursor() immediately.
"
nvidia 6 months ago and the issue is still "in progress". I've given up
waiting for them!
Platform - various Intel Windows XP SP2 PCs with various nvidia cards
including GeForce 8800 GTS and Quadro FX 4500, and various driver
versions including the latest WHQL 175.16.
I investigated your concerns about glGenerateMipmapEXT being slower than
GL_GENERATE_MIPMAP_SGIS, and for power-of-two textures, to my surprise
it is. For a 512*512 texture, glGenerateMipmapEXT takes on average 10ms,
while GL_GENERATE_MIPMAP_SGIS takes on average 6ms. Therefore I have
modified the code to only use glGenerateMipmapEXT if the texture has a
non-power-of-two width or height. I am resubmitting all the files
previously submitted (only "Texture.cpp" has significant changes since
my previous submission, I've also replaced tabs with spaces in
"Texture").
"
first post:
"I had the problem that debug and release version of the plugins had the same name under linux. These minors modification to Registry and the CMake support files enable to have both Release and Debug version of the plugins to coexist and be found by there respective runtimes."
follow up post:
"I've gone ahead and added a preprocessor directive with the editable CMAKE_DEBUG_POSTFIX. I modified Registry.cpp to take this new preprocessor directive called OSG_DEBUG_POSTFIX while looking for libraries in Debug mode for the windows (msvc) and the linux platforms.
MinGW, cygwin and Apple are still left out this proposal."
Notes from Robert Osfield, completed the work in change d entries to use OSG_DEBUG_POSTFIX
GL_GENERATE_MIPMAP_SGIS is very slow (over half a second for a 720*576
texture). However, glGenerateMipmapEXT() performs well (16ms for the
same texture), so I have modified the attached files to use
Texture::generateMipmap() if glGenerateMipmapEXT is supported, instead
of enabling & disabling GL_GENERATE_MIPMAP_SGIS."
Notes, from Robert Osfield, I've tested the out of the previous path using
GL_GENERATE_MIPMAP_SGIS and non power of two textures on NVidia 7800GT and
Nvidia linux drivers with the image size 720x576 and only get compile times
of 56ms, so the above half second speed looks to be a driver bug. With
Muchael's changes the cost goes done to less than 5ms, so it's certainly
an effective change, even given that Michael's poor expereiences with
GL_GENERATE_MIP_SGIS do look to be a driver bug.
The first bug is that the terrain tiles will page out to a lower LOD when they are right in front of you. The issue appears to be with the blacklisting heuristic which forces a tile to LOD 1, commenting out the usage of blacklisting with the LOD Nodes fixes our problem. This code change was made to line 29 of TXPPageLOD.cpp.
The second bug we were experiencing is that the database reader options never make it through to the archive loader. The use case for us appeared when the FID codes for the terrain were no longer on the materials. As it turns out the archive was being created twice, once by TXPNode and once by the ReaderWriterTXP on getArchive() so the options never actually got set on the archive that was being loaded. The fix is to first create the archive by calling getArchive on the ReaderWriterTXP, which stores it in a map for reference later, and then passing that archive into the TXPNode for it to set its internal member. With this code change we only create one archive (not sure what creating two did) and our options flags get set properly on the database.
The changes made are in TXPNode.h line 72 where the TXPArchive is now passed in. In the TXPNode.cpp the loadArchive(TXPArchive*) was changed to have the default behavior if NULL is passed in, if an archive is passed in then it does not load it since all the loading is done in the ReaderWriterTXP::getArchive(). The only other place that loadArchive is called is in TXPIO.cpp where a modification was made to pass in NULL which will have the same behavior as it used to. The last change is the little block of code starting on line 57 of ReaderWriterTXP.cpp, this was changed so that it first calls getArchive() which caches the archives in a map does some loading stuff and returns a pointer to it which is then passed in as a parameter to TXPNode::loadArchive().
The performance changes were made to TXPParser.cpp line 163 where we use to osgUtil::Optimizer on the node before passing it off, and on line 1456 we changed the geometry to use display lists. These small changes actually made drastic performance increases for us, as much as 1000% on certain laptops.
As far as testing goes, we have tested these changes with at least 5 txp databases on a variety of different computers including Mac OS and Linux. The base version used is 2.4."
The reason is if you want to build an application that use a library that use openscenegraph you have to build the full chain in debug or in release.
On windows you have no choice, but on linux you can link with both version without rebuilding everything ...
The patch consist only to change the line on one line
SET(CMAKE_DEBUG_POSTFIX "d")
with
SET(CMAKE_DEBUG_POSTFIX "d" CACHE STRING "add a postfix, usually d on windows")"
now holds the dirty flag and enables/disables event traversal in response dirty
being set/unset. This allows terrain to be automatically updated in response
to Terrain scale and sample ratio changes.
osg::ref_ptr<osg::Node> ReaderWriterVRML2::convertFromVRML(openvrml::node *obj)
The fixes are:
* Added the source's parent directory as search directory for image files.
* The material properties are now set in the stateset of the Geode rather than the Geometry. This will allow geometries to be reused with different material properties in future updates.
NB: I planned for a caching scheme in which multiple occurences of the same primitive (e.g., Cylinders with radius 0.8 and height 1.2), would use the same Geometry object. Unfortunately, my planning moved me to other areas, but I might still finish the caching scheme in a quiet hour. For the time being I decided it would be a good thing to already submit my current changes.
"
Cause: possibly a copy/paste typo in src/osgPlugins/osg/LineStipple.cc, line 61:
if (fr[0].matchWord("functionMask") && fr[1].getUInt(mask))
Solution: change to:
if (fr[0].matchWord("pattern") && fr[1].getUInt(mask))"
Finally it seems to not come from the empty geode. The origin of the problem seems to be the uniform initialization during the building of the program which call a glUseProgram.
If your scene never display the node that contains the shader and if there is no other shader on the scene, this "glUseProgram" is the only one that is called during your simulation. So, this shader is applied on all the scene.
I fix this bug by switching off the shader (by calling glUseProgram(0) ) during the compilation of a state which does not contain the shader.
"
Changes includes:
1. A new GifImageStream class (inherit from osg::ImageStream and OpenThreads::Thread) have already been added to implement different operations of a GIF movie, such like playing, pausing, rewinding, setting time and so on.
2. Some small changes to decode_row() and gif_read_stream(), which make the transparency of GIF images correctly.
3. Just a few changes to the ReaderWriterGIF::readGIFStream() function, which ensure that animate GIFs are loaded by GifImageStream (and the function returns GifImageStream objects) and static GIFs unchanged (still use the old method and returns osg::Image objects!).
Attachments are the cpp file and an animate GIF file for further test. Just rebuild the osgdb_gif project and use osgviewer or osgmovie to view it.
The plugin has been tested on Windows and Arch Linux."
"Here is a collection of changes which should fix issues building the OSG with CMake 2.6.0 (along with some other changes)
CMakeLists.txt:
* Set CMP0003 to supress warning about linking against -lpthread (which is a
non-absolute library location). (CMake 2.6.x fix)
* Modified the WIN32_USE_MP and a couple of other Visual Studio specific flags
to be in an IF(MSVC) block (minor tweak to reduce exposing this stuff on MinGW builds)
* Includes my second set of glu tesselator autodetection changes that you
seemed to want but haven't committed yet.
src/OpenThreads/pthreads/CMakeLists.txt:
* Eliminates warning when compiling on Linux about spaces in link line (CMake 2.6.x fix)
CMakeModules/OsgMacroUtils.cmake:
* Tweaks to make the macros behave properly under CMake 2.6.0 (doesn't change behavior under CMake 2.4.x)
CMakeModules/Find3rdPartyDependencies.cmake:
* Adds the NO_DEFAULT_PATH option to all of the search options so that things in C:\Program Files\OpenSceneGraph aren't accidently picked up during configure time and instead only things in the "3rdParty" folder are discovered. (general bugfix)
"
post 2:
"Ok, hold the presses. I just discovered that for some odd reason the osgdb_* plugins under Linux aren't getting put under the osgPlugins-2.5.0 folder. Not exactly sure why this broke, the folder was there, just empty. I'll have to look into it this evening."
post 3:
"Fixed, was caused by the switch to CMAKE_LIBRARY_OUTPUT_DIRECTORY and some code in osgPlugins/CMakeLists.txt that effectively overrides LIBRARY_OUTPUT_PATH on non-MSVC compilers to dump the plugins in the plugins folder. I tweaked it to override CMAKE_LIBRARY_OUTPUT_DIRECTORY as well. Seems to work fine."
