to make is easier to write code that can work on DrawElementUByte, UShort or UInt.
Changed the osgTerrain::GeometryTechnique so that it automatically chooses
the use of DrawElementUShort or DrawElementsUInt accordining to the size of the tile.
Because there already exists the option to convert slow path geometry to the fast path by computing an internal fast path alternative, I added a new optimizer option that automatically does this. To check the results I also made some changes to the statistics gathering and rendering.
Somewhat unrelated, but also part of the optimizer I disabled removal of CameraView nodes during RemoveRedundantNodes optimization.
As discussed on the ML, CameraViews were removed from the scenegraph. This solves that issue.
Summary:
-Geometry::areFastPathsUsed now also looks at internalOptimizedGeometry
-Added Optimize option to make all slow path geometry compute their internal fast path alternative
-Added fast geometry counter to the statistics
-Disabled removel of CameraViews in optimizer
"
circumstances under which this bug occur are rather specific, but the
basic problem occurs when one translation unit other than libosg.so
constructs an object that is a subclass of osg::Shape and another
translation unit other than libosg.so tries to perform a dynamic_cast or
other RTTI-based operation on that object. Under these circumstances,
the RTTI operation will fail. In my case, the translation units involved
were an application and osgdb_ive.so. The application constructed a
scene graph that included instantiations of subclasses of osg::Shape.
Depending on how the user ran the application, it would write the scene
graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast
operations in DataOutputStream::writeShape() would fail on the first
subclass of osg::Shape that was encountered. This is because there were
two different RTTI data objects for all osg::Shape subclasses being
compared: one in the application and one in osgdb_ive.so.
The fix for this is simple. We must ensure that at least one member
function of each of the subclasses of the polymorphic type osg::Shape is
compiled into libosg.so so that there is exactly one RTTI object for
that type in libosg.so. Then, all code linking against libosg.so will
use that single RTTI object. The following message from a list archive
sort of explains the issue and the solution:
http://aspn.activestate.com/ASPN/Mail/Message/1688156
While the posting has to do with Boost.Python, the problem applies to
C++ libraries in general."
The fix was to convert the osg::State to use C pointers for the set of applied PerContexProgram objects, and use the osg::Oberver mechanism to avoid dangling pointers for being maintained in osg::State.
methods
getProjectionMatrixAsOrtho()
getProjectionMatrixAsFrustum()
getProjectionMatrixAsPerspective()
getViewMatrixAsLookAt() (2x)
are now const, as they only call const methods of osg::Matrixf/d.
"
returns true if (the extension string is supported or GL version is greater than or equal to a specified version) and
non extension disable is used. This makes it possible to disable extensions that are now
available as parts of the core OpenGL spec.
Updated Texture.cpp is use this method.
/** Convinience method that sets the update callback of the node if it doesn't exist, or nest it into the existing one. */
void addUpdateCallback(NodeCallback* nc);
/** Convinience method that removes a given callback from a node, even if that callback is nested. There is no error return in case the given callback is not found. */
void removeUpdateCallback(NodeCallback* nc);
... and the same for Event and Cull callbacks methods."
--------------------------------------------
Descripton:
The patch does provide a new class PixelDataBufferObject which is capable of allocating memory on the GPU side (PBO memory) of arbitrary size. The memory can then further be used to be enabled into read mode (GL_PIXEL_UNPACK_BUFFER_ARB) or in write mode (GL_PIXEL_PACK_BUFFER_ARB). Enabling the buffer into write mode will force the driver to write data from bounded textures into that buffer (i.e. glGetTexImage). Using buffer in read mode give you the possibility to read data from the buffer into a texture with e.g. glTexSubImage or other instuctions. Hence no data is copied over the CPU (host memory), all the operations are done in the GPU memory.
--------------------------------------------
Compatibility:
The new class require the unbindBuffer method from the base class BufferObject to be virtual, which shouldn't break any functionality of already existing classes. Except of this the new class is fully orthogonal to existing one, hence can be safely added into already existing osg system.
--------------------------------------------
Testing:
The new class was tested in the current svn version of osgPPU. I am using the new class to copy data from textures into the PBO and hence provide them to CUDA kernels. Also reading the results back from CUDA is implemented using the provided patch. The given patch gives a possibility of easy interoperability between CUDA and osg (osgPPU ;) )
--------------------------------------------
I think in general it is a better way to derive the PixelBufferObject class from PixelDataBufferObject, since the second one is a generalization of the first one. However this could break the current functionality, hence I haven't implemented it in such a way. However I would push that on a stack of wished osg 3.x features, since this will reflect the OpenGL PBO functionality through the classes better.
"
* When used PDS RenderStage::runCameraSetUp sets flag that FBO has already stencil,depth buffer attached. Prevents adding next depth buffer.
* Sets correct traits for p-buffer if used PDS and something goes wrong with FBO setup or p-buffer is used directly.
* Adds warning to camera if user add depth/stencil already attached through PDS.
* Sets blitMask when use blit to resolve buffer.
There is also new example with using multisampled FBO."
I have not reverted added Compiler options. I assume that one may want to have warnings enabled for the application but may not want to see them while OSG libraries and examples compile.
Modified files:
osg/Export - now explicitly includes osg/Config to make sure OSG_DISABLE_MSVC_WARNINGS is read
osg/Config.in - declares OSG_DISABLE_MSVC_WARNINGS flag to be added to autogenerated osg/Config
CMakeLists.txt - declares OSG_DISABLE_MSVC_WARNINGS as option with default ON setting
"
facilitate the subclassing of Image providing interactive behaviours so as
used in the vnc interactive VncImage class.
osgViewer::InteractiveImageHandler provides an event handler that convertes osgGA
mouse and keyboard events into the coordinate frame of an image based on ray intersection with geometry in
the associated subgraph.
Changed the ordering of events processing in Viewer and CompositeViewer to allow
scene graph event handlers to take precidence over viewer event handlers and camera manipulators
To facilitate this possibility I have added a template copy constructor and a template assignment operator. These work for safe conversions like those in my previous example, but fail as desired for non-safe conversions since the template instantiation fails during the raw pointer copy/assignment.
The lack of this facility has appreciably handicapped development of generic algorithms applied to the scene graph, and I believe that this alteration will be welcomed by most of the community. If there are issues with antiquated compilers not supporting template member functions then perhaps a small piece of conditional compilation is in order.
I have made the change using the latest release version (2.6) as the base. The full file is attached.
I have not tested building the osg wrappers and the script binding code. I have tested the legal and illegal conversions of both copying and assignment to ensure that behave as expected on MSVC7.1, MSVC8, MSVC9, GCC 4.3."
