Re: [osg-users] OSG and .NET (C#)
Hi Nick, I forgot those. Please copy the missing .i files from the python folder to the csharp folder. They are redirecting to the ones one directory level above (the ones i've sent you). Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce Nikolov NICK Sent: Friday, May 23, 2014 11:12 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG and .NET (C#) Hi Carsten Thanks a bunch! At least some progress. I had to remove from src/csharp/CMakeLists.txt at ln 121 osgdSPACE to get it generated and now configure is complaining (see the attached log). You are sending these files in the zip file, shell I copy them in the csharp folder? OSG VERSION 3.1.6 Configuring done CMake Error in src/csharp/CMakeLists.txt: Cannot find source file: D:/Development/osgswig/src/csharp/osg.i Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx CMake Error in src/csharp/CMakeLists.txt: Cannot find source file: D:/Development/osgswig/src/csharp/osgAnimation.i Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx CMake Error in src/csharp/CMakeLists.txt: Cannot find source file: D:/Development/osgswig/src/csharp/osgDB.i Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx CMake Error in src/csharp/CMakeLists.txt: Cannot find source file: D:/Development/osgswig/src/csharp/osgFX.i Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx CMake Error in src/csharp/CMakeLists.txt: Cannot find source file: D:/Development/osgswig/src/csharp/osgGA.i Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx CMake Error in src/csharp/CMakeLists.txt: Cannot find source file: D:/Development/osgswig/src/csharp/osgManipulator.i Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx CMake Error in src/csharp/CMakeLists.txt: Cannot find source file: D:/Development/osgswig/src/csharp/osgSim.i Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx CMake Error in src/csharp/CMakeLists.txt: Cannot find source file: D:/Development/osgswig/src/csharp/osgText.i Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx CMake Error in src/csharp/CMakeLists.txt: Cannot find source file: D:/Development/osgswig/src/csharp/osgUtil.i Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx CMake Error in src/csharp/CMakeLists.txt: Cannot find source file: D:/Development/osgswig/src/csharp/osgViewer.i Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx Generating done On Fri, May 23, 2014 at 9:19 AM, Carsten Scharfe cscha...@dspace.demailto:cscha...@dspace.de wrote: Try the ones in the attached zip file _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.orgmailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce Nikolov NICK Sent: Wednesday, May 21, 2014 10:11 PM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG and .NET (C#) Hi Carsten, again on this topic, I decided to not give up on this. I am wondering how you actually build osgswig from the current source available. I have examined the CMakeLists.txt files in the project and all I can say this is available for python, perl and java only, from my little understanding of CMake configuration. In the main CMakeLists.txt line 174 is adding the src folder for the core And this is the src CMakeLists IF (BUILD_OSGPYTHON) ADD_SUBDIRECTORY(python) ENDIF(BUILD_OSGPYTHON) IF (BUILD_OSGPERL) ADD_SUBDIRECTORY(perl) ENDIF(BUILD_OSGPERL) IF (BUILD_OSGJAVA) ADD_SUBDIRECTORY(java) ENDIF(BUILD_OSGJAVA) since I dont build it for any of these I am not surprised I am ending up with empty project Can you share the build setting for CMake? Thanks again Nick On Wed, May 21, 2014 at 3:54 PM, Trajce Nikolov NICK trajce.nikolov.n...@gmail.commailto:trajce.nikolov.n...@gmail.com wrote: Thanks Robert, I will give it a try. Actually all I care for now is to see the Viewer into .NET control, do not care to much of the underlying approach - but simplier, better. I had thought C# was going out of fashion with the advent of tablet and phones taking midshare and developer time... Nah, at least not in Macedonia. Here you can not find C++ job, all is .NET, C#, Java .. suddenly Thanks again
Re: [osg-users] OSG and .NET (C#)
Hi Nick, I have done this with osgSwig, which can be found here: https://code.google.com/p/osgswig/ Although it's a pain with many pitfalls, you can get working wrappers with it. These osgSwig project works even with OSG 3.0.1, 3.1.5 and 3.3.1 after getting the project to compile correctly. Generally Swig (v2.0.12) generates code for intermediate c++ dlls which are called by .Net via Pinvoke. After generation, which in my case is not error free, you probably have to correct these errors by hand in the generated C# code. Luckily this is not an endless list. Cheers, Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce Nikolov NICK Sent: Tuesday, May 20, 2014 7:07 PM To: OpenSceneGraph Users Subject: [osg-users] OSG and .NET (C#) Hi Community, in the language wrappers section the project link is broken. Where is this project now and any clue what is the status? Also, anyone have done this and willing to share hints, code? Thanks a bunch! Nick -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and .NET (C#)
Hi, osgSwig generates the .cs files but no project. I leaves it to your choice if you want to integrate the .cs files in direct way into your own project or if you want to create a .Net dll. If the latter is what you want to do, then just create a .Net dll project, drag drop the .cs files into it and compile in a second step. At some points errors will appear telling you that the override keyword is illegal. This is the result of multiple inheritance in Osg. Just delete the override keyword (at 26 locations, dont worry the compiler tells you where) and continue. For my .Net wrappers i left out osgIntrospection, as this is not needed for generating the wrappers. Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce Nikolov NICK Sent: Wednesday, May 21, 2014 12:33 PM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG and .NET (C#) Hi Carsten, thanks for the input. Here is how far I have got: I downloaded swigwin got osgswig source run CMake of osgswig, build my solution (I am on Windows Visual Studio) and got no project for osgswig I set to build osgswig with osgIntrospection. Any hints? Thanks a bunch! Nick On Wed, May 21, 2014 at 9:25 AM, Carsten Scharfe cscha...@dspace.demailto:cscha...@dspace.de wrote: Hi Nick, I have done this with osgSwig, which can be found here: https://code.google.com/p/osgswig/ Although it's a pain with many pitfalls, you can get working wrappers with it. These osgSwig project works even with OSG 3.0.1, 3.1.5 and 3.3.1 after getting the project to compile correctly. Generally Swig (v2.0.12) generates code for intermediate c++ dlls which are called by .Net via Pinvoke. After generation, which in my case is not error free, you probably have to correct these errors by hand in the generated C# code. Luckily this is not an endless list. Cheers, Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.orgmailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce Nikolov NICK Sent: Tuesday, May 20, 2014 7:07 PM To: OpenSceneGraph Users Subject: [osg-users] OSG and .NET (C#) Hi Community, in the language wrappers section the project link is broken. Where is this project now and any clue what is the status? Also, anyone have done this and willing to share hints, code? Thanks a bunch! Nick -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and .NET (C#)
Did you configure the paths to your osg includes and libs in cmake? This sounds like that cmake could not find your osg. Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce Nikolov NICK Sent: Wednesday, May 21, 2014 2:42 PM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG and .NET (C#) Thanks Carsten. The problem is that I didn't get that far. I don't have osgswig built yet, from my CMake and the VS solution for osgswig I got only three projects (all in order to build osgswig. Is this an executable???) BUILD_ALL, uninstall and ZERO_CHECK, the standard that comes with every CMake generated solution, but again no osgswig. Any hints? What I have missed? Nick On Wed, May 21, 2014 at 2:17 PM, Carsten Scharfe cscha...@dspace.demailto:cscha...@dspace.de wrote: Hi, osgSwig generates the .cs files but no project. I leaves it to your choice if you want to integrate the .cs files in direct way into your own project or if you want to create a .Net dll. If the latter is what you want to do, then just create a .Net dll project, drag drop the .cs files into it and compile in a second step. At some points errors will appear telling you that the override keyword is illegal. This is the result of multiple inheritance in Osg. Just delete the override keyword (at 26 locations, dont worry the compiler tells you where) and continue. For my .Net wrappers i left out osgIntrospection, as this is not needed for generating the wrappers. Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.orgmailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce Nikolov NICK Sent: Wednesday, May 21, 2014 12:33 PM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG and .NET (C#) Hi Carsten, thanks for the input. Here is how far I have got: I downloaded swigwin got osgswig source run CMake of osgswig, build my solution (I am on Windows Visual Studio) and got no project for osgswig I set to build osgswig with osgIntrospection. Any hints? Thanks a bunch! Nick On Wed, May 21, 2014 at 9:25 AM, Carsten Scharfe cscha...@dspace.demailto:cscha...@dspace.de wrote: Hi Nick, I have done this with osgSwig, which can be found here: https://code.google.com/p/osgswig/ Although it's a pain with many pitfalls, you can get working wrappers with it. These osgSwig project works even with OSG 3.0.1, 3.1.5 and 3.3.1 after getting the project to compile correctly. Generally Swig (v2.0.12) generates code for intermediate c++ dlls which are called by .Net via Pinvoke. After generation, which in my case is not error free, you probably have to correct these errors by hand in the generated C# code. Luckily this is not an endless list. Cheers, Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.orgmailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce Nikolov NICK Sent: Tuesday, May 20, 2014 7:07 PM To: OpenSceneGraph Users Subject: [osg-users] OSG and .NET (C#) Hi Community, in the language wrappers section the project link is broken. Where is this project now and any clue what is the status? Also, anyone have done this and willing to share hints, code? Thanks a bunch! Nick -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Weird polygons on nVidia NVS cards
Hi Robert, Thank you for your answer. I've tried and set the sharedContext member to 0 for all views, as you've suggested. The result was the same, corrupted polygons in one or more views. But now with the difference that shaders work only in one view, which is the one first created. Maybe there is still an error in initializing the views, so I've added the code used for creating a view: osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; osg::ref_ptrosg::Referenced windata = new osgViewer::GraphicsWindowWin32::WindowData(hwnd,false); CRect winRect; ::GetClientRect(hwnd,winRect); // init graphics traits traits-x = 0; traits-y = 0; traits-width = winRect.Width(); traits-height = winRect.Height(); traits-windowDecoration = false; traits-doubleBuffer = true; traits-sharedContext = 0; traits-setInheritedWindowPixelFormat = true; traits-inheritedWindowData = windata; traits-supportsResize = true; traits-useMultiThreadedOpenGLEngine = true; traits-alpha = 8; traits-red = 8; traits-green = 8; traits-blue = 8; traits-depth = 24; traits-stencil = 8; osg::ref_ptrosg::GraphicsContext gc = osg::GraphicsContext::createGraphicsContext(traits.get()); osgViewer::View *posgViewNew = new osgViewer::View; osg::DisplaySettings *posgDs = new osg::DisplaySettings; posgDs-setDefaults(); posgDs-setDisplayType(osg::DisplaySettings::MONITOR); posgDs-setDepthBuffer(true); posgDs-setStereo(false); posgDs-setDoubleBuffer(true); // and make that camera display its contents in this context posgViewNew-getCamera()-setClearMask(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT | GL_STENCIL_BUFFER_BIT); posgViewNew-getCamera()-setClearStencil(0); posgViewNew-getCamera()-setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); posgViewNew-getCamera()-setDisplaySettings(posgDs); posgViewNew-getCamera()-setGraphicsContext(gc.get()); posgViewNew-getCamera()-setViewport(0,0, winRect.Width(), winRect.Height()); On start our application creates 4 views this way, right after creating and setting up the composite viewer as single threaded. What puzzles me is that assigned shaders work only in one view and that other views have still corrupted polygons. Besides displaying the views (i.e. adding them to the composite viewer) take a long time on NVS cards. Do you have seen such behavior? We observed this on an NVS4200M and on other NVS systems. Are the drivers so bad, that only one context is supported on NVS cards? Sadly, the other approach, you've suggested, by using the view's viewports in the same window is for several reason unapplicable. Regards, Carsten. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday, August 27, 2012 3:57 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Weird polygons on nVidia NVS cards Hi Carsten, On 27 August 2012 11:57, Carsten Scharfe cscha...@dspace.de wrote: Both views share the same context. This context is created first, with no inherited window data. When I create a new view, I create a new context for this view and set the sharedContext member to the shared context. I set the inherited window data too for embedding the view in the desired window. I think you are a little confused by what is a context and what is a shared context. You description implies that you have two graphics context, the second graphics context sharing OpenGL objects with the first context (this is what a shared context means), but is still a separate graphics context. It could be that there is an issue with the viewer setup, but equally is could be an issue in the OpenGL driver with sharing GL objects between contexts. Personally I would avoid sharing contexts historically has been be problematic with some drivers, and brings up limitations in the way that you can use the OSG i.e. you can't use it multi-threaded and you have to be careful about cleanup. The OSG can handle multiple contexts just fine, just don't set the sharedContext info when setting up your new context. Alternatively just share the same graphics context with both view's viewports on the same window - this approach will lead to the best performance. Robert. ___ 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] Weird polygons on nVidia NVS cards
I'll try that out. Carsten -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, August 28, 2012 11:45 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Weird polygons on nVidia NVS cards Hi Carsten, In principle what you are doing should work, what might be wrong I can't say though. I don't use windows so can't comment on the specifics of this type of setup. The only thing I can think of that might cause one window to work but others not is for the OpenGL object management to be set up incorrectly, this should however be done for you by the OSG. As a sanity test could you try creating windows using osgViewer's window creation without using the WindowData feature. Robert. On 28 August 2012 10:34, Carsten Scharfe cscha...@dspace.de wrote: Hi Robert, Thank you for your answer. I've tried and set the sharedContext member to 0 for all views, as you've suggested. The result was the same, corrupted polygons in one or more views. But now with the difference that shaders work only in one view, which is the one first created. Maybe there is still an error in initializing the views, so I've added the code used for creating a view: osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; osg::ref_ptrosg::Referenced windata = new osgViewer::GraphicsWindowWin32::WindowData(hwnd,false); CRect winRect; ::GetClientRect(hwnd,winRect); // init graphics traits traits-x = 0; traits-y = 0; traits-width = winRect.Width(); traits-height = winRect.Height(); traits-windowDecoration = false; traits-doubleBuffer = true; traits-sharedContext = 0; traits-setInheritedWindowPixelFormat = true; traits-inheritedWindowData = windata; traits-supportsResize = true; traits-useMultiThreadedOpenGLEngine = true; traits-alpha = 8; traits-red = 8; traits-green = 8; traits-blue = 8; traits-depth = 24; traits-stencil = 8; osg::ref_ptrosg::GraphicsContext gc = osg::GraphicsContext::createGraphicsContext(traits.get()); osgViewer::View *posgViewNew = new osgViewer::View; osg::DisplaySettings *posgDs = new osg::DisplaySettings; posgDs-setDefaults(); posgDs-setDisplayType(osg::DisplaySettings::MONITOR); posgDs-setDepthBuffer(true); posgDs-setStereo(false); posgDs-setDoubleBuffer(true); // and make that camera display its contents in this context posgViewNew-getCamera()-setClearMask(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT | GL_STENCIL_BUFFER_BIT); posgViewNew-getCamera()-setClearStencil(0); posgViewNew-getCamera()-setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); posgViewNew-getCamera()-setDisplaySettings(posgDs); posgViewNew-getCamera()-setGraphicsContext(gc.get()); posgViewNew-getCamera()-setViewport(0,0, winRect.Width(), winRect.Height()); On start our application creates 4 views this way, right after creating and setting up the composite viewer as single threaded. What puzzles me is that assigned shaders work only in one view and that other views have still corrupted polygons. Besides displaying the views (i.e. adding them to the composite viewer) take a long time on NVS cards. Do you have seen such behavior? We observed this on an NVS4200M and on other NVS systems. Are the drivers so bad, that only one context is supported on NVS cards? Sadly, the other approach, you've suggested, by using the view's viewports in the same window is for several reason unapplicable. Regards, Carsten. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday, August 27, 2012 3:57 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Weird polygons on nVidia NVS cards Hi Carsten, On 27 August 2012 11:57, Carsten Scharfe cscha...@dspace.de wrote: Both views share the same context. This context is created first, with no inherited window data. When I create a new view, I create a new context for this view and set the sharedContext member to the shared context. I set the inherited window data too for embedding the view in the desired window. I think you are a little confused by what is a context and what is a shared context. You description implies that you have two graphics context, the second graphics context sharing OpenGL objects with the first context (this is what a shared context means), but is still a separate graphics context. It could be that there is an issue with the viewer setup, but equally is could be an issue in the OpenGL driver with sharing GL objects between contexts
Re: [osg-users] Weird polygons on nVidia NVS cards
I tried it out now. Windows are appearing, and shaders work on each view. But polygon corruption still persists. It seems to me that this is a driver issue. Carsten. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Carsten Scharfe Sent: Tuesday, August 28, 2012 11:48 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Weird polygons on nVidia NVS cards I'll try that out. Carsten -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, August 28, 2012 11:45 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Weird polygons on nVidia NVS cards Hi Carsten, In principle what you are doing should work, what might be wrong I can't say though. I don't use windows so can't comment on the specifics of this type of setup. The only thing I can think of that might cause one window to work but others not is for the OpenGL object management to be set up incorrectly, this should however be done for you by the OSG. As a sanity test could you try creating windows using osgViewer's window creation without using the WindowData feature. Robert. On 28 August 2012 10:34, Carsten Scharfe cscha...@dspace.de wrote: Hi Robert, Thank you for your answer. I've tried and set the sharedContext member to 0 for all views, as you've suggested. The result was the same, corrupted polygons in one or more views. But now with the difference that shaders work only in one view, which is the one first created. Maybe there is still an error in initializing the views, so I've added the code used for creating a view: osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; osg::ref_ptrosg::Referenced windata = new osgViewer::GraphicsWindowWin32::WindowData(hwnd,false); CRect winRect; ::GetClientRect(hwnd,winRect); // init graphics traits traits-x = 0; traits-y = 0; traits-width = winRect.Width(); traits-height = winRect.Height(); traits-windowDecoration = false; traits-doubleBuffer = true; traits-sharedContext = 0; traits-setInheritedWindowPixelFormat = true; traits-inheritedWindowData = windata; traits-supportsResize = true; traits-useMultiThreadedOpenGLEngine = true; traits-alpha = 8; traits-red = 8; traits-green = 8; traits-blue = 8; traits-depth = 24; traits-stencil = 8; osg::ref_ptrosg::GraphicsContext gc = osg::GraphicsContext::createGraphicsContext(traits.get()); osgViewer::View *posgViewNew = new osgViewer::View; osg::DisplaySettings *posgDs = new osg::DisplaySettings; posgDs-setDefaults(); posgDs-setDisplayType(osg::DisplaySettings::MONITOR); posgDs-setDepthBuffer(true); posgDs-setStereo(false); posgDs-setDoubleBuffer(true); // and make that camera display its contents in this context posgViewNew-getCamera()-setClearMask(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT | GL_STENCIL_BUFFER_BIT); posgViewNew-getCamera()-setClearStencil(0); posgViewNew-getCamera()-setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); posgViewNew-getCamera()-setDisplaySettings(posgDs); posgViewNew-getCamera()-setGraphicsContext(gc.get()); posgViewNew-getCamera()-setViewport(0,0, winRect.Width(), winRect.Height()); On start our application creates 4 views this way, right after creating and setting up the composite viewer as single threaded. What puzzles me is that assigned shaders work only in one view and that other views have still corrupted polygons. Besides displaying the views (i.e. adding them to the composite viewer) take a long time on NVS cards. Do you have seen such behavior? We observed this on an NVS4200M and on other NVS systems. Are the drivers so bad, that only one context is supported on NVS cards? Sadly, the other approach, you've suggested, by using the view's viewports in the same window is for several reason unapplicable. Regards, Carsten. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday, August 27, 2012 3:57 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Weird polygons on nVidia NVS cards Hi Carsten, On 27 August 2012 11:57, Carsten Scharfe cscha...@dspace.de wrote: Both views share the same context. This context is created first, with no inherited window data. When I create a new view, I create a new context for this view and set the sharedContext member to the shared context. I set the inherited window data too for embedding the view in the desired window. I think you
Re: [osg-users] Weird polygons on nVidia NVS cards
Hi Robert, Both views share the same context. This context is created first, with no inherited window data. When I create a new view, I create a new context for this view and set the sharedContext member to the shared context. I set the inherited window data too for embedding the view in the desired window. Carsten. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday, August 27, 2012 11:41 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Weird polygons on nVidia NVS cards HI Carsten, Does the new view have the two views sharing the same graphics context, or are you creating a new context? If you are creating a new context how are your creating the new context? Robert. On 27 August 2012 10:13, Carsten Scharfe cscha...@dspace.demailto:cscha...@dspace.de wrote: Hi. I've come across a strange behaviour regarding NVS cards from nVidia. On some occasions I get corrupted polygons, when initializing and showing a new view, which is rendered by a composite viewer. I've attached 2 screenshots showing the corrupted rendering and how it should be. Strange enough, this behavior can be observed only on NVS cards. Quadro Fx, Quadro and GeForce cards do not show this issue. Has anybody had the same or similar problem and can give me some hints on what went wrong? I definitely need help here. I use OSG 3.0 on Win7. The scene is rendered with some shaders. Our application has an edit mode for scene assembly integrated, which, if activated, creates a new view for editing purposes and adds this view to the composite viewer. Our edit mode is rendered in a different window and thus requires it's own view. The polygon corruption occurs on this occasion. If the edit mode is deactivated and activated again (the view is only created once on the first activation) the rendering is as expected. Any comment is welcome. Thanks in advance. Carsten The correctd rendering: Fehler! Es wurde kein Dateiname angegeben. The corrupted rendering: Fehler! Es wurde kein Dateiname angegeben. ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto: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] Weird polygons on nVidia NVS cards
Oh. I forgot to mention that I'm using the composite viewer in single threaded mode. Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Carsten Scharfe Sent: Monday, August 27, 2012 12:58 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Weird polygons on nVidia NVS cards Hi Robert, Both views share the same context. This context is created first, with no inherited window data. When I create a new view, I create a new context for this view and set the sharedContext member to the shared context. I set the inherited window data too for embedding the view in the desired window. Carsten. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday, August 27, 2012 11:41 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Weird polygons on nVidia NVS cards HI Carsten, Does the new view have the two views sharing the same graphics context, or are you creating a new context? If you are creating a new context how are your creating the new context? Robert. On 27 August 2012 10:13, Carsten Scharfe cscha...@dspace.demailto:cscha...@dspace.de wrote: Hi. I've come across a strange behaviour regarding NVS cards from nVidia. On some occasions I get corrupted polygons, when initializing and showing a new view, which is rendered by a composite viewer. I've attached 2 screenshots showing the corrupted rendering and how it should be. Strange enough, this behavior can be observed only on NVS cards. Quadro Fx, Quadro and GeForce cards do not show this issue. Has anybody had the same or similar problem and can give me some hints on what went wrong? I definitely need help here. I use OSG 3.0 on Win7. The scene is rendered with some shaders. Our application has an edit mode for scene assembly integrated, which, if activated, creates a new view for editing purposes and adds this view to the composite viewer. Our edit mode is rendered in a different window and thus requires it's own view. The polygon corruption occurs on this occasion. If the edit mode is deactivated and activated again (the view is only created once on the first activation) the rendering is as expected. Any comment is welcome. Thanks in advance. Carsten The correctd rendering: Fehler! Es wurde kein Dateiname angegeben. The corrupted rendering: Fehler! Es wurde kein Dateiname angegeben. ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto: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
[osg-users] Problem with loading 3d-models with asian characters in file name.
Hi, I hope somebody can help me out with this nasty problem. I try to load model file (e.g. a collada file) which has some asian characters in its file name. Although I’ve compiled Osg with OSG_USE_UFT8_FILENAME set to true, no model is loaded. osgDB::readNodeFile just returns an empty node as result, saying that the file was not found. A filename like E:\3dlibnew\$龙\龙.dae is received as E:\3dlibnew\$?\?.dae even in our own application. Do I need to do additional conversions? Please help me. Any advice is welcome. I’m using Osg 3.0 on Win7. Regards, Carsten ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Questions on AutoTransform
Hi, I'm having to views, one normal 3d view and one top view with an camera icon, that represents the camera of the 3d view (orientation and position). The top view (with an orthogonal projection) kann be zoomed in and zoomed out. Of course, zooming out the top view will scale the camera icon, which I want to prevent. The camera icon shall have the same size at all times. Therefore I want to use the Autotransform, but I do not get the expected results. Here's how I set up the icon geometry with the AutoTransform: MatrixTransform | | AutoTransform | | IconGeometry (several Geodes) The MatrixTransform controls the orientation an position of the icon. The AutoTransform shall do the automatic scaling, so that the icon always stays the same size. Here's an excerpt from the initialization code: cameraIcon = new osg::MatrixTransform; cameraIcon-setMatrix(DsTOsgMatrix4::translate(2, g_fCameraIconHeight, 0)); osg::ref_ptrosg::AutoTransform camAutoScale = new osg::AutoTransform; camAutoScale-setAutoScaleToScreen(true); cameraIcon-addChild(camAutoScale); camAutoScale-addChild(camBody); camAutoScale-addChild(camMoveHandle); camAutoScale-addChild(camRotateHandle); The effect I'm getting is that the icon is not visible. If I comment out the line where I set the autoscaletoscreen as true, display of the icon is normal. I guess I'm missing something in the setup of the AutoTransform. I'm using Osg 3.0.0. Zooming is done by changing the orthogonal projection matrix of the view's camera appriately. I'm using a right handed coordinate system with the z-axis as up-axis. Do I have to set special axis in the AutoTransform? Does the position has to be set in the AutoTransform, when the icon's position changes? Can somebody help me out? Any hints are welcome. Cheers, Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::Viewer with independant slave cameras
Thanks for pointing me to the example, Robert. That helped. Obviously, I was too blind to see the part in the example. Cheers, Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday, October 10, 2011 4:45 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Using osgViewer::Viewer with independant slave cameras Hi Carsten, On Mon, Oct 10, 2011 at 3:32 PM, Carsten Scharfe cscha...@dspace.de wrote: Any idea on how I could convince each view of a composite viewer to share the graphics context? CompositeViewer works just fine with a sharing a context between all views. The osgcompositeviewer does *EXACTLY* this. Please read the example. Robert. ___ 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
[osg-users] Using osgViewer::Viewer with independant slave cameras
Hi! I've search the archives, but could not find any posts on this topic. I want to setup a osgViewer::Viewer with 4 cameras, which can be controlled independently from the master camera, if the user click-drags in the corresponding viewport. Creating the viewer and 4 slaves is not a problem, but to manipulate each cam separately. I have an implementation of my project with the composite viewer, which works, but due to some technical implications, I want to switch to a single viewer. I tried to set setAllowEventFocus(true) to the master and slave cams, but that did not work. Can anybody give me a hint on how to setup the viewer correctly or point me to an example where this is done? Cheers, Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::Viewer with independant slave cameras
Hi Robert, Yes, that's what I did first. But unfortunately my 4 views have to be embededded in windows (derived from CDocuemntView on Windows). Creating a view for each window also creates a new graphics context, since each view has its own window handle. Therefore much memory is consumed, which blows my app, if I load a bigger scene (~250k polys, on a Quadro 580FX). Any idea on how I could convince each view of a composite viewer to share the graphics context? Regards, Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday, October 10, 2011 4:19 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Using osgViewer::Viewer with independant slave cameras Hi Casten, If you have 4 independent views then you should use the CompositeViewer class. osgViewer::Viewer is for a single View. See the osgcomposite viewer example. Robert. On Mon, Oct 10, 2011 at 2:37 PM, Carsten Scharfe cscha...@dspace.de wrote: Hi! I've search the archives, but could not find any posts on this topic. I want to setup a osgViewer::Viewer with 4 cameras, which can be controlled independently from the master camera, if the user click-drags in the corresponding viewport. Creating the viewer and 4 slaves is not a problem, but to manipulate each cam separately. I have an implementation of my project with the composite viewer, which works, but due to some technical implications, I want to switch to a single viewer. I tried to set setAllowEventFocus(true) to the master and slave cams, but that did not work. Can anybody give me a hint on how to setup the viewer correctly or point me to an example where this is done? Cheers, Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] compiling trunk of osgIntrospection with osg3.0with vs2010
Hi Ryan, thank you very much for directing me to cppintrospection. This helped me a lot. I even got the most osg library wrappers compiled after generation of the osg wrappers and fixing some minor problems like: - adding libraries to link against, like cppinstrospection.lib, osg.lib and OpenThreads.lib (they somehow are missing in the wrapper libs) - adding an #include osg/observer_ptr where it was reported as unknown identifier - correcting some TYPE_NAME_ALIASES dealing with function pointers, e.g.: TYPE_NAME_ALIAS(void*(osgDB::ObjectWrapper*), osgDB::RegisterWrapperProxy::AddPropFunc) (was generated as TYPE_NAME_ALIAS(void(*, osgDB::RegisterWrapperProxy::AddPropFunc) , with a closing bracket missing ) But I'm again stuck at compiling osgDB wrapper, with the following error message: 1-- Build started: Project: osgwrapper_osgDB, Configuration: Release Win32 -- 1 OutputStream.cpp 1D:\development\visual studio 2010\VC\include\sstream(724): error C2248: 'std::basic_ios_Elem,_Traits::basic_ios' : cannot access private member declared in class 'std::basic_ios_Elem,_Traits' 1 with 1 [ 1 _Elem=char, 1 _Traits=std::char_traitschar 1 ] 1 D:\development\visual studio 2010\VC\include\ios(176) : see declaration of 'std::basic_ios_Elem,_Traits::basic_ios' 1 with 1 [ 1 _Elem=char, 1 _Traits=std::char_traitschar 1 ] 1 This diagnostic occurred in the compiler generated function 'std::basic_stringstream_Elem,_Traits,_Alloc::basic_stringstream(const std::basic_stringstream_Elem,_Traits,_Alloc )' 1 with 1 [ 1 _Elem=char, 1 _Traits=std::char_traitschar, 1 _Alloc=std::allocatorchar 1 ] I cannot track that down, to correct it. Any advice or help is welcome. Thanks in advance. Cheers, Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ryan Pavlik Sent: Monday, August 01, 2011 7:01 PM To: OpenSceneGraph Users Subject: Re: [osg-users] compiling trunk of osgIntrospection with osg3.0with vs2010 I've gotten fairly close to building this, even using the Clang compiler. You'll want to get my fork of the 'cppintrospection' library, which is just a name-change of osgIntrospection with some updates. https://github.com/rpavlik/cppintrospection There were a number of changes to the config needed, and I made a number of other fixes in the wrapper generator, as well as the library itself. This improved version also includes a single-step generate and build of wrappers, and also reduces the size of the wrapper libraries by reducing the number of reflection template instantiations required. I've used it successfully with the 2.8 branch and the Clang compiler on Linux - haven't tested it on other platforms yet but I've been careful to keep it cross-platform. Ryan On Mon, Aug 1, 2011 at 8:46 AM, Carsten Scharfe cscha...@dspace.demailto:cscha...@dspace.de wrote: Hi All, I'm trying to compile osgIntrospection with OSG 3.0.0 in Visual Studio 2010. While osgIntrospection compiles, the osgWrappers (e.g. Wrapper osg) do not. It seem to be that VS2010 has severe Problems with finding operator-methods of classes such as string or map. Maybe this is a template instatiation issue. The error messages I'll get from VS2010: 1E:\OpenSceneGraph-3.0.0\include\osg/State(2477): error C2784: 'bool std::operator (const std::move_iterator_RanIt ,const std::move_iterator_RanIt2 )' : could not deduce template argument for 'const std::move_iterator_RanIt ' from 'const std::string' 1 D:\development\visual studio 2010\VC\include\iterator(371) : see declaration of 'std::operator ' or 1E:\OpenSceneGraph-3.0.0\osgIntrospection\include\osgIntrospection/ReaderWriter(217): error C2678: binary '' : no operator found which takes a left-hand operand of type 'std::istream' (or there is no acceptable conversion) 1. D:\development\visual studio 2010\VC\include\istream(1053): could be 'std::basic_istream_Elem,_Traits std::operator std::char_traitschar(std::basic_istream_Elem,_Traits ,signed char *)' [found using argument-dependent lookup] In need some hints or help to sort this out. I'm definitely stuck. Can somebody help me please? Any advice is welcome, Cheers Carsten ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State
[osg-users] compiling trunk of osgIntrospection with osg3.0 with vs2010
Hi All, I'm trying to compile osgIntrospection with OSG 3.0.0 in Visual Studio 2010. While osgIntrospection compiles, the osgWrappers (e.g. Wrapper osg) do not. It seem to be that VS2010 has severe Problems with finding operator-methods of classes such as string or map. Maybe this is a template instatiation issue. The error messages I'll get from VS2010: 1E:\OpenSceneGraph-3.0.0\include\osg/State(2477): error C2784: 'bool std::operator (const std::move_iterator_RanIt ,const std::move_iterator_RanIt2 )' : could not deduce template argument for 'const std::move_iterator_RanIt ' from 'const std::string' 1 D:\development\visual studio 2010\VC\include\iterator(371) : see declaration of 'std::operator ' or 1E:\OpenSceneGraph-3.0.0\osgIntrospection\include\osgIntrospection/ReaderWriter(217): error C2678: binary '' : no operator found which takes a left-hand operand of type 'std::istream' (or there is no acceptable conversion) 1 D:\development\visual studio 2010\VC\include\istream(1053): could be 'std::basic_istream_Elem,_Traits std::operator std::char_traitschar(std::basic_istream_Elem,_Traits ,signed char *)' [found using argument-dependent lookup] In need some hints or help to sort this out. I'm definitely stuck. Can somebody help me please? Any advice is welcome, Cheers Carsten ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] camera/cameraview questions
hi robert, thanx for your answer. it helped me out. but how do i accumulate the matrix efficiently? cheers, carsten Zitat von Robert Osfield [EMAIL PROTECTED]: Hi Carsten, The CameraView node is meant to be placed within the scene graph as a leaf node, the accumulated transform matrix down to the CameraView provides its final position in space just like any other node. CameraView is a passive object, effectively a marker that you put into the scene graph it doesn't do any rendering itself. One would use it for marking various view points in the scene, or for creating a camera view that tracks a node in the scene i.e. a car. To render the view one must get the the accumulated view matrix (the world to local transform) and pass it onto the viewers Camera setting it's view matrix. Right now there isn't a convenience method built into osgViewer for doing this, so you'll need to manage this in your own application. You could use the NodeTrackerManipulator for to attach to the CameraView, but this manipulator is general purpose and doesn't know about some of the specific features of CameraView. CameraView isn't widely used, which is why it hasn't been wired up in osgViewer, perhaps further down the line we'll revisit this, feel free to contribute to this effort. Robert. On 8/28/07, Carsten Scharfe [EMAIL PROTECTED] wrote: hi there, do i understand the functionality of the cameraview node correct? i assume, that cameraview is used to position the camera (and animate, of course) within the scene, without having to manipulate view matrices directly. but then how do i retrieve the actual viewing matrix, if the camera is positioned by a cameraview? what happens if geometry is attached as a child of a camera node? maybe someone can help me out? cheers, carsten scharfe ___ 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 -- Carsten Scharfe Student of Computer Science University of Paderborn AR/VR TeamFuerstenallee 11 Heinz Nixdorf Institute 33102 Paderborn (Germany) -- Fon: 05251/606229(HNI - VR Lab) E-Mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- The dragon has woken up ! -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] camera/cameraview questions
hi there, do i understand the functionality of the cameraview node correct? i assume, that cameraview is used to position the camera (and animate, of course) within the scene, without having to manipulate view matrices directly. but then how do i retrieve the actual viewing matrix, if the camera is positioned by a cameraview? what happens if geometry is attached as a child of a camera node? maybe someone can help me out? cheers, carsten scharfe ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
