[osg-users] OpenSceneGraph-3.3.7 developer release tagged

[Robert Osfield]

Hi All,

I have just tagged the 3.3.7 developer release:

*O**pen**SceneGraph-3.3.7, **released on 15th April **2015*, key
deliverables in this dev release are:

   - Bug and build fixes
   - New osg::Camera attachment dirty mechanism to streamline the
   adjustment of FBO and Textures sizes
   - Added EXIF support to JPEG plugin, with automatic rotation of images
   according to the EXIF orientation setting
   - osg::Texture2DArray support for passing images in via an 3D osg::Image
   - Improvements to the 3DS plugins handling of transparent/diffuse
   textures and opacity maps.
   - Typo fixes to various doxygen and inline comments.
   - Support of OpenGL ES 3.0
   - Refactored osgManipulator::AntiSquish to address manipulator transform
   problems.
   - Fixed initial window size problem under WIn32 that was causing
   problems with mapping mouse coordinates for picking etc.
   - New osgjs and gles plugins to enable easy conversion of the OSG loaded
   models to work with osgjs (A Javascript/WebGL based OSG like scene graph.)

*source package :* OpenSceneGraph-3.3.7.zip


*svn tag:* svn co
http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-3.3.7
OpenSceneGraph

Thanks to all the contributors, OSG-3.4 branch very near now ;-)

Robert.

-- ChangeLog since 3.3.6

2015-04-15 18:05  robert

* CMakeLists.txt: Updated version number of dev release

2015-04-15 17:12  robert

* src/osgPlugins/gles/LineIndexFunctor: Added missing const to find
  VS2005 build

2015-04-14 18:16  robert

* src/osgViewer/GraphicsWindowWin32.cpp: Added check for changes to
  window size during GraphicsWindowWin32::init() to fix bug that
  occurs when the window manage resizes the window automatically on
  creation.

2015-04-14 15:50  robert

* src/osgPlugins/osgjs/JSON_Objects: From Philippe Renon, MingW
  build fix

2015-04-13 11:48  robert

* examples/osgprerender/osgprerender.cpp,
  examples/osgprerendercubemap/osgprerendercubemap.cpp,
  include/osg/Camera, src/osgSim/ElevationSlice.cpp,
  src/osgUtil/RenderStage.cpp,
  src/osgWrappers/deprecated-dotosg/osg/Camera.cpp,
  src/osgWrappers/serializers/osg/Camera.cpp: Fixed typo of
  SEPARATE enums

2015-04-13 10:43  robert

* CMakeModules/FindFFmpeg.cmake, CMakeModules/OsgMacroUtils.cmake,
  applications/osgconv/osgconv.cpp,
  applications/osgversion/osgversion.cpp,
  applications/present3D/Cluster.cpp,
  applications/present3D/present3D.cpp,
  examples/osg2cpp/osg2cpp.cpp,
  examples/osganimationsolid/osganimationsolid.cpp,
  examples/osganimationtimeline/osganimationtimeline.cpp,
  examples/osgautocapture/osgautocapture.cpp,
  examples/osgbillboard/osgbillboard.cpp,
  examples/osgcamera/osgcamera.cpp, examples/osgclip/osgclip.cpp,
  examples/osgcopy/osgcopy.cpp,
  examples/osgdistortion/osgdistortion.cpp,
  examples/osggeometry/osggeometry.cpp,
  examples/osgparticleshader/osgparticleshader.cpp,
  examples/osgreflect/osgreflect.cpp,
  examples/osgshadercomposition/osgshadercomposition.cpp,
  examples/osgtexture2DArray/osgtexture2DArray.cpp,
  examples/osgtexture3D/osgtexture3D.cpp,
  examples/osgwindows/osgwindows.cpp, include/OpenThreads/Thread,
  include/osg/Billboard, include/osg/BoundingSphere,
  include/osg/BufferIndexBinding, include/osg/BufferTemplate,
  include/osg/ImageSequence, include/osg/ScriptEngine,
  include/osg/Shader, include/osg/Shape, include/osg/State,
  include/osg/StateSet, include/osg/ValueObject,
  include/osgAnimation/Action, include/osgAnimation/RigGeometry,
  include/osgDB/Callbacks, include/osgManipulator/Dragger,
  include/osgPresentation/SlideEventHandler,
  include/osgShadow/OccluderGeometry,
  include/osgShadow/ViewDependentShadowMap,
  include/osgUtil/Optimizer, include/osgWidget/EventInterface,
  src/OpenThreads/pthreads/PThreadBarrierPrivateData.h,
  src/osg/Referenced.cpp, src/osg/Shader.cpp, src/osg/State.cpp,
  src/osg/Uniform.cpp, src/osgGA/CameraManipulator.cpp,
  src/osgPlugins/txp/trpage_geom.h,
  src/osgPlugins/txp/trpage_pparse.cpp,
  src/osgPlugins/txp/trpage_write.h,
  src/osgPresentation/SlideEventHandler.cpp,
  src/osgShadow/ConvexPolyhedron.cpp,
  src/osgShadow/DebugShadowMap.cpp,
  src/osgShadow/ShadowTechnique.cpp,
  src/osgShadow/ShadowVolume.cpp,
  src/osgShadow/ViewDependentShadowMap.cpp, src/osgViewer/View.cpp,
  src/osgWrappers/serializers/osgManipulator/Dragger.cpp: From
  Jannik Heller, typo fixes

2015-04-13 10:11  robert

* CMakeLists.txt, README.txt, src/osg/GL.in,
  src/osgPlugins/imageio/ReaderWriterImageIO.cpp,
  src/osgViewer/GraphicsWindowIOS.mm: From Konstantin Matveyev,
  "I've added GLES3 profile, which also enables GLES2 features
  (OSG_GLES3_AVAILABLE=tr

Re: [osg-users] Android osgPlugins

[Jan Ciger]

Hello Christian,

On Wed, Apr 15, 2015 at 4:15 PM, Christian Kehl 
wrote:


> Hi,
>
> I had a look on the OsgMainApp.hpp, where these plugin links are all active
> (looks as follows):
>
> //Static plugins Macro
> USE_OSGPLUGIN(ive)
> USE_OSGPLUGIN(osg)
> USE_OSGPLUGIN(osg2)
>
USE_OSGPLUGIN(terrain)
> USE_OSGPLUGIN(rgb)
> USE_OSGPLUGIN(OpenFlight)
> USE_OSGPLUGIN(dds)
> //Static DOTOSG
> USE_DOTOSGWRAPPER_LIBRARY(osg)
> USE_DOTOSGWRAPPER_LIBRARY(osgFX)
> USE_DOTOSGWRAPPER_LIBRARY(osgParticle)
> USE_DOTOSGWRAPPER_LIBRARY(osgTerrain)
> USE_DOTOSGWRAPPER_LIBRARY(osgText)
> USE_DOTOSGWRAPPER_LIBRARY(osgViewer)
> USE_DOTOSGWRAPPER_LIBRARY(osgVolume)
> //Static serializer
> USE_SERIALIZER_WRAPPER_LIBRARY(osg)
> USE_SERIALIZER_WRAPPER_LIBRARY(osgAnimation)
> USE_SERIALIZER_WRAPPER_LIBRARY(osgFX)
> USE_SERIALIZER_WRAPPER_LIBRARY(osgManipulator)
> USE_SERIALIZER_WRAPPER_LIBRARY(osgParticle)
> USE_SERIALIZER_WRAPPER_LIBRARY(osgTerrain)
> USE_SERIALIZER_WRAPPER_LIBRARY(osgText)
> USE_SERIALIZER_WRAPPER_LIBRARY(osgVolume)
>
> if one of them would go wrong, my JNI-compiler would mourn, I presume ?
> Hence, the links are active, still the models are not loaded.
>

That looks sensible to me.



>
> At the moment, I follow this approach:
> go on the commandline to my workdirectory,
> execute "/ndk-build", then go to eclipse,
> hit "start" and try out the app.
> May that be a cause for problems ?
>

No not really. That is pretty much how it should be built.

It would be best to turn on debugging and check where exactly it fails. It
could also be that you don't have osgDB compiled statically for some reason
- it was looking for its shared library. Does it load an .ive or .osg file?
Or no files at all?

J.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [3rdparty] Qt Form integration

[Christian Kunz]

Hi Alistair,

thanks for your reply. Your solution seems way easier. Do you have an example 
how to do that?


... 


Thank you!

Cheers,
Christian

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63404#63404





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] [3rdparty] Combining OSG and Qt 5.4 architecture

[Christian Kunz]

Hello everyone,

I have a question regarding the combination of OSG and Qt 5.4.
I already combined my OSG application with Qt. I used the example which is 
shipped with OSG: "osgviewerQt".
At the moment my OSG application is quite simple. Its a 3D scene with a 
animated 6 axis robot.

I added my root node as explained in the example:


Code:

QApplication app( argc, argv );
osgQt::GraphicsWindowQt* gw = createGraphicsWindow( 50, 50, 640, 480 );

//osg::Node* scene = osgDB::readNodeFile("cow.osg");
osg::Node* scene = root;

ViewerWidget* widget = new ViewerWidget(gw, scene);
widget->setGeometry( 100, 100, 800, 600 );
widget->show();
return app.exec();



Then my scene is rendered in a Qt Widget.

The problem with this solution is, that it is not a Qt mainWindow. Is there a 
way to add this ViewerWidget which is inherited from QWidget to a normal Qt 
form?
The best would be that you can see a placeholder in the forms editor of Qt 
creator. Does anyone know an example which is more complex than "osgviewerQt"?



... 
Thank you!

Cheers,
Christian
Code:




--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63403#63403





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Best practice for dynamic StateSets & Geometry

[Jannik Heller]

> I am surprised you saw a boost with disable double precision.  What specific 
> element you do you change w.r.t double precision? 

I enabled OSG_USE_FLOAT_MATRIX and OSG_USE_FLOAT_PLANE and observed a 10% 
framerate improvement.

Might be related to particle systems, which I forgot to mention I'm also using.


> 
> For the change to double precision making a difference it's a hint that you 
> have a scene that is poorly balanced.  
> 

W.r.t. balancing, for exterior environments I have objects organized in a grid 
of 3x3 cells. A quad tree might yield better results. Main problem though is 
that I am restricted to runtime optimizations - the scene itself comes from a 
third party source that I am not at liberty to modify or distribute. The scenes 
were created for a game in 2002, so not surprising they're CPU bound on modern 
hardware now.

I plan on trying the osgUtil::Optimizer at some point though I'm afraid I can 
only run it on individual models and not the whole scene - as the scene is 
tightly connected to game logics, scripting, physics, etc.


> 
> Are you using CPU based animation?  Could you shift it onto the GPU? 
> 

Yes and yes - I am using software skinning at the moment just because it works. 
I will try and move to hardware skinning later, but for now I am focused on 
porting the rest of my rendering code to OSG before optimizing more.

Thanks,
Jannik[/quote]

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63421#63421





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Android osgPlugins

[Christian Kehl]

Jan Ciger  writes:

> 
> 
> 
> On Mon, Apr 13, 2015 at 11:16 AM, Christian Kehl 
uni.no> wrote:Hi Jordi,
> I encounter the same problem in the same situation. I've build OSG for
> Android in static mode (only way it even compiles), all static libraries
> (for me: .a-files) are in my local installation folder, together with the
> libraries for armeabi and armeabi-v7a from the Android Native Developer Kit.
> It compiles fine, I can change the background of the viewer without
> problems, but it just doesn't wanna load the models. I get the same logcat
> messages as mentioned before (not finding the plugins). I, up until now,
> loaded files from the internal HDD of the phone (I am on Nexus 5), but today
> also try out the sdcard as source. Are there any suggestions how to solve
> the problem ?
> 
> 
> 
> 
> Did you:
> 
> a) Link the plugins into your JNI code? This is needed because the
libraries are static, thus it cannot load them dynamically at runtime. It is
a workaround for complicated deployment on Android. 
> 

> 
> Without this sort of declaration and the corresponding linking statement
it will not work when built as a fully static library. 
> 
> J.

I also append the output of the ndk-build, in case this may give some
indication what goes wrong there ...

christian@PROMETHEUS:~/workspace/Android/osgViewer2$ ${ANDROID_NDK}/ndk-build
Android NDK: WARNING:jni/Android.mk:osgNativeLib: non-system libraries in
linker flags: -lgnustl_static -lcurl -ljpeg -lgif -lpng -ltiff -losgdb_dds
-losgdb_openflight -losgdb_tga -losgdb_rgb -losgdb_osgterrain -losgdb_osg
-losgdb_ive -losgdb_deprecated_osgviewer -losgdb_deprecated_osgvolume
-losgdb_deprecated_osgtext -losgdb_deprecated_osgterrain
-losgdb_deprecated_osgsim -losgdb_deprecated_osgshadow
-losgdb_deprecated_osgparticle -losgdb_deprecated_osgfx
-losgdb_deprecated_osganimation -losgdb_deprecated_osg
-losgdb_serializers_osgvolume -losgdb_serializers_osgtext
-losgdb_serializers_osgterrain -losgdb_serializers_osgsim
-losgdb_serializers_osgshadow -losgdb_serializers_osgparticle
-losgdb_serializers_osgmanipulator -losgdb_serializers_osgfx
-losgdb_serializers_osganimation -losgdb_serializers_osg -losgViewer
-losgVolume -losgTerrain -losgText -losgShadow -losgSim -losgParticle
-losgManipulator -losgGA -losgFX -losgDB -losgAnimation -losgUtil -losg
-lOpenThreads
Android NDK: This is likely to result in incorrect builds. Try using
LOCAL_STATIC_LIBRARIES
Android NDK: or LOCAL_SHARED_LIBRARIES instead to list the library
dependencies of the
Android NDK: current module
Android NDK: WARNING:jni/Android.mk:osgNativeLib: non-system libraries in
linker flags: -lgnustl_static -lcurl -ljpeg -lgif -lpng -ltiff -losgdb_dds
-losgdb_openflight -losgdb_tga -losgdb_rgb -losgdb_osgterrain -losgdb_osg
-losgdb_ive -losgdb_deprecated_osgviewer -losgdb_deprecated_osgvolume
-losgdb_deprecated_osgtext -losgdb_deprecated_osgterrain
-losgdb_deprecated_osgsim -losgdb_deprecated_osgshadow
-losgdb_deprecated_osgparticle -losgdb_deprecated_osgfx
-losgdb_deprecated_osganimation -losgdb_deprecated_osg
-losgdb_serializers_osgvolume -losgdb_serializers_osgtext
-losgdb_serializers_osgterrain -losgdb_serializers_osgsim
-losgdb_serializers_osgshadow -losgdb_serializers_osgparticle
-losgdb_serializers_osgmanipulator -losgdb_serializers_osgfx
-losgdb_serializers_osganimation -losgdb_serializers_osg -losgViewer
-losgVolume -losgTerrain -losgText -losgShadow -losgSim -losgParticle
-losgManipulator -losgGA -losgFX -losgDB -losgAnimation -losgUtil -losg
-lOpenThreads
Android NDK: This is likely to result in incorrect builds. Try using
LOCAL_STATIC_LIBRARIES
Android NDK: or LOCAL_SHARED_LIBRARIES instead to list the library
dependencies of the
Android NDK: current module
[armeabi] Compile++ thumb: osgNativeLib <= osgNativeLib.cpp
[armeabi] Compile++ thumb: osgNativeLib <= OsgMainApp.cpp
[armeabi] Compile++ thumb: osgNativeLib <= OsgAndroidNotifyHandler.cpp
[armeabi] SharedLibrary  : libosgNativeLib.so
[armeabi] Install: libosgNativeLib.so => libs/armeabi/libosgNativeLib.so
[armeabi-v7a] Compile++ thumb: osgNativeLib <= osgNativeLib.cpp
[armeabi-v7a] Compile++ thumb: osgNativeLib <= OsgMainApp.cpp
[armeabi-v7a] Compile++ thumb: osgNativeLib <= OsgAndroidNotifyHandler.cpp
[armeabi-v7a] SharedLibrary  : libosgNativeLib.so
[armeabi-v7a] Install: libosgNativeLib.so =>
libs/armeabi-v7a/libosgNativeLib.so




___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Android osgPlugins

[Christian Kehl]

Jan Ciger  writes:

> 
> 
> 
> On Mon, Apr 13, 2015 at 11:16 AM, Christian Kehl 
uni.no> wrote:Hi Jordi,
> I encounter the same problem in the same situation. I've build OSG for
> Android in static mode (only way it even compiles), all static libraries
> (for me: .a-files) are in my local installation folder, together with the
> libraries for armeabi and armeabi-v7a from the Android Native Developer Kit.
> It compiles fine, I can change the background of the viewer without
> problems, but it just doesn't wanna load the models. I get the same logcat
> messages as mentioned before (not finding the plugins). I, up until now,
> loaded files from the internal HDD of the phone (I am on Nexus 5), but today
> also try out the sdcard as source. Are there any suggestions how to solve
> the problem ?
> 
> 
> 
> 
> Did you:
> 
> a) Link the plugins into your JNI code? This is needed because the
libraries are static, thus it cannot load them dynamically at runtime. It is
a workaround for complicated deployment on Android. 
> 
> b) Declared which plugins you are using? Again, this is linked to the
point above, because the plugin registration has to be done at compile time
when using static linking. Make sure that you have something like this in
your code (add/remove the plugins you need/don't need):
> //Static plugins
> MacroUSE_OSGPLUGIN(ive)
> USE_OSGPLUGIN(osg)
> USE_OSGPLUGIN(osg2)
> USE_OSGPLUGIN(freetype)
> //USE_OSGPLUGIN(terrain)
> USE_OSGPLUGIN(rgb)//
> USE_OSGPLUGIN(OpenFlight)
> //USE_OSGPLUGIN(dds)
> //Static
> DOTOSGUSE_DOTOSGWRAPPER_LIBRARY(osg)
> //USE_DOTOSGWRAPPER_LIBRARY(osgFX)
> //USE_DOTOSGWRAPPER_LIBRARY(osgParticle)
> //USE_DOTOSGWRAPPER_LIBRARY(osgTerrain)
> USE_DOTOSGWRAPPER_LIBRARY(osgText)
> USE_DOTOSGWRAPPER_LIBRARY(osgAnimation)
> //USE_DOTOSGWRAPPER_LIBRARY(osgViewer)
> //USE_DOTOSGWRAPPER_LIBRARY(osgVolume)
> //Static serializer
> USE_SERIALIZER_WRAPPER_LIBRARY(osg)
> USE_SERIALIZER_WRAPPER_LIBRARY(osgAnimation)
> //USE_SERIALIZER_WRAPPER_LIBRARY(osgFX)
> USE_SERIALIZER_WRAPPER_LIBRARY(osgManipulator)
> //USE_SERIALIZER_WRAPPER_LIBRARY(osgParticle)
> //USE_SERIALIZER_WRAPPER_LIBRARY(osgTerrain)
> USE_SERIALIZER_WRAPPER_LIBRARY(osgText)
> //USE_SERIALIZER_WRAPPER_LIBRARY(osgVolume)
> 
> Without this sort of declaration and the corresponding linking statement
it will not work when built as a fully static library. 
> 
> J.


Hi,

I had a look on the OsgMainApp.hpp, where these plugin links are all active
(looks as follows):

//Static plugins Macro
USE_OSGPLUGIN(ive)
USE_OSGPLUGIN(osg)
USE_OSGPLUGIN(osg2)
USE_OSGPLUGIN(terrain)
USE_OSGPLUGIN(rgb)
USE_OSGPLUGIN(OpenFlight)
USE_OSGPLUGIN(dds)
//Static DOTOSG
USE_DOTOSGWRAPPER_LIBRARY(osg)
USE_DOTOSGWRAPPER_LIBRARY(osgFX)
USE_DOTOSGWRAPPER_LIBRARY(osgParticle)
USE_DOTOSGWRAPPER_LIBRARY(osgTerrain)
USE_DOTOSGWRAPPER_LIBRARY(osgText)
USE_DOTOSGWRAPPER_LIBRARY(osgViewer)
USE_DOTOSGWRAPPER_LIBRARY(osgVolume)
//Static serializer
USE_SERIALIZER_WRAPPER_LIBRARY(osg)
USE_SERIALIZER_WRAPPER_LIBRARY(osgAnimation)
USE_SERIALIZER_WRAPPER_LIBRARY(osgFX)
USE_SERIALIZER_WRAPPER_LIBRARY(osgManipulator)
USE_SERIALIZER_WRAPPER_LIBRARY(osgParticle)
USE_SERIALIZER_WRAPPER_LIBRARY(osgTerrain)
USE_SERIALIZER_WRAPPER_LIBRARY(osgText)
USE_SERIALIZER_WRAPPER_LIBRARY(osgVolume)

if one of them would go wrong, my JNI-compiler would mourn, I presume ?
Hence, the links are active, still the models are not loaded.

At the moment, I follow this approach:
go on the commandline to my workdirectory, 
execute "/ndk-build", then go to eclipse, 
hit "start" and try out the app. 
May that be a cause for problems ?

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Best practice for dynamic StateSets & Geometry

[Robert Osfield]

Hi Jannik,


On 15 April 2015 at 11:55, Jannik Heller  wrote:

> Thanks for the hints - I am using a release build, and I already disabled
> double precision from cmake which gave me another nice boost.
>

I am surprised you saw a boost with disable double precision.  What
specific element you do you change w.r.t double precision?

For the change to double precision making a difference it's a hint that you
have a scene that is poorly balanced.



> In the stats handler I am seeing roughly the same amount of time spent in
> the cull, draw and GPU threads. After adding the double buffering the 3
> threads all run in parallel so performance is decent now.
> I know that my app is CPU bound but there's not much I can do about it.
> Some of the time in the cull thread is spent updating vertex animations,
> and some time for organizing light lists. I have scenes with a lot more
> than 8 lights, so I have to check what lights are closest to a given
> sub-graph before rendering it. This system was really slow to begin with
> but I already optimized it a lot. Non the less setting the lights still has
> a noticable overhead.
> Next problem is the sheer number of objects - often thousands per scene. I
> tried batching before but the problem is the scenes I am working with are
> scripted, so objects can be moved or removed at any time, also, batching
> objects would interfere with the light lists - i.e. with too many objects
> sharing a large batch I can not set fine grained light lists on them.
> I'm looking forward to switching the light system to deferred shading in
> the future - I'm sure then it will be GPU bound. I still need a forward
> rendering fallback in place though.
>

Thousands of objects per frame is not unusually for a scene graph
application and should work fine rendering at 60hz on modern hardware.  If
you are hitting CPU limits prematurely then it's another hint that the
scene graph is poorly balanced.

There are lots of different things you can do to create a more efficient
scene graph, exactly what to advice is hard to do without knowing more
specifics about the application and types of data being handling.  Batching
might be one thing to try, but only if it's established as the main
bottleneck.  From what you've written I wonder if the animation element to
your scene is what is slowing things down.   Are you using CPU based
animation?  Could you shift it onto the GPU?

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Best practice for dynamic StateSets & Geometry

[Jannik Heller]

Hi Robert,

Thanks for the hints - I am using a release build, and I already disabled 
double precision from cmake which gave me another nice boost.

In the stats handler I am seeing roughly the same amount of time spent in the 
cull, draw and GPU threads. After adding the double buffering the 3 threads all 
run in parallel so performance is decent now.
I know that my app is CPU bound but there's not much I can do about it.
Some of the time in the cull thread is spent updating vertex animations, and 
some time for organizing light lists. I have scenes with a lot more than 8 
lights, so I have to check what lights are closest to a given sub-graph before 
rendering it. This system was really slow to begin with but I already optimized 
it a lot. Non the less setting the lights still has a noticable overhead.
Next problem is the sheer number of objects - often thousands per scene. I 
tried batching before but the problem is the scenes I am working with are 
scripted, so objects can be moved or removed at any time, also, batching 
objects would interfere with the light lists - i.e. with too many objects 
sharing a large batch I can not set fine grained light lists on them.
I'm looking forward to switching the light system to deferred shading in the 
future - I'm sure then it will be GPU bound. I still need a forward rendering 
fallback in place though. 

Cheers,
Jannik

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63417#63417





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] [GL ES2.0] Render to texture

[Jean Baptiste Poquelin]

Hi,

I am trying to render a scene inside a texture using OpenGL ES 2.0 in the 
particular context of a server side renderer using render node and GBM. Here is 
a sample of what I am trying to achieve:


Code:

static const EGLint conf_att[] =
{
EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
EGL_RENDERABLE_TYPE, EGL_OPENGL_BIT,
EGL_RED_SIZE, 1,
EGL_GREEN_SIZE, 1,
EGL_BLUE_SIZE, 1,
EGL_ALPHA_SIZE, 0,
EGL_NONE,
};
static const EGLint ctx_att[] =
{
EGL_CONTEXT_CLIENT_VERSION, 2,
EGL_NONE
};
EGLBoolean b;
EGLenum api;
EGLint major, minor, n;
EGLConfig egl_conf;
struct gbm_device *gbm_dev;

int rnode = rnode_open();
gbm_dev = gbm_create_device(rnode);
if(!gbm_dev)
{
std::cerr << "cannot create gbm device" << std::endl;
return;
}

EGLDisplay egl_display = eglGetDisplay((EGLNativeDisplayType)gbm_dev);
if(!egl_display)
{
std::cerr << "cannot create EGL display" << std::endl;
return;
}

b = eglInitialize(egl_display, &major, &minor);
if(!b)
{
std::cerr << "cannot initialize EGL" << std::endl;
return;
}

std::cout << "EGL major/minor: " << major << "." << minor << std::endl;
std::cout << "EGL version: " << eglQueryString(egl_display, EGL_VERSION) << 
std::endl;
std::cout << "EGL vendor: " << eglQueryString(egl_display, EGL_VENDOR) << 
std::endl;
std::cout << "EGL extensions: " << eglQueryString(egl_display, EGL_EXTENSIONS) 
<< std::endl;

api = EGL_OPENGL_API;
b = eglBindAPI(api);
if(!b)
{
std::cerr << "cannot bind OpenGLES API" << std::endl;
return;
}

b = eglChooseConfig(egl_display, conf_att, &egl_conf, 1, &n);

if(!b || n != 1)
{
std::cerr << "cannot find suitable EGL config" << std::endl;
return;
}

EGLContext egl_ctx = eglCreateContext(egl_display, egl_conf, EGL_NO_CONTEXT, 
ctx_att);
if(!egl_ctx)
{
std::cerr << "cannot create EGL context" << std::endl;
return;
}

eglMakeCurrent(egl_display, EGL_NO_SURFACE, EGL_NO_SURFACE, egl_ctx);

osg::ref_ptr viewer = new osgViewer::Viewer();
osg::ref_ptr graphicsWindow = 
viewer->setUpViewerAsEmbeddedInWindow(0, 0, width, height);
if(!graphicsWindow->valid())
{
std::cerr << "Viewer window is invalid." << std::endl;
return;
}

viewer->setThreadingModel(osgViewer::ViewerBase::SingleThreaded);

viewer->realize();

if(!viewer->isRealized())
{
std::cerr << "No viewer window is realized." << std::endl;
return;
}

osgViewer::Viewer::Windows windows;
viewer->getWindows(windows);
for(osgViewer::Viewer::Windows::iterator itr = windows.begin();itr != 
windows.end();++itr)
{
  (*itr)->getState()->setUseModelViewAndProjectionUniforms(true);
  (*itr)->getState()->setUseVertexAttributeAliasing(true);
}

// create texture
texture = new osg::Texture2D;
texture->setTextureSize(width, height);
texture->setInternalFormat(GL_RGBA);
texture->setSourceFormat(GL_RGBA);
texture->setSourceType(GL_FLOAT);
texture->setFilter(osg::Texture2D::MIN_FILTER, 
osg::Texture2D::LINEAR_MIPMAP_LINEAR);
texture->setFilter(osg::Texture2D::MAG_FILTER, osg::Texture2D::LINEAR);
texture->setWrap(osg::Texture2D::WRAP_S, osg::Texture2D::CLAMP_TO_EDGE);
texture->setWrap(osg::Texture2D::WRAP_T, osg::Texture2D::CLAMP_TO_EDGE);

// attach texture to camera
osg::Camera *camera = viewer->getCamera();
camera->setViewport(0, 0, texture->getTextureWidth(), 
texture->getTextureHeight());
camera->setClearColor(osg::Vec4(1.0f, 1.0f, 1.0f, 0.0f));
camera->setClearMask(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);

camera->setRenderOrder(osg::Camera::PRE_RENDER);
camera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
camera->attach(osg::Camera::COLOR_BUFFER, texture);

camera->setReferenceFrame(osg::Camera::ABSOLUTE_RF);

osg::State &state = graphicsWindow->getState();
state.initializeExtensionProcs();
texture->apply(state);

// create an EGL image from that texture
EGLImageKHR image = eglCreateImageKHR(egl_display, egl_ctx,
   EGL_GL_TEXTURE_2D_KHR,
   (EGLClientBuffer)(unsigned 
long)texture->getTextureObject(0)->id(),
   NULL);

std::cout << "got image " << image << std::endl;

EGLint handle;
int stride;
b = eglExportDRMImageMESA(egl_display, image, NULL, &handle, &stride);
if(!b)
{
std::cerr << "failed to export image" << std::endl;
return;
}

std::cout << "image exported " << handle << " " << stride << std::endl;
int fd;
int r = drmPrimeHandleToFD(rnode, handle, DRM_CLOEXEC, &fd);
if(r < 0)
{
std::cerr << "cannot get prime-fd for handle" << std::endl;
return;
}

// create quad
osg::ref_ptr vertices = new osg::Vec3Array;
vertices->push_back(osg::Vec3(-0.5f, 0.0f,-0.5f));
vertices->push_back(osg::Vec3(0.5f, 0.0f,-0.5f));
vertices->push_back(osg::Vec3(0.5f, 0.0f, 0.5f));
vertices->push_back(osg::Vec3(-0.5f, 0.0f, 0.5f));
osg::ref_ptr normals = new osg:

Re: [osg-users] RTT Camera does not render anything

[Sebastian Messerschmidt]

Hi Andreas,



Hi,

my bad for not explaining it very well ;)

I want the following:

With the RTT Camera I want to render a specific geometry. The texture I get 
from that, will be used in the main scene later.

The RTT Camera must not point in the same direction as the main camera.
If this would be the case the texture would change if I move the camera, 
correct?

My thought was if I create the RTT Camera, with "ABSOLUTE_RF" it would point in 
the same direction as the main camera, but would not change its orientation etc. when the 
main camera does.
It will have some default orientation and is totally decoupled from 
other cameras.
So you will have to set the orientation/projection to what you desire, 
either by callback or if static after the initialization.





Now I try to read out the ViewMatrix and the ProjectionMatrix to find out the 
difference.



At the moment I just  could transform the geometry under the RTT Camera so the 
camera renders the part I want. But I wanted to understand what goes on so I do 
not carry any mistakes with me ;).
You can do it this way or apply the same transformation inverted to the 
camera ...


Hope this makes it clear, if anything isn't just ask

Thank you for helping me out Sebastian ;)
...

Thank you!

Cheers,
Andreas

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63415#63415





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] RTT Camera does not render anything

[Andreas Schreiber]

Hi,

my bad for not explaining it very well ;)

I want the following:

With the RTT Camera I want to render a specific geometry. The texture I get 
from that, will be used in the main scene later.

The RTT Camera must not point in the same direction as the main camera.
If this would be the case the texture would change if I move the camera, 
correct?

My thought was if I create the RTT Camera, with "ABSOLUTE_RF" it would point in 
the same direction as the main camera, but would not change its orientation 
etc. when the main camera does.


Now I try to read out the ViewMatrix and the ProjectionMatrix to find out the 
difference.



At the moment I just  could transform the geometry under the RTT Camera so the 
camera renders the part I want. But I wanted to understand what goes on so I do 
not carry any mistakes with me ;).

Hope this makes it clear, if anything isn't just ask

Thank you for helping me out Sebastian ;)
... 

Thank you!

Cheers,
Andreas

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63415#63415





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG RECIPES Data

[Dave Sargrad]

wangrui wrote:
> Hi Dave,
> 
> 
> One of the purpose of the osgRecipes project is to provide all source code 
> used in the book OpenSceneGraph 3.0 Cookbook, published by Packt Publishing. 
> And what you found is just corresponding to the second example in Chapter 5. 
> And it should be a mistake... The correct code snippet, as shown in the book, 
> is as below:
> image = osgDB::readImageFile( "0.ffmpeg", new osgDB::Options("format=vfwcap 
> frame_rate=25") );
> 
> 
> It in fact uses the FFmpeg plugin to load video stream from the webcam using 
> the VFW option. You may change the filename to some other disk files like 
> "c:/path/file.avi.ffmpeg" and then ignore the option string. But there is no 
> "animate PNG" support in OSG... so sorry for the misdirection. :-)
> 
> 
> Also thank you for supporting the osgRecipes project.
> 
> 
> Wang Rui
> 
> 
> -- Original --
> From:  "Dave Sargrad";<>;
> Date:  Wed, Apr 15, 2015 05:42 AM
> To:  "osg-users"<>; 
> 
> Subject:   OSG RECIPES Data
> 
> 
> 
> Hi,
> 
> I've found the osgRecipes (https://github.com/xarray/osgRecipes) to be quite 
> useful. However most of the data is missing from these, and there is no 
> proper reference to the location of the data. I stumbled on this 
> (https://github.com/openscenegraph/osg-data) data. It seems to be a close fit 
> to the recipes. However some data files are missing. For example right now 
> I'm in cookbook_05_02. This cookbook is looking for one of two datafiles (in 
> my case pic.png). I think this is just a placeholder, and I'm expected to 
> drop my own "animated PNG" into place. I've tried several such png's found on 
> the web, but none seem to do what one might expect.
> 
> 
> Code:
> osg::ref_ptr image;
> if ( arguments.argc()>1 )
> image = osgDB::readImageFile( arguments[1] );
> else
> {
> #ifdef WIN32
> image = osgDB::readImageFile( "Images/bouncing_beach_ball.png" );
> #else
> image = osgDB::readImageFile( "/dev/video0.ffmpeg" );
> #endif
> }
> 
> osg::ImageStream* imageStream = dynamic_cast( image.get() 
> );
> if ( imageStream ) imageStream->play();
> 
> 
> 
> I've never used animated png's before so I'm not sure how best to find a 
> compatible image.
> 
> In this code snippet, I replaced pic.png with a bouncing_beach_ball.png found 
> here 
> (http://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png).
> 
> Thank you for any insights.
> 
> Cheers,
> Dave
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=63394#63394
> 
> 
> 
> 
> 
> ___
> osg-users mailing list
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
>  --
> Post generated by Mail2Forum


Thanks very much. This is quite helpful. Certainly no need for apologies. I 
find that most of the cookbook examples are extremely informative. I look 
forward to acquiring the book for the surrounding explanations.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63414#63414





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] RTT Camera does not render anything

[Sebastian Messerschmidt]

You lost me here,

You want a relative RTT camera ("pointing" to where the main camera 
points to) but you set up da absolute camera (having its independent 
Viewport, matrix etc.)
You most likely want to have a ABSOLUTE ref frame for screenspace passes 
and final output only-


Cheers
Sebastian

Hi,

sorry here it is

Code:

osg::ref_ptr RTTCamera = 
createRTTCamera(osg::Camera::COLOR_BUFFER, rttTexture.get(), 1);




then I add to this camera the needed geometry and at the camera to the scene 
graph

Code:

RTTCamera->addChild(geometry.get());

root->addChild(RTTCamera.get());
root->addChild(geometry.get());
root->addChild(rttQuad.get());





Between these steps I do nothing else with the rtt camera.

In the createRTTCamera function I set the ReferenceFrame to "ABSOLUTE_RF"

...

Thank you!

Cheers,
Andreas

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63407#63407





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] RTT Cameras for computer vision simulation

[Robert Osfield]

Hi Matt,

The osgscreencapture example has code use setting up multiple pixel buffer
objects to help improve the speed of reading images.  The key is double
buffering the PBO's so you read asynchronously.

Robert.

On 15 April 2015 at 04:37, Matt Donahoe  wrote:

> Hi,
>
> I am looking to use OpenSceneGraph to simulate multi-camera images in real
> time, but my frame rates are not great with the number of cameras I need. I
> currently have 6 cameras rendering to 640x480 images and I see ~8fps max,
> with a lot of jitter.
>
> The osg examples have been a great help, but I wanted to ask for general
> advice before I dig too much deeper. Everything I have read indicates that
> GPU->CPU is a very slow operation, but I am wondering if I am actually
> maxed out or just doing something dumb.
>
> Here is my setup for N cameras:
>
> 0. Populate the scene with objects
> 1. Create the N osg::Cameras with RenderTargetImplementation of
> FRAME_BUFFER_OBJECT (PIXEL_BUFFER doesn't work for me yet)
> 2. Create N rgb 640x480 osg::Images and attach to the cameras
> 3. Add my scene to each camera
> 4. Add draw callbacks to each camera.
> 5. Add each camera to a root scene.
> 6. Create a viewer with the root scene.
>
> Now in a custom main loop, I do the following:
>
> 0. Read the requested camera poses from a message queue
> 1. Adjust the pose of each camera
> 2. Viewer.frame()
> 3. Each camera callback will fire
> 4. When all camera callbacks have fired, I read .data() from each Image.
> 5. Publish the N images in a single message, which gets serialized and
> sent over UDP to other processes.
>
> I still need to profile this to see where the bottleneck is, but my hunch
> is that I can speed up by rendering and reading the data from each camera
> independently instead of simultaneously. I am not sure how to do it yet,
> but I assume "Pixel Buffer Objects" will be part of the answer.
>
> Any suggestions on where to start would be appreciated!
>
> Cheers,
> Matt
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=63398#63398
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Thoughts on Vulkan

[Robert Osfield]

Hi David, Chris et. al,

On 14 April 2015 at 22:47, Chris Hanson  wrote:

> I think OSG is a bad fit for Vulkan. OSG has so much code to support FFP
> dataflows that Vulkan doesn't have.
>
> I personally think a Vulkan scenegraph could be made from the components
> of OSG (OSG 4.x?) but bringing along all of OSG's legacy code into a Vulkan
> space would be counterproductive.
>

This is not far from my own viewpoint.  I do have a rough plan in mind that
is still evolving. I'll open my own thoughts for discussion once OSG-3.4 is
out the door.

Right now getting a OSG-3.4 is my focus.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Best practice for dynamic StateSets & Geometry

[Robert Osfield]

Hi Jannik,

General purpose double buffering of data is something I've considered in
the past but not attempted to implement into the core OSG as it introduces
a range of complexities in implementation and API.  There are places in the
OSG where buffering is done locally but in general these are areas where
the implementation is lightweight and there is a clear benefit.

In your case it's cool that you've found a way of implementing and got a
performance benefit.  It's a complexity that most users haven't tried to
tackle before, but I suspect this is probably partly down to not having the
same bottlenecks that you are probably seeing.

I don't know the bottlenecks in your app, but for DrawThreadPerContext to
make such big difference in performance it would suggest that your are CPU
bound.  Are you update, cull, draw dispatch or draw GPU bound?  Use the
osgViewer::StatsHandler to show the relatively load on screen.  Most scene
graphs app will have a pretty light update, a modest cull and draw
dispatch.  If any of these phases are the bottleneck then look to resolving
these might be the key to getting best performance rather than adding
double buffering.

Also, make sure that you are using a release build when performance
profiling, the results you get in debug make a huge difference and can
totally distort the relative cost of different phases.

Cheers,
Robert.



On 14 April 2015 at 18:28, Jannik Heller  wrote:

> Hi OSG friends,
>
> A common challenge for OSG users are the implications of the viewer
> threading model - by default the viewer.frame() will return before the draw
> dispatch is complete, meaning users (and the OSG) can start preparing the
> next frame before the current frame has completed. However, if you attempt
> to change a StateSet or Drawable in the frame update, you run the risk of
> modifying data that the OSG is still working with in a background thread,
> resulting in crashes.
> Often times you will see code dealing with this by setting the
> DataVariance of the object to DYNAMIC. Unfortunately as result the draw
> dispatch has to complete before the frame() returns, for me this dropped
> the frame rate in half.
> Recently I developed a more efficient solution for dealing with this and
> would like to hear your thoughts.
> The idea is similar to "double buffering" with the framebuffer - you
> create two copies of the data on start, one copy is write only, another
> copy is read only, and when the frame completes the roles are swapped. You
> can implement this idea for both Drawables and StateSets:
> - Dynamic Drawables (RigGeometry, MorphGeometry, etc): create a deep copy
> of the Drawable, decorate both Drawables with a FrameSwitch node. A
> FrameSwitch node is a variant of Group that only traverses even or non-even
> children based on the current FrameStamp. Code (
> https://github.com/OpenMW/openmw/blob/f7da9796692e14c79632cb85fa75a90b082cd863/components/nifosg/nifloader.cpp#L179
> )
> - Dynamic StateSets: Create two copies of the StateSet on start, then
> every frame in a NodeCallback swap the roles of these StateSets, apply
> changes to the first StateSet, then set the currently active StateSet on
> the Node. Code (
> https://github.com/scrawl/openmw/blob/osg/components/sceneutil/statesetupdater.cpp#L8
> )
>
> There are some downsides to this approach (mostly that for data that is
> just rarely changing, you have to apply every change twice), but other than
> that it works beautifully and now I've got 2x the framerate again.
>
> I'm curious how the OSG veterans are dealing with this. Anything I've
> missed?
>
> Cheers
> Jannik
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=63390#63390
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] RTT Camera does not render anything

[Andreas Schreiber]

Hi,

sorry here it is  

Code:

osg::ref_ptr RTTCamera = 
createRTTCamera(osg::Camera::COLOR_BUFFER, rttTexture.get(), 1);




then I add to this camera the needed geometry and at the camera to the scene 
graph

Code:

RTTCamera->addChild(geometry.get());

root->addChild(RTTCamera.get());
root->addChild(geometry.get());
root->addChild(rttQuad.get());





Between these steps I do nothing else with the rtt camera.

In the createRTTCamera function I set the ReferenceFrame to "ABSOLUTE_RF"

... 

Thank you!

Cheers,
Andreas

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63407#63407





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] RTT Camera does not render anything

[Sebastian Messerschmidt]

Hi Andreas,
you are not showing the part where you use the

createRTTCamera

function.
Are you setting it up as relative to the main camera?

Cheers
Sebastian


Hi,

ok that was a big mistake from my side.

I forgot to set the width and height of the Texture, but I used 
getTextureWidth() and getTextureHeight to specify the Viewport.

Well if the Viewport is (0, 0, 0, 0) there will be nothing to see.


But the thing with the orientation I am still trying to understand.

...

Thank you!

Cheers,
Andreas

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63405#63405





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] RTT Camera does not render anything

[Andreas Schreiber]

Hi,

ok that was a big mistake from my side.

I forgot to set the width and height of the Texture, but I used 
getTextureWidth() and getTextureHeight to specify the Viewport.

Well if the Viewport is (0, 0, 0, 0) there will be nothing to see.


But the thing with the orientation I am still trying to understand.

... 

Thank you!

Cheers,
Andreas

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63405#63405





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] RTT Camera does not render anything

[Andreas Schreiber]

Hi,

I changed my camera. 

Now I don't use the method where I create the rtt camera, like shown in first 
post.

Now I just created the camera in the method where I setup the scene and it 
works...

I really do not get why
Is there a specific order I should follow with the camera calls (setReference, 
setRenderOrder, setProjectionmatrixAsOrtho2D, setViewport, etc)??


One more thing that bothers me is the orientation. 
I did no transforms on the viewer or the scene itself. So my expectation was 
that the rendering of the rtt camera should be in the same orientation like the 
viewer camera, but it looks like in sketch which I attached.



Thank you!

Cheers,
Andreas[/img]

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63402#63402



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org