Re: [osg-users] (no subject)
Hi Oran, When optimizing OSG applications most of the task is really about optimizing the scene graph to address bottlenecks. You've taken the first step in look at high level cull, draw dispatch (the OSG's draw traversal dispatch data into the OpenGL FIFO) and draw GPU stats, and listing the various scene graph stats that cause the performance issues. The next step is working out how to address the performance issues, the first step in this is to look at which element of the frame is longest and start there as this is likely the most fruitful place to achieve gains. In your case I expect each of the high cull, draw dispatch and draw GPU are all linked to how fine grained the scene graph is set up - you have large number of scene graph level objects relative to the number vertices and primitives being dispatched. The most effective way to improve performance will be merge osg::Geometry and with it simplify the scene graph structure above it. You can only merge osg::Geometry that share the same state so this may require some adjustment to how you manage the state of objects. Moving state changes from osg::StateSet's/osg::Material into the osg::Geometry as per vertex data/per PrimitiveSet data may the be the solution, it might be that shaders might be need to help with this. For picking, if you merge a large number of osg::Geometry then CPU based intersection testing may end up being slower, to resolve this you can build osg::KdTree for the osg::Geometry and then the IntersectionVisitor will be able to use the KdTree to speed up intersection. If you want to pick patches then you may want to keep each patch in it's own osg::PrimitiveSet rather than merging these. However, merging osg::PrimitiveSet is something that will help performance, just like merging osg::Geometry will do. For modern graphics hardware it's typically best to just use a single osg::DrawElementsUShort/UInt with GL_TRIANGLES mode for all the triangles in an osg::Geometry rather than using triangle strips. So if you are wanting to pick and edit patches that you once managed at the osg::Geometry level, then you could merge all the triangles in the original osg::Geometry into a single osg::DrawElementUShort/UInt and then merge the osg::Geometry data whilst not further merging any of the primitives sets. The osgUtil::Optimizer class has a collected of visitors that can help with merging state and geometries, and the osgUtil::MeshOptimizers can also help with generating efficient meshes. Robert On 2 May 2018 at 01:31, Oran Wallacewrote: > > Hi All, > > Been using OSG for a while and have learned a lot and enjoyed it. I > currently have an application with uses OSG and Qt for displaying a highly > detailed model. A database is loaded which may cause colors in the model to > change or additional geometries to be generated. > > My OSG viewport is a class which subclasses from QWidget and > osgViewer::CompisiteViewer and is embedded into a QMainWindow. This works > fine so I've stuck with it. The application can perform most CAD-like > operations on the model with OSG. > > I've finally encountered a model which brings my application to around 1-2 > fps while interacting with it. I know there are various techniques used to > help with performance but also understand the approach depends on the > situation. I'm currently considering a major rewrite. > > Scene Details: > 1. 540k vertices > 2. 81000 drawables > 3. 77000 sorted drawables > 4. 81000 fast drawables > 5. 81000 primitive sets > 6. 10 triangles > 7. 37000 quad > 8. 181000 polygon ( probably hurting a lot) > 9. 26000 unique state sets > 10. 73000 instance state sets > 11. 28000 groups > > Cull: 113.50, Draw: 390, GPU: 355 (never seen values this high on the > forums) > Additionally the graph doesn't seem to rendering correctly; the largest > "bar" is Cull and last ~10% is the Draw, which doesnt seem to match the > values. (Probably because a single frame takes so long?) > > Implementation Details: > 1. I am orthographic project as it is a "CAD" style application. > 2. Currently all objects are within Geode->Geometry nodes, each with > their own vertex, color, and normal arrays. > 3. The main "mode" of the application is a "ghosted" mode which is > applied to the walls of the model. Each wall has an osg::Material set to it > and blending turned on. > 4. All objects are pickable and hold a variety of property data > (extracted from the models file or the database). I have implemented > "picking" using the PickHandler::pick example and code. > 5. A user often views the whole model from afar interacting with other > Qt widgets and watch how the scene changes, occasionally they will zoom in > on a section but are never "inside" the model. I can clearly see when view > frustum culling is working when zooming in. > 6. My graph is VERY flat. Nearly all object are attached to the root
Re: [osg-users] (no subject)
Hi Michael, Nice job, will certainly use it! Cheers, Raymond On 7/1/2017 10:04 AM, Robert Osfield wrote: Great work Michael :-) On 30 June 2017 at 18:16, michael kapelkowrote: Hi. TL;DR Sample OpenSceneGraph application in Web: https://ogstudio.github.io/openscenegraph-cross-platform-guide/ Give it a try! -- Official -- I've finished my work on the OpenSceneGraph cross-platform guide: https://github.com/OGStudio/openscenegraph-cross-platform-guide It contains step-by-step instructions with screenshots how to build and run sample OpenSceneGraph application under the following platforms: * Linux * macOS * Windows * Android * iOS * Web It also contains YouTube and downloadable (MP4) videos depicting every step. I hope this guide fills the gap of good cross-platform documentation for OpenSceneGraph. I plan to maintain it and update whenever something changes in the build process. Drop me a line if anything becomes outdated and/or I have missed it. -- Personal -- Last year once I got the first taste of my own game editor results ( opengamestudio.org ), I realized supporting only desktop in 2017 is a no-go. So I started to research Android support. Since OpenSceneGraph Android samples are of pre-AndroidStudio era and I was a newbie in Android native development, I spent literally several months trying to get OpenSceneGraph render under Android. Then came iOS and Web, which were just a piece of cake, compared to Android. I realized that there may be many people who waste as many months just to get OpenSceneGraph to mobile and web. That's why I decided to share the knowledge in the form of detailed tutorials with screenshots and videos of the whole process. I hope this saves you precious time! ___ 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 --- This email has been checked for viruses by AVG. http://www.avg.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Great work Michael :-) On 30 June 2017 at 18:16, michael kapelkowrote: > Hi. > > TL;DR Sample OpenSceneGraph application in Web: > https://ogstudio.github.io/openscenegraph-cross-platform-guide/ > Give it a try! > > -- Official -- > > I've finished my work on the OpenSceneGraph cross-platform guide: > https://github.com/OGStudio/openscenegraph-cross-platform-guide > > It contains step-by-step instructions with screenshots how to build > and run sample OpenSceneGraph application under the following > platforms: > * Linux > * macOS > * Windows > * Android > * iOS > * Web > > It also contains YouTube and downloadable (MP4) videos depicting every step. > > I hope this guide fills the gap of good cross-platform documentation > for OpenSceneGraph. > I plan to maintain it and update whenever something changes in the > build process. Drop me a line if anything becomes outdated and/or I > have missed it. > > -- Personal -- > > Last year once I got the first taste of my own game editor results ( > opengamestudio.org ), I realized supporting only desktop in 2017 is a > no-go. So I started to research Android support. > Since OpenSceneGraph Android samples are of pre-AndroidStudio era and > I was a newbie in Android native development, I spent literally > several months trying to get OpenSceneGraph render under Android. > Then came iOS and Web, which were just a piece of cake, compared to Android. > I realized that there may be many people who waste as many months just > to get OpenSceneGraph to mobile and web. That's why I decided to share > the knowledge in the form of detailed tutorials with screenshots and > videos of the whole process. > > I hope this saves you precious time! > ___ > 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] (no subject)
Hi Grendah, On 23 Apr 2016, at 15:35 , Grendah Garidiwrote: > hi, I want to use Qt with OSG(2.9.12_x86VC2008) and I need a Binaries > library of osg version 3.x.x do you perhaps want to consider installing all dependencies needed to build OSG via MSYS2 [1] and start using the MinGW toolchain instead of Microsoft’s Visual C++? Greets, Marko [1] http://msys2.github.io/___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Hi Anders, There is a new mechanism for managing clean up of GL objects, which in theory should help improve management of lifetimes of GL objects. The warning suggests that something is try to do GL call after the context is cleaned up, I don't know yet if this is a bug in the new code or whether the new code is just revealling an old bug elsewhere. Could you be more specific of how to reproduce the problem as there isn't an --ssm option supported by the osgviewer example. Robert. On 4 February 2016 at 09:05, Anders Backmanwrote: > Hi all. > > Trying OSG 3.5.1 and I have started to get some problems with objects > (osg::Program/osg::Shaders etc.) being de-allocated after context is > destroyed: > > Error: OpenGL version test failed, requires valid graphics context. > > > Sometime it crasches sometimes it just print the warning. > > I can reproduce it with osgViewer --ssm > > The only solution so far has been to keep a static reference to the camera > in the scene, which feels a lot like a hack. > The same code worked in 3.4.0. So as you wrote in an earlier post, this > probably reveals something that was not deallocated before. > > As soon as the viewer is destroyed, it takes the camera with it. Hence the > Context is also destroyed. > > Not sure how to handle this in an general way. > > /Anders > > > -- > __ > Anders Backman, HPC2N > 90187 Umeå University, Sweden > and...@cs.umu.se http://www.hpc2n.umu.se > Cell: +46-70-392 64 67 > > ___ > 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] (no subject)
Yep sorry. I was having some (other) issue where text was not rendered when I had enabled shadows, so I was messing with osgViewer.cpp copying sample code from osgShadow there. The example that reveals the issue at shutdown is plainly osgShadow.cpp Output: osgshadow.exe --window 0 0 1024 768 FOV is 29.1484 Error: OpenGL version test failed, requires valid graphics context. And a crasch. Interestingly only if you first move the camera (left mouse move) in the graphics window. If you do not interact with the scene, it only show the error message. /Anders On Thu, Feb 4, 2016 at 11:57 AM, Robert Osfieldwrote: > Hi Anders, > > There is a new mechanism for managing clean up of GL objects, which in > theory should help improve management of lifetimes of GL objects. > > The warning suggests that something is try to do GL call after the > context is cleaned up, I don't know yet if this is a bug in the new > code or whether the new code is just revealling an old bug elsewhere. > > Could you be more specific of how to reproduce the problem as there > isn't an --ssm option supported by the osgviewer example. > > Robert. > > > On 4 February 2016 at 09:05, Anders Backman wrote: > > Hi all. > > > > Trying OSG 3.5.1 and I have started to get some problems with objects > > (osg::Program/osg::Shaders etc.) being de-allocated after context is > > destroyed: > > > > Error: OpenGL version test failed, requires valid graphics context. > > > > > > Sometime it crasches sometimes it just print the warning. > > > > I can reproduce it with osgViewer --ssm > > > > The only solution so far has been to keep a static reference to the > camera > > in the scene, which feels a lot like a hack. > > The same code worked in 3.4.0. So as you wrote in an earlier post, this > > probably reveals something that was not deallocated before. > > > > As soon as the viewer is destroyed, it takes the camera with it. Hence > the > > Context is also destroyed. > > > > Not sure how to handle this in an general way. > > > > /Anders > > > > > > -- > > __ > > Anders Backman, HPC2N > > 90187 Umeå University, Sweden > > and...@cs.umu.se http://www.hpc2n.umu.se > > Cell: +46-70-392 64 67 > > > > ___ > > 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 > -- __ Anders Backman, HPC2N 90187 Umeå University, Sweden and...@cs.umu.se http://www.hpc2n.umu.se Cell: +46-70-392 64 67 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Seems that this actually caused a lot more problem than I first thought... The fact that you need to have a valid reference while tearing down nodes, means that our system with plugins (dll:s loaded etc) now causes problems. The Camera it self, has references to a scene, states, (Renderer) etc, and if I keep a reference of the Camera to last, I get crashes when the camera destructor is called, due to the fact that most of the nodes, shaders, programs where created (allocated) in dll:s that has already been unloaded. So to recap: I need a context when a node is removed (if the node contains for example a shader/program). If I keep a reference to the Camera (hence the context), the camera also keep references to just about everything I put into the scenegraph, meaning that I delay the destruction of objects very late. Right now I do not really see a solution for this. It was working in 3.4.0. /A On Thu, Feb 4, 2016 at 12:25 PM, Anders Backmanwrote: > Yep sorry. I was having some (other) issue where text was not rendered > when I had enabled shadows, so I was messing with osgViewer.cpp copying > sample code from osgShadow there. > > The example that reveals the issue at shutdown is plainly osgShadow.cpp > > > Output: > > osgshadow.exe --window 0 0 1024 768 > FOV is 29.1484 > Error: OpenGL version test failed, requires valid graphics context. > > And a crasch. Interestingly only if you first move the camera (left mouse > move) in the graphics window. > If you do not interact with the scene, it only show the error message. > > /Anders > > > > On Thu, Feb 4, 2016 at 11:57 AM, Robert Osfield > wrote: > >> Hi Anders, >> >> There is a new mechanism for managing clean up of GL objects, which in >> theory should help improve management of lifetimes of GL objects. >> >> The warning suggests that something is try to do GL call after the >> context is cleaned up, I don't know yet if this is a bug in the new >> code or whether the new code is just revealling an old bug elsewhere. >> >> Could you be more specific of how to reproduce the problem as there >> isn't an --ssm option supported by the osgviewer example. >> >> Robert. >> >> >> On 4 February 2016 at 09:05, Anders Backman wrote: >> > Hi all. >> > >> > Trying OSG 3.5.1 and I have started to get some problems with objects >> > (osg::Program/osg::Shaders etc.) being de-allocated after context is >> > destroyed: >> > >> > Error: OpenGL version test failed, requires valid graphics context. >> > >> > >> > Sometime it crasches sometimes it just print the warning. >> > >> > I can reproduce it with osgViewer --ssm >> > >> > The only solution so far has been to keep a static reference to the >> camera >> > in the scene, which feels a lot like a hack. >> > The same code worked in 3.4.0. So as you wrote in an earlier post, this >> > probably reveals something that was not deallocated before. >> > >> > As soon as the viewer is destroyed, it takes the camera with it. Hence >> the >> > Context is also destroyed. >> > >> > Not sure how to handle this in an general way. >> > >> > /Anders >> > >> > >> > -- >> > __ >> > Anders Backman, HPC2N >> > 90187 Umeå University, Sweden >> > and...@cs.umu.se http://www.hpc2n.umu.se >> > Cell: +46-70-392 64 67 >> > >> > ___ >> > 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 >> > > > > -- > __ > Anders Backman, HPC2N > 90187 Umeå University, Sweden > and...@cs.umu.se http://www.hpc2n.umu.se > Cell: +46-70-392 64 67 > -- __ Anders Backman, HPC2N 90187 Umeå University, Sweden and...@cs.umu.se http://www.hpc2n.umu.se Cell: +46-70-392 64 67 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Hi Anders, On 4 February 2016 at 13:19, Robert Osfieldwrote: > However, let me investigate the bug at my end. This should clarify > things. I haven't had a chance to investigate yet as I've been > testing and checking a block of work this morning. I have tracked the problem down to the various osgShadow::ShadowTechnique not implementing the resizeGLObjects() and releaseGLObjects() methods that they should have been implementing all along, this is a bug in these classes, which have been revealed by the changes to the core OSG w.r.t release GL objects. Fixes for these ommissions is something I'm currently working on. These changes would be appropriate to older versions of the OSG as well as. I will complete these fixes and get them checked in, once I do I'll update this thread. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Hi Anders, On 4 February 2016 at 13:03, Anders Backmanwrote: > Seems that this actually caused a lot more problem than I first thought... > > The fact that you need to have a valid reference while tearing down nodes, > means that our system with plugins (dll:s loaded etc) now causes problems. > The Camera it self, has references to a scene, states, (Renderer) etc, and > if I keep a reference of the Camera to last, I get crashes when the camera > destructor is called, due to the fact that most of the nodes, shaders, > programs where created (allocated) in dll:s that has already been unloaded. > > > So to recap: > > I need a context when a node is removed (if the node contains for example a > shader/program). > If I keep a reference to the Camera (hence the context), the camera also > keep references to just about everything I put into the scenegraph, meaning > that I delay the destruction of objects very late. I wouldn't worry to much right now as I haven't yet worked out what is going wrong in your case. The changes to the core OSG aren't meant to cause new restrictions on usage. The only case where we might not be able to retain support for is if there was originally buggy code that was doing things wrong and somehow by luck didn't cause problems now causes problems. For the later case we need to find the problem in client code. However, let me investigate the bug at my end. This should clarify things. I haven't had a chance to investigate yet as I've been testing and checking a block of work this morning. > Right now I do not really see a solution for this. It was working in 3.4.0. Right now just go back to OSG-3.4.0, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Hi Anders et.al, On 4 February 2016 at 14:34, Robert Osfieldwrote: > I will complete these fixes and get them checked in, once I do I'll > update this thread. I have fixed the problems in osgShadow and checked in fixes to git master. Gotta be said that some elements of the osgShadow code is right mess, far more complicated and difficult to follow than it should be. There are quite a few classes in there that I should never have merged as they really make a mockery of clean and clear class design and implementation. I'm wondering whether I should just remove such parts of the OSG as we go forward. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Hi Joshua, I'm not sure what you mean by video canvas. If you want to render a video as a texture on a geometry then the osgmovie example is the place to look. Robert. On 24 May 2015 at 21:39, Joshua Robinson shooki.robin...@gmail.com wrote: Howdy OSG-Users Volcans, I am a newbie to OSG and need help to do : Add a video canvas to scale the video. It should do : 1) Create a video canvas. 2) Assign texture coordinates to the video canvas, I prefer manually, it can be automatically (function). Specify the number of columns and rows on your own, need to have more than 2. 3) Use texture coordinate video image rendering. I have no idea how, a small sample(s) code will be appreciate . Cheers, (oyori), -Joshua Robinson PS. Live long and prosper. ___ 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] (no subject)
I am having this problem with OSG 3.3.3 and Qt5 and MSVC2013 Commenting out the #define GL_ARB_vertex_buffer_object in osg/BufferObject does indeed allow it to compile. On Sun, Feb 1, 2015 at 10:56 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Phileppe, I presume Qt5.4 is define the various GL values in it's headers as well as the OSG. You could try changing the include order of the Qt and OSG headers to see if that can resolve the issue. I don't have Qt5.4 on my system to test against so I'll have to defer to you to see if you can find a solution. If you do just let me know the changes required and we can then discuss how to tweak the OSG or it's Qt usage to avoid the issues. Robert. On 31 January 2015 at 22:03, philippe renon philippe_re...@yahoo.fr wrote: I am also seeing this warnings multiple times: [ 92%] Building CXX object src/applications/osgearth_package_qt/CMakeFiles/application_osgearth_package_qt.dir/package_qt.cpp.obj In file included from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopengl.h:123:0, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/qgl.h:39, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/QGLWidget:1, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgQt/GraphicsWindowQt:17, from d:/Projects/OpenPilot/3rdparty/osgearth/src/osgEarthQt/ViewerWidget:26, from d:\Projects\OpenPilot\3rdparty\osgearth\src\applications\osgearth_package_qt\package_qt.cpp:26: d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h:2431:0: warning: GL_SHADER_STORAGE_BARRIER_BIT redefined #define GL_SHADER_STORAGE_BARRIER_BIT 0x2000 ^ In file included from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/GLExtensions:18:0, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/BufferObject:19, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/Array:46, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/Shape:21, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/KdTree:17, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgDB/Registry:21, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgDB/FileUtils:17, from d:\Projects\OpenPilot\3rdparty\osgearth\src\applications\osgearth_package_qt\package_qt.cpp:21: D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/GLDefines:496:0: note: this is the location of the previous definition #define GL_SHADER_STORAGE_BARRIER_BIT 0x2000 ^ PS : sorry for the missing email object. Le Samedi 31 janvier 2015 21h44, philippe renon philippe_re...@yahoo.fr a écrit : Hi, Compilation of osg 3.2.1 against Qt 5.4.0 (mingw) was working perfectly fine. After switching to 3.3.3 we are seeing this compilation error : In file included from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopengl.h:123:0, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/qgl.h:39, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/QGLWidget:1, from d:/Projects/OpenPilot/3rdparty/osg/include/osgQt/GraphicsWindowQt:17, from d:\Projects\OpenPilot\3rdparty\osg\examples\osgviewerQt\osgviewerQt.cpp:12: d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h:10653:130: error: 'GLintptrARB' has not been declared typedef void (APIENTRYP PFNGLBINDVIDEOCAPTURESTREAMBUFFERNVPROC) (GLuint video_capture_slot, GLuint stream, GLenum frame_region, GLintptrARB offset); The issue comes from a conflict between osg/include/osg/BufferObject and qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h within the section starting with: #ifndef GL_ARB_vertex_buffer_object #define GL_ARB_vertex_buffer_object I beleive that this issue was introduced by openscenegraph/osg https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c [image: image] https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c openscenegraph/osg https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c osg - OpenSceneGraph git mirror Afficher sur github.com
Re: [osg-users] (no subject)
Hi Philippe, Unfortunately the forum has messed up the attachments. The mailing list is such much more reliable for attachments, alas forum's are so modern that most new users seem to prefer it. Could you just email me directly the changed files. Thanks for you patience, Robert. On 3 February 2015 at 00:03, Philippe Renon philippe_re...@yahoo.fr wrote: Hi Robert, Thanks for the quick answers. Please find attached the two modified files (originals are from version 3.3.3): The files are: - include/osg/BufferObject - include/osg/GLDefines Qt also uses the #ifdef #define pattern so switching include order might not be ideal (haven't tested...). I guess it is easier to change osg than Qt ;) But there is a somewhat related Qt bug open : https://bugreports.qt.io/browse/QTBUG-43748 Qt unnecessarily exposes GL constants publicly. Regards, Philippe -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62562#62562 Attachments: http://forum.openscenegraph.org//files/4674_1422921720._672. http://forum.openscenegraph.org//files/4674_1422921695._155. ___ 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] (no subject)
Hi Robert, Thanks for the quick answers. Please find attached the two modified files (originals are from version 3.3.3): The files are: - include/osg/BufferObject - include/osg/GLDefines Qt also uses the #ifdef #define pattern so switching include order might not be ideal (haven't tested...). I guess it is easier to change osg than Qt ;) But there is a somewhat related Qt bug open : https://bugreports.qt.io/browse/QTBUG-43748 Qt unnecessarily exposes GL constants publicly. Regards, Philippe -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62562#62562 Attachments: http://forum.openscenegraph.org//files/4674_1422921720._672. http://forum.openscenegraph.org//files/4674_1422921695._155. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
robertosfield wrote: Could you try removing the #define GL_ARB_vertex_buffer_object line from the include/osg/BufferObject header to see if that allows the Qt header to compile fine. Removing the #define GL_ARB_vertex_buffer_object line did the trick. Fixing the GL_SHADER_STORAGE_BARRIER_BIT redefine warning is also straightfoward: diff --git a/include/osg/GLDefines b/include/osg/GLDefines index e89bd3a..11ef3d2 100644 --- a/include/osg/GLDefines +++ b/include/osg/GLDefines @@ -493,7 +493,7 @@ typedef char GLchar; #endif #ifndef GL_VERSION_4_3 -#define GL_SHADER_STORAGE_BARRIER_BIT 0x2000 +#define GL_SHADER_STORAGE_BARRIER_BIT 0x2000 -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62543#62543 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
robertosfield wrote: Hi Phileppe, I presume Qt5.4 is define the various GL values in it's headers as well as the OSG. You could try changing the include order of the Qt and OSG headers to see if that can resolve the issue. I don't have Qt5.4 on my system to test against so I'll have to defer to you to see if you can find a solution. If you do just let me know the changes required and we can then discuss how to tweak the OSG or it's Qt usage to avoid the issues. Robert. It is exactly that and I tend to include OSG first and then Qt. Will try the other way around although fixing OSG is pretty simple (see my last post on that subject). Philippe. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62547#62547 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Hi Phileppe, Good to hear you've been able to fix the problems. Could you send me the whole modified files so I can do graphical diff to make sure I get all the correct modifications. Thanks, Robert. On 1 February 2015 at 12:08, Philippe Renon philippe_re...@yahoo.fr wrote: robertosfield wrote: Could you try removing the #define GL_ARB_vertex_buffer_object line from the include/osg/BufferObject header to see if that allows the Qt header to compile fine. Removing the #define GL_ARB_vertex_buffer_object line did the trick. Fixing the GL_SHADER_STORAGE_BARRIER_BIT redefine warning is also straightfoward: diff --git a/include/osg/GLDefines b/include/osg/GLDefines index e89bd3a..11ef3d2 100644 --- a/include/osg/GLDefines +++ b/include/osg/GLDefines @@ -493,7 +493,7 @@ typedef char GLchar; #endif #ifndef GL_VERSION_4_3 -#define GL_SHADER_STORAGE_BARRIER_BIT 0x2000 +#define GL_SHADER_STORAGE_BARRIER_BIT 0x2000 -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62543#62543 ___ 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] (no subject)
Hi Phileppe, I presume Qt5.4 is define the various GL values in it's headers as well as the OSG. You could try changing the include order of the Qt and OSG headers to see if that can resolve the issue. I don't have Qt5.4 on my system to test against so I'll have to defer to you to see if you can find a solution. If you do just let me know the changes required and we can then discuss how to tweak the OSG or it's Qt usage to avoid the issues. Robert. On 31 January 2015 at 22:03, philippe renon philippe_re...@yahoo.fr wrote: I am also seeing this warnings multiple times: [ 92%] Building CXX object src/applications/osgearth_package_qt/CMakeFiles/application_osgearth_package_qt.dir/package_qt.cpp.obj In file included from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopengl.h:123:0, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/qgl.h:39, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/QGLWidget:1, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgQt/GraphicsWindowQt:17, from d:/Projects/OpenPilot/3rdparty/osgearth/src/osgEarthQt/ViewerWidget:26, from d:\Projects\OpenPilot\3rdparty\osgearth\src\applications\osgearth_package_qt\package_qt.cpp:26: d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h:2431:0: warning: GL_SHADER_STORAGE_BARRIER_BIT redefined #define GL_SHADER_STORAGE_BARRIER_BIT 0x2000 ^ In file included from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/GLExtensions:18:0, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/BufferObject:19, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/Array:46, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/Shape:21, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/KdTree:17, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgDB/Registry:21, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgDB/FileUtils:17, from d:\Projects\OpenPilot\3rdparty\osgearth\src\applications\osgearth_package_qt\package_qt.cpp:21: D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/GLDefines:496:0: note: this is the location of the previous definition #define GL_SHADER_STORAGE_BARRIER_BIT 0x2000 ^ PS : sorry for the missing email object. Le Samedi 31 janvier 2015 21h44, philippe renon philippe_re...@yahoo.fr a écrit : Hi, Compilation of osg 3.2.1 against Qt 5.4.0 (mingw) was working perfectly fine. After switching to 3.3.3 we are seeing this compilation error : In file included from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopengl.h:123:0, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/qgl.h:39, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/QGLWidget:1, from d:/Projects/OpenPilot/3rdparty/osg/include/osgQt/GraphicsWindowQt:17, from d:\Projects\OpenPilot\3rdparty\osg\examples\osgviewerQt\osgviewerQt.cpp:12: d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h:10653:130: error: 'GLintptrARB' has not been declared typedef void (APIENTRYP PFNGLBINDVIDEOCAPTURESTREAMBUFFERNVPROC) (GLuint video_capture_slot, GLuint stream, GLenum frame_region, GLintptrARB offset); The issue comes from a conflict between osg/include/osg/BufferObject and qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h within the section starting with: #ifndef GL_ARB_vertex_buffer_object #define GL_ARB_vertex_buffer_object I beleive that this issue was introduced by openscenegraph/osg https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c [image: image] https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c openscenegraph/osg https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c osg - OpenSceneGraph git mirror Afficher sur github.com https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c Aperçu par Yahoo Regards, Philippe. ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] (no subject)
Hi Philippe, Could you try removing the #define GL_ARB_vertex_buffer_object line from the include/osg/BufferObject header to see if that allows the Qt header to compile fine. Robert. On 31 January 2015 at 20:44, philippe renon philippe_re...@yahoo.fr wrote: Hi, Compilation of osg 3.2.1 against Qt 5.4.0 (mingw) was working perfectly fine. After switching to 3.3.3 we are seeing this compilation error : In file included from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopengl.h:123:0, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/qgl.h:39, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/QGLWidget:1, from d:/Projects/OpenPilot/3rdparty/osg/include/osgQt/GraphicsWindowQt:17, from d:\Projects\OpenPilot\3rdparty\osg\examples\osgviewerQt\osgviewerQt.cpp:12: d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h:10653:130: error: 'GLintptrARB' has not been declared typedef void (APIENTRYP PFNGLBINDVIDEOCAPTURESTREAMBUFFERNVPROC) (GLuint video_capture_slot, GLuint stream, GLenum frame_region, GLintptrARB offset); The issue comes from a conflict between osg/include/osg/BufferObject and qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h within the section starting with: #ifndef GL_ARB_vertex_buffer_object #define GL_ARB_vertex_buffer_object I beleive that this issue was introduced by openscenegraph/osg https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c [image: image] https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c openscenegraph/osg https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c osg - OpenSceneGraph git mirror Afficher sur github.com https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c Aperçu par Yahoo Regards, Philippe. ___ 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] (no subject)
I am also seeing this warnings multiple times: [ 92%] Building CXX object src/applications/osgearth_package_qt/CMakeFiles/application_osgearth_package_qt.dir/package_qt.cpp.obj In file included from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopengl.h:123:0, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/qgl.h:39, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/QGLWidget:1, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgQt/GraphicsWindowQt:17, from d:/Projects/OpenPilot/3rdparty/osgearth/src/osgEarthQt/ViewerWidget:26, from d:\Projects\OpenPilot\3rdparty\osgearth\src\applications\osgearth_package_qt\package_qt.cpp:26: d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h:2431:0: warning: GL_SHADER_STORAGE_BARRIER_BIT redefined #define GL_SHADER_STORAGE_BARRIER_BIT 0x2000 ^ In file included from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/GLExtensions:18:0, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/BufferObject:19, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/Array:46, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/Shape:21, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/KdTree:17, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgDB/Registry:21, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgDB/FileUtils:17, from d:\Projects\OpenPilot\3rdparty\osgearth\src\applications\osgearth_package_qt\package_qt.cpp:21: D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/GLDefines:496:0: note: this is the location of the previous definition #define GL_SHADER_STORAGE_BARRIER_BIT 0x2000 ^ PS : sorry for the missing email object. Le Samedi 31 janvier 2015 21h44, philippe renon philippe_re...@yahoo.fr a écrit : Hi, Compilation of osg 3.2.1 against Qt 5.4.0 (mingw) was working perfectly fine. After switching to 3.3.3 we are seeing this compilation error : In file included from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopengl.h:123:0, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/qgl.h:39, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/QGLWidget:1, from d:/Projects/OpenPilot/3rdparty/osg/include/osgQt/GraphicsWindowQt:17, from d:\Projects\OpenPilot\3rdparty\osg\examples\osgviewerQt\osgviewerQt.cpp:12: d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h:10653:130: error: 'GLintptrARB' has not been declared typedef void (APIENTRYP PFNGLBINDVIDEOCAPTURESTREAMBUFFERNVPROC) (GLuint video_capture_slot, GLuint stream, GLenum frame_region, GLintptrARB offset); The issue comes from a conflict between osg/include/osg/BufferObjectand qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h within the section starting with: #ifndef GL_ARB_vertex_buffer_object #define GL_ARB_vertex_buffer_object I beleive that this issue was introduced by openscenegraph/osg | | | | | | | | | | | openscenegraph/osgosg - OpenSceneGraph git mirror | | | | Afficher sur github.com | Aperçu par Yahoo | | | | | Regards,Philippe. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
LineSegmentIntersector will almost never hit non-polygon geometry. A perfect hit between a line and another line is difficult with floating point math. You should probably use the PolytopeIntersector ( http://trac.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00616.html ) which intersects a VOLUME representing the intersection ray against the lines of the geometry, being much more inclusive. PolytopeIntersector is slower of course. On Fri, Oct 10, 2014 at 11:42 PM, jiang.sa...@gmail.com jiang.sa...@gmail.com wrote: Hi guys, Recently, I have build a test application based on osg 3.2 and osgEarth 2.5 which loads some linestring geometry. Then I tried to calculate the spatial distance between two lines using *osgUtil::LineSegmentIntersector::Intersections results; if (getMapNode() view-computeIntersections(x, y, results, _intersectionMask)) { // find the first hit under the mouse: osgUtil::LineSegmentIntersector::Intersection first = *(results.begin()); osg::Vec3d point = first.getWorldIntersectPoint(); double lat_rad, lon_rad, height; getMapNode()-getMap()-getProfile()-getSRS()-getEllipsoid()-convertXYZToLatLongHeight( point.x(), point.y(), point.z(), lat_rad, lon_rad, height); lat = osg::RadiansToDegrees(lat_rad); lon = osg::RadiansToDegrees(lon_rad); hgt = height;* *}* But always is the intersection point on terrain, not linestring. Do you have any suggestion to complish it ? Thanks! -- jiang.sa...@gmail.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android @alphapixel https://twitter.com/alphapixel facebook.com/alphapixel (775) 623-PIXL [7495] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Thanks Robert for the detailed analysis. This is very helpful. Is there a way for me to directly access the slave cameras in my Viewer object, so I could, in the short term, hack in a change to the colorMasks, and thus perhaps not need to recompile OpenSceneGraph? Longer term, it might be nice to add an API for setting the color mask, in DisplaySettings. The most direct approach would be to add methods something like Code: DisplaySettings.setLeftAnaglyphColorMask(bool, bool, bool) Passing a bunch of boolean values like that smells a little bad, but it would expose the full constellation of possibilities presented by the underlying glColorMask() approach. I'm not sure what the corresponding getter method would look like. Regards, Christopher robertosfield wrote: HI Christopher, Currently the ANAGLYPHIC stereo support is hardwired to red-cyan. Curiously you are the first to ask for anything else. To implement for other interpretations of anaglyphic you'd need to implement it using osgViewer::View slave Camera's, one slave Camera for the left eye and one for the right - you'd attach the appropriate osg::ColorMask for each slave Camera to get the effect you want. The code that sets up stereo in svn/trunk can be found in OpenSceneGraph/src/osgViewer/View.cpp assignStereoOrKeystoneToCamera(..) method, the code block of interest looks like: switch(ds-getStereoMode()) { case(osg::DisplaySettings::QUAD_BUFFER): { // disconect the camera from the graphics context. camera-setGraphicsContext(0); // left Camera left buffer osg::ref_ptrosg::Camera left_camera = assignStereoCamera(ds, gc.get(), 0, 0, traits-width, traits-height, traits-doubleBuffer ? GL_BACK_LEFT : GL_FRONT_LEFT, -1.0); left_camera-setClearMask(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT); left_camera-setRenderOrder(osg::Camera::NESTED_RENDER, 0); // right Camera right buffer osg::ref_ptrosg::Camera right_camera = assignStereoCamera(ds, gc.get(), 0, 0, traits-width, traits-height, traits-doubleBuffer ? GL_BACK_RIGHT : GL_FRONT_RIGHT, 1.0); right_camera-setClearMask(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT); right_camera-setRenderOrder(osg::Camera::NESTED_RENDER, 1); You could implement this without going via the osg::DisplaySettings/default configuration, the other alternative would be to extend DisplaySettings and the View.cpp code to handle customization of the anaglyphic settings. Robert. On 31 July 2014 16:07, Christopher Bruns () wrote: Hi, Is it possible to display stereo 3D rendering for green-magenta anaglyph glasses in OpenSceneGraph? (as opposed to red-cyan glasses) I can get stereo working well with old-fashioned red-(blue-cyan) glasses. Is there a way to change the color settings of anaglyph mode? Below is a complete twelve line python program that renders in stereo for red/cyan glasses. Code: from osgswig import osg, osgDB, osgViewer, osgGA print %d.%d.%d % (osg.OSG_VERSION_MAJOR, osg.OSG_VERSION_MINOR, osg.OSG_VERSION_PATCH) # prints 3.2.1 cow = osgDB.readNodeFile(cow.osg) # Use custom DisplaySettings to create a stereoscopic view display_settings = osg.DisplaySettings() display_settings.setStereoMode(osg.DisplaySettings.ANAGLYPHIC) # Red-cyan ONLY !?!? display_settings.setStereo(True) viewer = osgViewer.Viewer() viewer.setSceneData(cow) viewer.setUpViewInWindow(100, 100, 500, 500, 1) viewer.setDisplaySettings(display_settings) viewer.run() How would I modify this program to display stereo for modern green-magenta filtered glasses? Thank you! Cheers, Christopher ___ osg-users mailing list () http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org) -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=60526#60526 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Sorry I neglected to put a subject line. I think once I have two posts, I will be able to edit my question subject on the forum. Christopher -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=60519#60519 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
HI Christopher, Currently the ANAGLYPHIC stereo support is hardwired to red-cyan. Curiously you are the first to ask for anything else. To implement for other interpretations of anaglyphic you'd need to implement it using osgViewer::View slave Camera's, one slave Camera for the left eye and one for the right - you'd attach the appropriate osg::ColorMask for each slave Camera to get the effect you want. The code that sets up stereo in svn/trunk can be found in OpenSceneGraph/src/osgViewer/View.cpp assignStereoOrKeystoneToCamera(..) method, the code block of interest looks like: switch(ds-getStereoMode()) { case(osg::DisplaySettings::QUAD_BUFFER): { // disconect the camera from the graphics context. camera-setGraphicsContext(0); // left Camera left buffer osg::ref_ptrosg::Camera left_camera = assignStereoCamera(ds, gc.get(), 0, 0, traits-width, traits-height, traits-doubleBuffer ? GL_BACK_LEFT : GL_FRONT_LEFT, -1.0); left_camera-setClearMask(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT); left_camera-setRenderOrder(osg::Camera::NESTED_RENDER, 0); // right Camera right buffer osg::ref_ptrosg::Camera right_camera = assignStereoCamera(ds, gc.get(), 0, 0, traits-width, traits-height, traits-doubleBuffer ? GL_BACK_RIGHT : GL_FRONT_RIGHT, 1.0); right_camera-setClearMask(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT); right_camera-setRenderOrder(osg::Camera::NESTED_RENDER, 1); You could implement this without going via the osg::DisplaySettings/default configuration, the other alternative would be to extend DisplaySettings and the View.cpp code to handle customization of the anaglyphic settings. Robert. On 31 July 2014 16:07, Christopher Bruns cmbr...@rotatingpenguin.com wrote: Hi, Is it possible to display stereo 3D rendering for green-magenta anaglyph glasses in OpenSceneGraph? (as opposed to red-cyan glasses) I can get stereo working well with old-fashioned red-(blue-cyan) glasses. Is there a way to change the color settings of anaglyph mode? Below is a complete twelve line python program that renders in stereo for red/cyan glasses. [code] from osgswig import osg, osgDB, osgViewer, osgGA print %d.%d.%d % (osg.OSG_VERSION_MAJOR, osg.OSG_VERSION_MINOR, osg.OSG_VERSION_PATCH) # prints 3.2.1 cow = osgDB.readNodeFile(cow.osg) # Use custom DisplaySettings to create a stereoscopic view display_settings = osg.DisplaySettings() display_settings.setStereoMode(osg.DisplaySettings.ANAGLYPHIC) # Red-cyan ONLY !?!? display_settings.setStereo(True) viewer = osgViewer.Viewer() viewer.setSceneData(cow) viewer.setUpViewInWindow(100, 100, 500, 500, 1) viewer.setDisplaySettings(display_settings) viewer.run() [/code] How would I modify this program to display stereo for modern green-magenta filtered glasses? Thank you! Cheers, Christopher ___ 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] (no subject)
Hi Daniel, somewhere in the header of the txp archive should be something like GetVersion or such. Look in the trpage_* headers Nick On Thu, Apr 25, 2013 at 1:10 PM, Daniel Krikun krikun.dan...@gmail.comwrote: Hello Nick, How can I check what version of the txp is the format of the terrain? Mess ag e: 2 Date: Mon, 22 Ap r 20 13 09 :4 4: 5 5 +0 20 0 From : Tr ajc e Nik olov NIC K traj ce .n iko lov. ni ck @g m ail .c om To : Ope nS c eneG rap h Us ers osg - use rs@ lis ts . open sc ene gr aph .or g Su bj ect : Re: [osg - use rs] txp lod prob lem : sw itc hi ng in cyc l es Mess ag e - ID: CA O - +zi kU 6a UW pV C g uT 8M S 0qb y3 - + NkU D_ C 60 zKg sK tDZ0 G3 iS w @m ai l. gm ai l. c om Con tent - Ty pe: text/ p lai n; ch ars et= is o - 88 59 - 1 Hi Dani el, I am run nin g larg e terr ain (txp ) on my lapt op wi th no prob lem s wi th the lates t cod e fr om the trun k (alt houg h I don' t thin k the txp load er was touc hed latel y). Wha t is the vers ion of your arc hi ve ? It seam that the cod e in the repo sit ory wor ks the bes t wi th 2. 1 arc hi ves. Al so, goo d prac ti ce is to use s3 textu re com pr es sio n (dx t3 and dxt5 ) wh en bui ldi ng the arc hi ve in Te rra Vi sta . If you can bui ld a bloc k and post it I can take a look wh at is happ eni ng Let me know Nic k On Mon, Ap r 22 , 20 13 at 9: 02 AM , Dani el Krik un kri ku n. dani el@g mai l. c om wr ote: Hel lo, I have a he avy appl ic ati on wh ic h use s osg view er and a TX P terr ain . Af te r som e tim e the appl ic ati on is run nin g , LOD level of the terr ain star ts bein g sw itc he d hig h er and low er all the tim e in cyc l es, so one sec ond I have trees and bui ldi ng bein g dis pla yed and one sec ond later - they dis appe ar. Inter est ing , if I run jus t 2 ins tanc es of osg vie we r. exe wi th a larg e TX P terr ain , af ter som e tim e, I ach ieve the sam e ef f ec t. I sus pec t, TX P load er detec ts low me mor y avail abl e and sw itc he s LOD dow n, then wh en som e me mor y is fr eed due to this LOD sw itc hi ng , the load er sw itc he s the LOD up, the me mor y ge ts low and it con tin ues in cyc l es. An y idea s ? I'm run nin g Win dow s XP, 32 - bit, GT X 67 0. Both osg - 2. 9. 8 and 3. 0. 1 exh ibi t this beha viou r. Th ank s, - - Dani el Krik un __ __ _ __ _ __ __ _ __ _ __ _ __ __ _ __ _ __ _ __ __ _ __ _ __ __ _ __ _ _ osg - use rs mai li ng lis t osg - use rs@ lis ts . open sc ene gr aph .or g http: / / li sts .op ens ce neg r aph. org / li sti nf o. cg i / ___ osg-users mailing list 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] (no subject)
Hi RigTransformSoftware is not a node, it is helper class which implements skinning animation inside RigGeometry (which is not a node either, its drawable).Just dont touch vertex positions array and use gl_Vertex in shader instead of your position attribute (dont do this: geom-setVertexAttribArray(0, vertex_data_array); ). So your example vertex shader will look like this:attribute vec4 color_attribute;varying vec4 color;void main(){color = color_attribute;gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;} Cheers.06.09.2012, 21:28, "Peterakos" hay...@gmail.com:Hello.First of all the SceneGraph that is created after i read the dae file doesnt have any RigTransformSoftware node. Does that mean the values in the vertex array in the rig geometry will stay the same during the program execution (and they will never get the updated value) ?In order for me to pass to the shader's position_attribute the correct updated value what do i have to do ?Do i have to call setVertexAttribArray in every loop, passing the as parameter the udapted values ?Is there any way to received these updated vertex positions without using the RigTransformSoftware and without having to multiply with the transformation matrices i received from bones ??Thnx again and sorry for the long thread. ,___osg-users mailing listosg-users@lists.openscenegraph.orghttp://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] (no subject)
Hi RigGeometry vertex\normal arrays updated according to animation when software rig transform implementation is used. Have a look at RigTransformSoftware::operator() source. If you set vertex position with setVertexAttribArray, it woudnt be updated, else if you set it with setVertexArray it would be overwritten with array calculated by rig transform implementation. If you just need transformed values - use gl_Vertex in shader, and dont touch vertex array. Cheers. 06.09.2012, 14:54, "Peterakos" hay...@gmail.com:Hello.My task is to render an animated dae character with shaders.I have created a simple vertex shader:attribute vec4 position_attribute;attribute vec4 color_attribute;varying vec4 color; void main(){color = color_attribute;gl_Position = gl_ModelViewProjectionMatrix * position_attribute;} After that i use stateset-setAttributeAndModes to assign the program to the model .I assign the position and color atrtibute to the corresponding location according to this:gl_Vertex0gl_Normal2gl_Color3gl_SecondaryColor4 Everything works fine.The problem comes when i try to pass manually the vertex array and color array using:geom-setVertexAttribArray(attrib_num, data_array);geom-setVertexAttribBinding(attrib_num, attrib_binding); I pass the RigGeometry's VertexArray as data array, but the character is not animated because the defaultgeometry's values are passed. Watching the osganimationhardware example i noticed that i have to pass the bone matricesas well and multiply with vertex position.Is there any Array which keeps the updated vertex positions according to the animation?If there is, i can match this array's values to position attribute, without having to pass the matrices in the shader.Thank you for your time and sorry for the long post.,___osg-users mailing listosg-users@lists.openscenegraph.orghttp://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] (no subject)
Hello. First of all the SceneGraph that is created after i read the dae file doesnt have any RigTransformSoftware node. Does that mean the values in the vertex array in the rig geometry will stay the same during the program execution (and they will never get the updated value) ? In order for me to pass to the shader's position_attribute the correct updated value what do i have to do ? Do i have to call setVertexAttribArray in every loop, passing the as parameter the udapted values ? Is there any way to received these updated vertex positions without using the RigTransformSoftware and without having to multiply with the transformation matrices i received from bones ?? Thnx again and sorry for the long thread. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Spam. Do not visit this link. On Mon, Jul 2, 2012 at 3:18 PM, m...@arne-kreutzmann.de wrote: http://newmodeluk.com/time.php?ocean208.png ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Hi, Short answer: there are no simple way, You should get all drawables, grab all primitivesets and set instance count for them, write shaders that make use of instanceID to calculate vertex position. also with instanced drawing you should disable display lists, so for performance reasons make sure that your drawables have low primitivesets count (single primitiveset is good goal), i'd recommend to use osg optimizer with INDEX_MESH | VERTEX_PRETRANSFORM | VERTEX_POSSTRANSFORM on models you gonna draw instanced. 03.12.2011, 07:03, michael.a.bo...@l-3com.com: Hi Everyone, I'm trying to implement a fairly dense forested area and simply adding in a bunch of osg::MatrixTransform nodes predictably causes the cull to crash. I could try reorganizing the scene around an oct-tree as was suggested by a previous discussion on this topic, but for draw performance reasons, since each tree is the same model, I would like to use the new draw instanced arb. I see that osgdrawinstanced has been referenced in many similar threads, but osgdrawinstanced creates its geometry on the fly, and in doing so can quite easily use the command syntax for instancing. I am trying to apply the technique to a loaded model and there is no obvious easy method. My question is this, if I load a file using osgDB::readNodeFile(somefile.osg); How would I set it up for instanced drawing? My guess is that I would need to write a node-visitor that collects all of the geometry - drawables and sets them up to use the instanced call overload instead of the default. I have tried doing this, but my implementation has gotten pretty complex, and I want to make sure there isn't a more simple way I have overlooked. Thank you very much for your time. Michael A Bosse' ___ 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] (no subject)
Hello Michael, I guess with instancing you mean not loading the geometry more than once. By default, when loading a let's say openflight database OSG will load every external, even it has been encountered before. There are 2 options you can try. 1, Set up a readFileCallback and cache the model yourself 2. use the osgDB caching: osgDB::ReaderWriter::Options* opt = osgDB::Registry::instance()-getOptions(); if (opt == NULL) { opt = new osgDB::ReaderWriter::Options(); } // setup caching opt-setObjectCacheHint(osgDB::ReaderWriter::Options::CACHE_ALL); also you might consider using sharing of states and textures: osgDB::SharedStateManager::ShareMode mode = osgDB::SharedStateManager::SHARE_ALL; mode = static_castosgDB::SharedStateManager::ShareMode(mode | osgDB::SharedStateManager::SHARE_STATESETS | osgDB::SharedStateManager::SHARE_TEXTURES); osgDB::Registry::instance()-getOrCreateSharedStateManager()-setShareMode(mode); For a real instancing/pseudo-instancing or different methods to draw massive amounts of trees you might also want to take a look into the osgforest example. P.S. Please provide a subject, as it might raise your chances to appear on the readers radar ;-) cheers Sebastian Hi Everyone, I'm trying to implement a fairly dense forested area and simply adding in a bunch of osg::MatrixTransform nodes predictably causes the cull to crash. I could try reorganizing the scene around an oct-tree as was suggested by a previous discussion on this topic, but for draw performance reasons, since each tree is the same model, I would like to use the new draw instanced arb. I see that osgdrawinstanced has been referenced in many similar threads, but osgdrawinstanced creates its geometry on the fly, and in doing so can quite easily use the command syntax for instancing. I am trying to apply the technique to a loaded model and there is no obvious easy method. My question is this, if I load a file using osgDB::readNodeFile(somefile.osg); How would I set it up for instanced drawing? My guess is that I would need to write a node-visitor that collects all of the geometry - drawables and sets them up to use the instanced call overload instead of the default. I have tried doing this, but my implementation has gotten pretty complex, and I want to make sure there isn't a more simple way I have overlooked. Thank you very much for your time. Michael A Bosse' ___ 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] (no subject)
Sorry abou this unsavoury spam getting through - it looks to be a case of a guinuine osg-user that has their mail account compromised by the spammers. I've unsubscribed the problem account and notified the account holder. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Hi, FYI, Paul Martz's OpenSceneGraph Quick Start Guide is preferred for beginners in my opinion. And Qian Xuelei and I wrote a book OpenSceneGraph Beginners Guide in the end of last year, which is published by the Packt Publishing. Do some search in the osg-users archives could be of a lot help, too. As I guess you are from China, I'll also suggest the osgChina forum (bbs.osgchina.org), and some Chinese materials, like The Longest Frame (in Chinese, 最长的一帧) written by me, and two OSG publications published by the Tsinghua University Press. Wang Rui 在 2011年5月10日 上午7:55,蜡笔小新 841224...@qq.com 写道: hello,everyone,i'd like to ask some question about osg. I 'm trying to analysis the architecture of osg depending on the source code. As i'm a researcher and i try to do something on graphics,I have to do some reseach. Can anybody give me any suggestions ___ 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] (no subject)
Manage/stop your subscription at the same place you signed up at http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ Gordon Tomlinson http://www.photographybygordon.com/ www.photographybyGordon.com http://www.gordontomlinson.com/ www.gordontomlinson.com http://www.vis-sim.com/ www.vis-sim.com Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival -Master Tambo Tetsura From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Vivek Kumar Dwivedi Sent: Sunday, March 27, 2011 10:10 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] (no subject) DON'T SEND MESSAGE PLEASE. -- Vivek Dwivedi, ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
On Wed, Jan 12, 2011 at 6:21 AM, Vivek Kumar Dwivedi vivekcsjm...@gmail.com wrote: Pléase don't send me queries. -- Vivek Dwivedi, ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org If want to disable subscription or unsubscribe then simply follow the list to the mailing list admin page - it's appended to all posts (see above you post even had all the info you need). Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Hi Robert, Could you remove him from the mailing list ? he have sent dozens of mails like this. Mourad If want to disable subscription or unsubscribe then simply follow the list to the mailing list admin page - it's appended to all posts (see above you post even had all the info you need). 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] (no subject)
Hi Vivek, On Wed, Sep 22, 2010 at 6:44 AM, Vivek Kumar Dwivedi vivekcsjm...@gmail.com wrote: Hi,do not send mail. I am very busy. Too busy to be polite or to take control of your own subscription? At the bottom of all emails there is the link to the mailing list admin pages, simple log in and disable your receipt of mailing lists posts or simply subscribe. http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
This is a spam and spam link, Gordon Tomlinson Product Manager 3d Technology Project Wyvern Overwatch® An Operating Unit of Textron Systems __ WARNING: Documents that can be viewed, printed or retrieved from this E-Mail may contain technical data whose export is restricted by the Arms Export Control Act (Title 22, U.S.C., Sec 2751, et seq,) or the Export Administration Act of 1979, as amended, Title 50, U.S.C., App. 2401 et seq. and which may not be exported, released or disclosed to non-U.S. persons (i.e. persons who are not U.S. citizens or lawful permanent residents [green card holders]) inside or outside the United States, without first obtaining an export license. Violations of these export laws are subject to severe civil, criminal and administrative penalties. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Yurii Monakov Sent: Saturday, July 24, 2010 9:21 PM To: osg-users@lists.openscenegraph.org; pavelpel...@ya.ru Subject: [osg-users] (no subject) http://sites.google.com/site/gGtjM8SvxU11/yhhyksvy ___ 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] (no subject)
On Mon, Jul 26, 2010 at 12:39 PM, Tomlinson, Gordon gtomlin...@overwatch.textron.com wrote: This is a spam and spam link, I spotted it too, and don't know how it got into osg-users list. The mailing addresses on the post aren't subscribed and the mailing list is set to reject all posts from non subscribed members. The only exception to this is ones sent via the forum which get sent through the forums subscribed account, but this spam post didn't seem to come through this route. Any ideas? Has mailman been hacked? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Hi John, I would suggest adding the directory where the collada lib is into your lib search path. I can't recall exactly what this is under windows, could it just be PATH? The other alternative is to copy the lib into the directory where you've installed the OSG libs. Robert. On Tue, Mar 2, 2010 at 6:29 PM, Montgomery, John T. j.t.montgom...@abdn.ac.uk wrote: Hello All, I am trying, for the first time, to export a Blender model into OSG - specifically, present3D. I have compiled OSG debug version with Collada, Exported a DAE from Blender 'eye.dae'. Run this in the standard plain vanilla way for present3D - within a slide/layer: slide background/background titleEye Modelled in Blender/title duration20/duration layer model coordinate_frame=slide scale=1.0images/eye.dae/model /layer /slide Run with: C:\2010-02-22_OSG\bin\present3Dd.exe C:\dropbox\tutorial\eye.p3d (Some of the) console debug output: SlideShowConstructor::addModel(images/eye.dae) readNode(images/eye.dae) itr='C:\2010-02-22_OSG\bin' FindFileInPath() : trying C:\2010-02-22_OSG\bin\osgPlugins-2.9.7\osgdb_daed.dll ... FindFileInPath() : USING C:\2010-02-22_OSG\bin\osgPlugins-2.9.7\osgdb_daed.dll DynamicLibrary::failed loading osgPlugins-2.9.7/osgdb_daed.dll No valid object found for images/eye.dae Warning: Could not find plugin to read objects from file images/eye.dae. end of SlideShowConstructor::addModel(images/eye.dae) In the running application, a dialogue reports. This application has failed to start because libcollada14dom2l-d.dll was not found. Re-installing the application may fix this problem. ( Technically, the application isn't installed, I didn't build 'INSTALL'. Does this matter? ) The dll is in the folder C:\2010-02-22_OSG\bin\osgPlugins-2.9.7\osgdb_daed.dll, however, libcollada14dom2l-d.dll is in C:\OSG_dev\collada \dom\build\vc9-1.4-d\libcollada14dom21-d.dll (miles away) This directory \collada\ is at the same level, *but not inside* the OSG 3rdParty dependencies folder. I have an environmental variable COLLADA_DIR= C:\OSG_dev\collada Also, have C:\OSG_dev\collada \dom\build\vc9-1.4-d\ in PATH variable. I tried copying the DLL to C:\2010-02-22_OSG\bin\osgPlugins-2.9.7 - but, didn't help. The minimal slide contains two things, and I don't think is the cause of the problem: 1. The title which displays and handles as normal, 2. The DAE model (not) - which of course doesn't appear. I would be grateful for any ideas what might be going wrong here, please? :-) John Montgomery, Glassel, Scotland. The University of Aberdeen is a charity registered in Scotland, No SC013683. ___ 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] (no subject)
Hi John, Is there a reason why you write libcollada14dom2l-d.dll with an L rather than a 1 ? Mourad On Tue, Mar 2, 2010 at 7:29 PM, Montgomery, John T. j.t.montgom...@abdn.ac.uk wrote: Hello All, I am trying, for the first time, to export a Blender model into OSG - specifically, present3D. I have compiled OSG debug version with Collada, Exported a DAE from Blender 'eye.dae'. Run this in the standard plain vanilla way for present3D - within a slide/layer: slide background/background titleEye Modelled in Blender/title duration20/duration layer model coordinate_frame=slide scale=1.0images/eye.dae/model /layer /slide Run with: C:\2010-02-22_OSG\bin\present3Dd.exe C:\dropbox\tutorial\eye.p3d (Some of the) console debug output: SlideShowConstructor::addModel(images/eye.dae) readNode(images/eye.dae) itr='C:\2010-02-22_OSG\bin' FindFileInPath() : trying C:\2010-02-22_OSG\bin\osgPlugins-2.9.7\osgdb_daed.dll ... FindFileInPath() : USING C:\2010-02-22_OSG\bin\osgPlugins-2.9.7\osgdb_daed.dll DynamicLibrary::failed loading osgPlugins-2.9.7/osgdb_daed.dll No valid object found for images/eye.dae Warning: Could not find plugin to read objects from file images/eye.dae. end of SlideShowConstructor::addModel(images/eye.dae) In the running application, a dialogue reports. This application has failed to start because libcollada14dom2l-d.dll was not found. Re-installing the application may fix this problem. ( Technically, the application isn't installed, I didn't build 'INSTALL'. Does this matter? ) The dll is in the folder C:\2010-02-22_OSG\bin\osgPlugins-2.9.7\osgdb_daed.dll, however, libcollada14dom2l-d.dll is in C:\OSG_dev\collada \dom\build\vc9-1.4-d\libcollada14dom21-d.dll (miles away) This directory \collada\ is at the same level, *but not inside* the OSG 3rdParty dependencies folder. I have an environmental variable COLLADA_DIR= C:\OSG_dev\collada Also, have C:\OSG_dev\collada \dom\build\vc9-1.4-d\ in PATH variable. I tried copying the DLL to C:\2010-02-22_OSG\bin\osgPlugins-2.9.7 - but, didn't help. The minimal slide contains two things, and I don't think is the cause of the problem: 1. The title which displays and handles as normal, 2. The DAE model (not) - which of course doesn't appear. I would be grateful for any ideas what might be going wrong here, please? :-) John Montgomery, Glassel, Scotland. The University of Aberdeen is a charity registered in Scotland, No SC013683. ___ 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] (no subject)
Hi Robert, (Sorry about the 'no subject'.) You gave me an idea - put 'libcollada14dom2l-d.dll' in the System32 folder - and it worked! Thanks very much. :-) John Montgomery, Glassel, Scotland. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: 03 March 2010 08:46 To: OpenSceneGraph Users Subject: Re: [osg-users] (no subject) Hi John, I would suggest adding the directory where the collada lib is into your lib search path. I can't recall exactly what this is under windows, could it just be PATH? The other alternative is to copy the lib into the directory where you've installed the OSG libs. Robert. The University of Aberdeen is a charity registered in Scotland, No SC013683. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Hi Mourad, You have eagle eyes! :-) Reason: I used irfanview's OCR to translate the error message in the dialogue screenshot, and didn't notice it had mistranslated. But, it's working now, thanks for your interest. :-) John Montgomery, Glassel, Scotland. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Mourad Boufarguine Sent: 03 March 2010 09:01 To: OpenSceneGraph Users Subject: Re: [osg-users] (no subject) Hi John, Is there a reason why you write libcollada14dom2l-d.dll with an L rather than a 1 ? Mourad The University of Aberdeen is a charity registered in Scotland, No SC013683. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Oh, and sorry about the no subject. I hit the Send button to soon. Jesper D. Thomsen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
HI Sunitha, In future posts could you use a relevant subject line as this helps with mail clients to thread appropriately, and also for others down the line to find threads on particular topics in the archives. When you load a scene graph from any of the 3d loaders you'll get a complete scene graph with a single node at it's root, the StateSets that contain the OpenGL state will be distributed across this graph, and will rarely just be contained at the root node. This means you'll need to traverse the scene graph to find the StateSets, to do this the best way is to write a custom NodeVisitor. There are many examples of custom NodeVisitor all over the OSG source code and examples - just do a search for NodeVisitor to see it in action. Robert. On Tue, Feb 3, 2009 at 6:42 AM, sunitha sunagad sunithassuna...@gmail.com wrote: -- How can i get the staeset of the model i have lodeaded to the openScenegraph I am loading an iv file which has the state set attribute in it i need the current state set attribute does any one know... I am using getStateset but its returning null. Always Keep Smiling! Defeat the defeat before defeat defeats you Regards Sunitha.S.Sunagad ___ 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] (no subject)
Hi Pecoraro thank to spot the bug please send your submissions on osg-submissions the next time. after review the original code, at line Optimizer.cpp:1561 lod-getNumRanges() is used to know how many iteration will be done in the for loop, and getNumRanges have to be equal to getNumChild, so lod-getChild(i) at line 1563 is not the problem. Perhaps you LOD is not synchronised (num of children and num of range are not equal)i don't know why or how is possible. Anyway, in a case of a PagedLOD, only the code of LOD is used, so not special case for a PagedLOD. correct me if i'm wrong. Cheers David Callu 2008/6/6 Pecoraro, Alexander N [EMAIL PROTECTED]: I think there is a bug in the osgUtil::Optimizer::CombineLODVisitor - at line 1530 of Optimizer.cpp it does a dynamic_cast on and osg::Node* to osg::LOD* and then at line 1563 it calls getChild(i) (even if getNumChildren() == 0) on the dynamically casted LOD node. This works fine when the node is an LOD node, but when it is a PagedLOD node then it causes in invalid access to the _children vector. I attached a screen shot to show what I mean. This situation would only ocurr when a PagedLOD node was a sibling of an LOD node, which is probably why it hasn't been spotted before. Not sure if this is the accepted way to submit a fix, but anyway I made a fix to the Optimizer code (version 2.4) and attached it to the email. Alex ___ 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] (no subject)
Hi Maya, Sorry about this, changed the API but missed updating the wrappers. They are now updated and checked in. Robert. On Mon, Mar 31, 2008 at 12:34 AM, maya leonard [EMAIL PROTECTED] wrote: Hi Robert While trying to compile the latest svn version from today I get the following compile errors for osgDB and osgTerrain Wrappers. Thanks Maya 3-- Build started: Project: Wrapper osgDB, Configuration: Release x64 -- 2Compiling... 3Compiling... 3DatabasePager.cpp 2Terrain.cpp 3.\osgDB\DatabasePager.cpp(296) : error C2039: 'setMaximumNumOfRemovedChildPagedLODs' : is not a member of 'osgDB::DatabasePager' 3 D:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\include\osgDB/DatabasePager(42) : see declaration of 'osgDB::DatabasePager' 3.\osgDB\DatabasePager.cpp(296) : error C2065: 'setMaximumNumOfRemovedChildPagedLODs' : undeclared identifier 3.\osgDB\DatabasePager.cpp(301) : error C2039: 'getMaximumNumOfRemovedChildPagedLODs' : is not a member of 'osgDB::DatabasePager' 3 D:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\include\osgDB/DatabasePager(42) : see declaration of 'osgDB::DatabasePager' 3.\osgDB\DatabasePager.cpp(301) : error C2065: 'getMaximumNumOfRemovedChildPagedLODs' : undeclared identifier 3.\osgDB\DatabasePager.cpp(306) : error C2039: 'setMinimumNumOfInactivePagedLODs' : is not a member of 'osgDB::DatabasePager' 3 D:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\include\osgDB/DatabasePager(42) : see declaration of 'osgDB::DatabasePager' 3.\osgDB\DatabasePager.cpp(306) : error C2065: 'setMinimumNumOfInactivePagedLODs' : undeclared identifier 3.\osgDB\DatabasePager.cpp(311) : error C2039: 'getMinimumNumOfInactivePagedLODs' : is not a member of 'osgDB::DatabasePager' 3 D:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\include\osgDB/DatabasePager(42) : see declaration of 'osgDB::DatabasePager' 3.\osgDB\DatabasePager.cpp(311) : error C2065: 'getMinimumNumOfInactivePagedLODs' : undeclared identifier 3Build log was saved at file://d:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\src\osgWrappers\osgwrapper_osgDB.dir\Release\BuildLog.htm 3Wrapper osgDB - 8 error(s), 0 warning(s) 2.\osgTerrain\Terrain.cpp(73) : error C2039: 'setTerrainTechnique' : is not a member of 'osgTerrain::Terrain' 2 D:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\include\osgTerrain/Terrain(26) : see declaration of 'osgTerrain::Terrain' 2.\osgTerrain\Terrain.cpp(73) : error C2065: 'setTerrainTechnique' : undeclared identifier 2.\osgTerrain\Terrain.cpp(78) : error C2039: 'getTerrainTechnique' : is not a member of 'osgTerrain::Terrain' 2 D:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\include\osgTerrain/Terrain(26) : see declaration of 'osgTerrain::Terrain' 2.\osgTerrain\Terrain.cpp(78) : error C2065: 'getTerrainTechnique' : undeclared identifier 2.\osgTerrain\Terrain.cpp(83) : error C2039: 'getTerrainTechnique' : is not a member of 'osgTerrain::Terrain' 2 D:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\include\osgTerrain/Terrain(26) : see declaration of 'osgTerrain::Terrain' 2.\osgTerrain\Terrain.cpp(83) : error C2065: 'getTerrainTechnique' : undeclared identifier 2Build log was saved at file://d:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\src\osgWrappers\osgwrapper_osgTerrain.dir\Release\BuildLog.htm 2Wrapper osgTerrain - 6 error(s), 0 warning(s) Windows Live Hotmail is giving away Zunes. Enter for your chance to win. ___ 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] (no subject)
Hi, A 60ms draw time is high, and may be high simply because the OpenGL fifo is full and stalling draw dispatch, or could be that you could requires a round trip from CPU to GPU. I wouldn't have though having lots of Camera in itself would be the cause of the slow draw times. W.r.t multipass, using of multiple Camera is probably the way, but one thing osg::Camera possibly doesn't yet support is sharing of FBO's, I say possibly because I haven't tried to implement this type of rendering myself yet, and osg::Camera is setup with the assumption that each camera will create and manage its own FBO. One might be able to assign an already created FBO and share between multiple Cameras, but I can't say for sure as I haven't tried it in code yet... Robert. On Sun, Feb 3, 2008 at 11:32 PM, [EMAIL PROTECTED] wrote: Hi all, I have a problem in which I have to do multipass rendering. When I say multipass, it's in fact rendering to a texture which is the input for the next rendering, etc... and that about a hundreds time... I could explain why, but only if necessary, but let's say that no there is no better way than doing a cascaded rendering with that amount of steps, and in fact, that's sphecifically why I'm doing it on GPU... Moving on to OSG related problem, it seems to me that every time you want to render to a texture you have to add a Camera node. I've heard that you could maybe do a little bit better, by having only one Camera node, but several paths leading to it with differents statesets. But in my case, I can't have only one camera, and several statesets, because each time, I have to change the fbo to render to, that can only be done by adding a new camera, with a different texture to render to ... So my question is, is there a better way to do this kind of multipass rendering, than adding a camera for each step ? (better in the sense of less costly ...) I'm asking this because when I look at the stats, drawing takes about 60 ms, and gpu time is 80ms. I expected the value for the gpu, because for each camera, there is a fragment shader associated. But I didn't expect the draw time to be so high, and I really think that is because of the way I'm doing it (too many nodes maybe ... :( ) Thank you all ___ 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] (no subject)
Hi Pedro, Have you added the core osg libraries to you link line? Are the osg libraries built OK and on your paths? Robert. On Jan 2, 2008 2:06 PM, Pedro José Muñoz Martínez [EMAIL PROTECTED] wrote: Hello all, I am trying to load Images in my application and it compiles ok but when linking it appears the following errors: Creating library ../bin/ExerciseImpl.lib and object ../bin/ExerciseImpl.exp 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: virtual void __thiscall osg::Texture::compileGLObjects(class osg::State )const ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@@Z) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) protected: virtual void __thiscall osg::Texture2D::computeInternalFormat(void)const ([EMAIL PROTECTED]@osg@@MBEXXZ) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) protected: virtual void __thiscall osg::Texture2D::allocateMipmap(class osg::State )const ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@@Z) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: virtual int __thiscall osg::Texture2D::getTextureDepth(void)const ([EMAIL PROTECTED]@osg@@UBEHXZ) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: virtual int __thiscall osg::Texture2D::getTextureHeight(void)const ([EMAIL PROTECTED]@osg@@UBEHXZ) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: virtual void __thiscall osg::Object::computeDataVariance(void) ([EMAIL PROTECTED]@osg@@UAEXXZ) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: virtual int __thiscall osg::Texture2D::getTextureWidth(void)const ([EMAIL PROTECTED]@osg@@UBEHXZ) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: virtual unsigned int __thiscall osg::Texture2D::getNumImages(void)const ([EMAIL PROTECTED]@osg@@UBEIXZ) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: virtual class osg::Image const * __thiscall osg::Texture2D::getImage(unsigned int)const ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@[EMAIL PROTECTED]) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: virtual class osg::Image * __thiscall osg::Texture2D::getImage(unsigned int) ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@[EMAIL PROTECTED]) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: virtual void __thiscall osg::Texture2D::setImage(unsigned int,class osg::Image *) ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@@Z) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: virtual unsigned int __thiscall osg::Texture2D::getTextureTarget(void)const ([EMAIL PROTECTED]@osg@@UBEIXZ) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: virtual enum osg::StateAttribute::Type __thiscall osg::Texture2D::getType(void)const ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@[EMAIL PROTECTED]) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: virtual char const * __thiscall osg::Texture2D::className(void)const ([EMAIL PROTECTED]@osg@@UBEPBDXZ) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: virtual char const * __thiscall osg::Texture2D::libraryName(void)const ([EMAIL PROTECTED]@osg@@UBEPBDXZ) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: virtual bool __thiscall osg::Texture2D::isSameKindAs(class osg::Object const *)const ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@@Z) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: virtual class osg::Object * __thiscall osg::Texture2D::clone(class osg::CopyOp const )const ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@Z) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) class osg::Image * __cdecl osgDB::readImageFile(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@2@@std@@[EMAIL PROTECTED]@1@@Z) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: virtual class osg::Object * __thiscall osg::Texture2D::cloneType(void)const ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@XZ) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: virtual bool __thiscall osg::StateAttribute::checkValidityOfAssociatedModes(class osg::State )const ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@@Z) 1prueba.obj : error LNK2001: unresolved external symbol __declspec(dllimport) public: class osgDB::ReaderWriter::Options * __thiscall osgDB::Registry::getOptions(void)
Re: [osg-users] (no subject)
Silvère Besse wrote: in the daily builds : OpenSG\Source\System\FieldContainer\OSGFieldDescription.cpp is missing, no way to compile :( Looks like you posted to the mailing list of the wrong scene graph ;-) Try the one at www.opensg.org Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Hi Jan Take a look to the ShapeDrawable::accept(const HeightField field) to see how osg render a height field. Take a look to the osgtexture2d example to know how to enable and render texture. HTH David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org