to optimize away duplicate state with dynamic, static and unspecified DataVarience. By default
the code now optimizes away duplicate state with either static and unspecied state, previously
it was just handling static state.
MemoryBarrier() is used in the implementation, so it should be checked.
This in effect disables the faster atomic ops on msvc 7.1 and older, even if
only the MemoryBarrier() call is missing. But it ensures for the fist cut
that it will build everywhere. If somebody cares for msvc 7.1 enough and has
one for testing installed, he might provide the apropriate defines to guard
that MemoryBarrier() call.
I tested that msvc8 32/64bit still passes the configure tests and compiles.
"
1) The "highest res" child is assumed to be the child with index "getNumFileNames()-1" or "getNumChildren()-1". As a result, PagedLODs that do not sort children from furthest to nearest will intersect with the wrong child. (see attached "case1.osg" to reproduce this problem.)
2) The code assumes there is only one highest res child. As a result. PagedLODs with multiple children at the same highest res range can only intersect one of those children. ("case2.osg" demonstrates this issue; you can only pick the quad on the right.)
I've attached a modified IntersectionVisitor.cpp that attempts to resolve these issues. It identifies a highest res range based on the range mode, then continues traversal on all valid children corresponding to that range description. Only in the case of a malformed PagedLOD does the code fall back to getting the last child in the list.
"
implementation of the atomic increment and decrement into a implementation
file.
This way inlining and compiler optimization can no longer happen for these
implementations, but it fixes compilation on win32 msvc targets. I expect
that this is still faster than with with mutexes.
Also the i386 gcc target gets atomic operations with this patch. By using an
implementation file we can guarantee that we have the right compiler flags
available."
atomic related compile failures with msvs2005. Attached changes to make win32
really use the atomic stuff. There are pointer typecast problems and some
historic alignment restrictions that I just took from a previous similar
implementation of mine without looking deep enough. "
I needed a -DCMAKE_DEBUG_POSTFIX="d" not a -D"CMAKE_DEBUG_POSTFIX=d".
This corrects the build for the CMake 2.4 and 2.6 series
The error was in compiling osgDB/Registry.cpp
"
- Added osgviewerCocoa example to APPLE builds
- Fixed corrupt Xcode project generation with CMake 2.6 dealing with ADD_DEFINITIONS and CMake Policy CMP0005 on Leopard
- Resolved CMP0006 warning for examples and programs by setting BUNDLE DESTINATION to same as RUNTIME DESTINATION with CMake 2.6
- Fixed freetype plugin on Leopard to avoid OpenGL linking problem
- Figured out how to use a custom Info.plist included in the project (see osgviewerCocoa application CMakeLists.txt)"
From Robert Osfield, made a range of changes to Terry's visitor integrating it into osgUtil::Optimizer and
changing the code to use a style more like the rest of the OSG.
"I have taken the liberty of updating a few files so that there is no longer any derivation from std::vector. I have done this by adding a new file osg/MixinVector and by updating only two others: osg/PrimitiveSet and osg/Array. You will notice that this actually removes what is acknowledged as a \u2018hack\u2019 in osg/PrimitiveSet.
With the original code I did manage to find memory leaks with some compiler options on VC 8 and 9, as well as Intel compiler. I determined the leak existence by instrumenting the destructor code, and by use of a garbage collector as a leak detector (in a similar manner to the Firefox project). Hence in contrast to what I said originally, it is exhibiting symptoms on at least some platforms.
Since I am trying to be a good OSG citizen I got out my editor and started hacking! I have built and tested on Linux (Ubuntu) with GCC 4.x and Windows VC 8 SP1. It appears that nothing is broken, and that I\u2019m using less memory J"
