unsigned int Image::computeNumComponents(GLenum pixelFormat)
so I added these types to the switch statement:
case(GL_RED_INTEGER_EXT): return 1;
case(GL_GREEN_INTEGER_EXT): return 1;
case(GL_BLUE_INTEGER_EXT): return 1;
case(GL_ALPHA_INTEGER_EXT): return 1;
case(GL_RGB_INTEGER_EXT): return 3;
case(GL_RGBA_INTEGER_EXT): return 4;
case(GL_BGR_INTEGER_EXT): return 3;
case(GL_BGRA_INTEGER_EXT): return 4;
case(GL_LUMINANCE_INTEGER_EXT): return 1;
case(GL_LUMINANCE_ALPHA_INTEGER_EXT): return 2;
That's all... now it computes the number of components and, thus, the image size
correctly."
Source and CMake files are:
CMakeLists.txt
ReaderWriterBVH.cpp
Also there are 3 example BVH files. The first two are captured from motions of human beings - maybe a kung-fu master here. PLEASE use command below to see the results:
# osgviewer example1.bvh -O solids
This will demonstrate the animating of a skeleton and render bones as solid boxes. Note that the motion assumes XOZ is the ground and has an offset from the center, so we should adjust our view to get best effects.
You may also use "-O contours" to render bones as lines. The viewer shows nothing if without any options because osgAnimation::Bone does not render itself. User may add customized models to each named bones as osganimationskinning does to make uses of this plugin in their own applications.
I was wondering to support a BvhNode in my osgModeling peoject before, but soon found it better be a plugin for animation. A problem is, how to bind real geometry models to the skeleton. Maybe we could have a bindingToNode() visitor in future to find geodes matching names of bones and add them as bones' children."
--------------------------------------------
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.
"
Attached is a modified FindOpenEXR.cmake module that locates IlmIlf and Half, as well as a modified exr/CMakeLists.txt that picks up this change.
Also attached are some typo fixes for CMakeModules.
Cheers,"
updated XCode project, added osgAnimation framework + one example using it (osganimationviewer).
Added _OPENTHREADS_ATOMIC_USE_BSD_ATOMIC to local OpenThreads/Config when compiling for the 10.5 SDK.
Some minor fixes on some of the configurations/targets
"To reproduce the bug:
1. Create a template osg::Sequence node (and underlying geometry) but do not attach the node to the current active scenegraph.
2. At some point during the rendering loop (perhaps on a keystroke) clone the sequence node (I use the call:
dynamic_cast<osg::Node*>(templateNode -> clone( osg::CopyOp( (osg::CopyOp::CopyFlags)osg::CopyOp::DEEP_COPY_NODES ) ) )
3. Set the cloned sequence node duration to a value that makes the animation run slower (i.e. 2.0).
4. Start the cloned sequence (using setMode()).
5. Repeat steps 2 \u2013 4 and observe that the cloned sequences do not run slow but run as fast, appearing to ignore the duration that has been set on them.
Looking at the \u2018good documentation\u2019 (2.4 source code), I see that _start is being set to _now (osg::Sequence::setMode(), line 192). Should this not _start not be set to -1.0?"
The plug-in is a wrapper around open-exr (http://www.openexr.com) that consists of two projects, ilmbase-1.0.1 and openexr-1.6.1.
I have only tested it on windows XP 32 machine. So there might be some work making it work on other platforms.
The plug-in supports writing and reading EXR files. When writing it can use the data type GL_HALF_FLOAT_ARB(se ilmbase-1.0.1) and GL_FLOAT. When reading the data type always becomes GL_HALF_FLOAT_ARB. It supports textures with three and four channels.
When reading an exr file it automatically removes Alfa channel if it didn't store any information."
--
From Robert Osfield, started work on ported it to other platforms, but could fix some problems relating to error:
?Imf::OStream::OStream(const Imf::OStream&)? is private
I'm checking in now so that others can have a bash at completing the port.
Also, I've modified the FindCOLLADA.cmake to locate the current 2.1 versions of the COLLADA DOM in the build directories under VC8. I've also added a COLLADA_LIBRARY_DEBUG spec. Other flavors may be added depending on compiler version and DOM version."
Standard is to generate one stl file.
With an additional option it is possible to write one file per Geode. This option is not very "useful" for typical application, I use it for separating and conversion of geometric data. So it could be removed if considered to special."
