Re: [osg-users] left/right alternating stereo
Hi, i have the same problem I have a system where graphic board (nvidia K5000) must be setted to 60Hz, and a projector able to go to 120Hz (between graphic card and projector there are 2 devices that work only to 60 Hz). To visualize stereo 3D, this system uses a player like butterfly3D (or BINO, http://bino3d.org/doc/bino.html#Overview-1). It loads a syde-by-syde left-right movie (60 Hz) and sends an alternating left-right (60Hz) to projector. The projector (Vivitek D5380U), receives a 60Hz input signal and visualizes a type of stereo (like quad buffer) at 120Hz. It seems to duplicates the frequency. Using Bino, stereo works (quite correctly). I would like to visualize OSG application in stereo mode (using the same approach), on this system. My question is : If i use quadbuffer stereo forcing frequency to 60 Hz, do i get the same result? This becouse i have no side by side source. So i suppose that with a slow quad buffer, i can simulate the alternating output to projector. Is it possible to force quadbuffer to 60Hz? On a common workstation with nvidia quadro 600, using a 60Hz monitor and use quadbuffer stereo, i see the alternating frames slower than on 120 Hz monitor. This is the reason for forcing the quadbuffer to 60Hz. I try to direct execute quadbuffer on the system with openscenegraph application, but i don't see the alternating images (i get also an error : detect OpenGL error 'invalid operation' at after RenderBin::draw(...). I see a single image (like mono view). Thank you! Cheers, Andrea -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62389#62389 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Aborting frames that take too long
Hi, I'm having a problem trying to use OSG for a specific scenario. My simulation contains several screens all showing the same scene at different angles (think projector setup). I'd like to synchronize the frames among them so that tearing between screens is minimal. Due to the nature of my scenes, some screens will have more to render than others and, as a result, take longer to render (ground vs sky). I'm looking for a way to interrupt a render loop and restart it if I detect it's taking too long for my liking. I've looked at a few proposed solutions by others with a similar problem and I've found about the osg::State::setAbortRenderingPtr(bool*). That indeed cancels the current frame, but it causes the viewer to get locked up waiting for a mutex to become available in the Renderer::ThreadSafeQueue::takeFront() function called from the Renderer::draw() function. I've tried setting the abortRenderPtr to NULL every frame (using the FRAME event on osgGA::GUIEventAdapter) and setting it to NULL immediately after it's been checked in RenderLeaf::render, though that doesn't seem to change anything. The wait function still takes control. I've read that the setAbortRenderingPtr function is old, but is there any knowledge about how it's supposed to be used? Also, if that doesn't seem like the solution for my scenario, does anyone have any suggestions? Thanks! - Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Oldie, but goodie... Aero themes and OpenGL/MFC
Hi, 2015-01-09 23:58 GMT+01:00 Andrew Cunningham andr...@mac.com: Hi, I finally got around to resolving these MFC/Aero issues using the following . snip Hope someone finds this helpful While I didn't hit the Aero issue you're talking about (I'm still on Windows XP), this post remains helpful as I'm getting performance issue with a similar MFC/OSG application. By contrast with the osgviewerMFC example where the cOSG class (that makes the glue between OSG and MFC) is a component of the view (CMFC_OSG_MDIView), I imagine that in your situation, this cannot be the case, as each view of your CSplitterWnd would otherwise have it's own OSG viewer/scene graph, right? I also imagine that you're using a CompositeViewer rather than a Viewer instance to manage the OSG part of your different CSplitterWnd views? Where did you put the instance of this CompositeViewer, as a member variable of the child frame? In my application, I'm relying upon a CompositeViewer, a member variable of the child frame. This child frame also has a CSplitterWnd member variable. Each view of the CompositeViewer inherits the window data from the CSplitterWnd view's HWND. With this architecture, the performances are far from stellar. Basically, the framerate is divided by the number of views. If it does matter, I'm using a separate render thread for each CompositeViewer. Since there's one CompositeViewer per child frame, there's in fact one distinct CompositeViewer by opened document. I don't know if it's the optimum architecture. For the records, I've also tried one unique CompositeViewer and render thread at the application level, shared by all the child frames/opened documents, but I was getting random crashes. But that's another story, back to the performance problem. Do you also notice performance issue with your application? I don't know where it comes from, maybe context switching as each view of the CompositeViewer inherit a different graphics context from the CSplitterWnd view? I've discarded the CSplitterWnd as the cause, as I'm getting the same kind of performance drop simply replacing the Viewer in the osgviewerMFC example with a CompositeViewer holding two views of the same scene graph. For completeness, I've also looked at the osgviewerQt example that makes use of a CompositeViewer, each view also having it's own graphics context. I'm not seeing any performance problem there on the same PC. Cheers, Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Some thoughts on the new DisplacementMapping technique
Hi Robert, after inspecting the new DisplacementMappingTechnique I have some ideas. First of all, the shader source code should be configurable from the outside via interface in order to integrate it into own pipelines (in my case I have a CustomShaderProgram based pipeline. Another option might be to create an interface to let one set the program from the outside, alongside with an option to retrieve the defines that would have been injected. Second suggestion: The use of tesselation shaders. Currently you are pushing a lot vertex buffers around for tiles with a regular grid. It might be more efficient only pushing 4 vertices and letting the tesselation do the rest. It might be even more efficient to move the displacement there, since each vertex would be touched exactly once in terms of transform. Cheers Sebastian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using pbuffer as a texture.
Hi Trajce. Thank you very much for your answer. Unfortunately this isn't what I'm looking for. The prerender example does pretty much the same thing as the distortion example : it creates a window with a view and a scene graph and does render to texture within this graph. I, on the other hand, must do render to texture within a graph that is not linked to any window (offscreen). Here is a use case example. I'm making an airplane simulation. I have a window with a view displaying the outside world as seen from the cockpit. Now, when the user press a button, I want to make a photo of what is below the plane. This photo must not be displayed on any window at the moment it is taken (not yet), it must be rendered offscreen and stored for later use. What I tried to do is creating a pbuffer (using the createGraphicsContext() function and setting pbuffer = true in the traits), then assign a view to this pbuffer and use it for my offscreen rendering. It didn't work. It seems it isn't possible to create both a window and a pbuffer within the same application. If I create a pbuffer first and a window later I get an error in wglMakeCurrent() saying the pixel format is invalid. If I create the window first and then the pbuffer then I get no error but the window doesn't show up. Regards -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62372#62372 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.3.3 developer release
Hi again, I've identified one crash in the GLBufferObject::bindBuffer due to an uninitialized _extension member. It seems, it gets destroyed somewhere in the middle. Unfortunately the GLExtensions object doesn't have a declared destructor, so chasing this down is harder than I thought. I'll analyze futher. Btw. I've already rebuild cleanly and used the HEAD for testing, but it seems the behaviour stays the same. Cheers Sebastian Hi Robert, would you expect problems with old osgTerrain databases (build with ~3.2.0, osgb format)? I have some strange behaviour with a huge database, which simply not displayed anymore and somehow breaks state (See attached picture). Also there is a warning coming from an optimzer I guess: Warning: CollectLowestTransformsVisitor::removeTransforms() error, encountered a NULL Transform pointer A second, much smaller database is sometimes displayed, but crashes the viewer sometimes. I've attached it, could you please try to load it? It is really hard to find the culprit. Any hints? I'll investigate the issue further ... Cheers Sebastian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.3.3 developer release
Hi Robert, as already written, the problem is an invalidated _extensions object. It seems to be invalidated by the State destructor, which causes the destructor of the GLExtensions object to be called. (I've got there using a memory breakpoint) I've attached a callstack for analysis. (i've added a destructor for the GLExtensions for testing) Cheers Sebastian snip osg116-osgd.dll!osg::Referenced::~Referenced() Line 234 C++ osg116-osgd.dll!osg::GLExtensions::~GLExtensions() + 0x28 bytesC++ osg116-osgd.dll!osg::GLExtensions::`vector deleting destructor'() + 0x7d bytesC++ osg116-osgd.dll!osg::Referenced::signalObserversAndDelete(bool signalDelete, bool doDelete) Line 324 + 0x31 bytesC++ osg116-osgd.dll!osg::Referenced::unref() Line 200C++ osg116-osgd.dll!osg::ref_ptrosg::GLExtensions::operator=(osg::GLExtensions * ptr) Line 59C++ osg116-osgd.dll!osg::GLExtensions::Set(unsigned int contextID, osg::GLExtensions * extensions) Line 429C++ osg116-osgd.dll!osg::State::~State() Line 136C++ osg116-osgUtild.dll!osg::State::`scalar deleting destructor'() + 0x2d bytesC++ osg116-osgd.dll!osg::Referenced::signalObserversAndDelete(bool signalDelete, bool doDelete) Line 324 + 0x31 bytesC++ osg116-osgd.dll!osg::Referenced::unref() Line 200C++ osg116-osgUtild.dll!osg::ref_ptrosg::State::operator=(osg::State * ptr) Line 59C++ osg116-osgUtild.dll!osg::RenderInfo::setState(osg::State * state) Line 57 + 0x32 bytesC++ osg116-osgUtild.dll!osgUtil::SceneView::setState(osg::State * state) Line 184 + 0x3b bytesC++ osg116-osgViewerd.dll!osgViewer::Renderer::updateSceneView(osgUtil::SceneView * sceneView) Line 517C++ osg116-osgViewerd.dll!osgViewer::Renderer::cull() Line 625C++ osg116-osgViewerd.dll!osgViewer::ViewerBase::renderingTraversals() Line 826C++ osg116-osgViewerd.dll!osgViewer::ViewerBase::frame(double simulationTime) Line 677C++ osg116-osgViewerd.dll!osgViewer::ViewerBase::run() Line 647C++ osg116-osgViewerd.dll!osgViewer::Viewer::run() Line 420 C++ RenderTest_d.exe!main(int argc, char * * argv) Line 66 + 0xb bytesC++ RenderTest_d.exe!__tmainCRTStartup() Line 555 + 0x19 bytesC RenderTest_d.exe!mainCRTStartup() Line 371C /snip Hi Robert, would you expect problems with old osgTerrain databases (build with ~3.2.0, osgb format)? I have some strange behaviour with a huge database, which simply not displayed anymore and somehow breaks state (See attached picture). Also there is a warning coming from an optimzer I guess: Warning: CollectLowestTransformsVisitor::removeTransforms() error, encountered a NULL Transform pointer A second, much smaller database is sometimes displayed, but crashes the viewer sometimes. Unfortunately my first email, containing a database didn't get through. It is really hard to find the culprit. Any hints? I'll investigate the issue further ... Cheers Sebastian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Some thoughts on the new DisplacementMapping technique
Am 19.01.2015 21:40, schrieb Robert Osfield: Hi Sebastian, On 19 January 2015 at 12:43, Sebastian Messerschmidt sebastian.messerschm...@gmx.de mailto:sebastian.messerschm...@gmx.de wrote: after inspecting the new DisplacementMappingTechnique I have some ideas. First of all, the shader source code should be configurable from the outside via interface in order to integrate it into own pipelines (in my case I have a CustomShaderProgram based pipeline. Making the methods of the osgTerrain::GeometryPool virtual might a means of achieving this. Allow you to overload the osg::Program creation. That should do the trick as well. Actually it seems to be the cleaner solution. Another option might be to create an interface to let one set the program from the outside, alongside with an option to retrieve the defines that would have been injected. I am actually working on adding support to osg::State, osg::Program and osg::Shader for passing on #define's to the Shaders, and have these #define's match up to osg::StateSet::setMode(GLenum,..) management of glEnable/glDisable. This would eventually be user customizable, but in the first instance my intention is to have the normally toggling of GL_LIGHTING, or GL_TEXTURE_* map to #define GL_LIGHTING etc. that gets included infront of a Shader when it's compiled. This approach would allow use to blend fixed function style OSG usage with Shaders. Potentially this approach could be a new take on doing shader composition. Great. I've been doing something like this by modifying the ShaderComposition (as proposed by you) and injection defines at start of the composed shader. It still seems to be a clutch, so I'm looking forward to your ideas. If you want to, I'm totally happy to share my insights. I had some request to review it some months ago, but you where into some other stuff at this time, so it might have ended up below the radar. (The topic was [osg-users] ShaderComposer and some missing features) Second suggestion: The use of tesselation shaders. Currently you are pushing a lot vertex buffers around for tiles with a regular grid. The idea of the GeometryPool is that most of the osg::Geometry are now shared so the number of VBO's being managed is now far lower than it used to be with the brute force GeometryTechnique. With Geocentric databases the grids aren't actually regular, it takes double maths to make sure the curvature it correct when you set up the osg::Geometry to share. I disagree. They are still regular at the tile level. Currently the matrix is pushed together with the local geometry, so it should stay in the float precision range (the matrix is not changed, nor are the local vertices). Maybe I'm overlooking something here, but I don't see the difference pushing only the vertices for the outer-geometry as the resulting inner is locally flat. Along with the potential savings in pushing less vertices, it might even produce some fractal noise to add artificial details (This looks really really great) It might be more efficient only pushing 4 vertices and letting the tesselation do the rest. It might be even more efficient to move the displacement there, since each vertex would be touched exactly once in terms of transform. My work I checked in last on using geometry shaders to toggle the edge of the triangles to fit with terrain has worked as I intended but performance hit is far greater than I expected - it's around 3 times slower on the GPU when using the geometry shader than when just using the vertex and fragment shaders to displacement mapping. For the small visual quality improvement the use of geometry shaders provide I'm incline to think for most users they aren't a good tradeoff. Geometry shaders are great when it comes to minimize drawing. A good example is rendering millions of billboard trees from instanced point geometry which is used to create a billboard for each point. I managed to get a fair amount of trees (~500k) rendered with them, so I wonder where the bottleneck might be in your case. I guess its all about not switching and batching up similar sized arrays ;-) It's could be that tessellation shaders will be good solution, it's something I've only briefly looked at so can't comment on it more deeply. The issue of using double maths to compute the base mesh that is displaced is something that will require us to still do stuff on the CPU unless we start pushing double data down to the GPU, but here dragons lie... I'm open to suggestions, especially if you pony up some code to illustrate what you have in mind :-) See my email concerning the crash and errors I'm experiencing regarding my terrains. When the issue is solved and you made the GeometryPool accessible via inheritance I'd be more as happy contributing, as I have some related work duties to solve in the next months. I've tried some
Re: [osg-users] OpenSceneGraph-3.3.3 developer release
Hi Sebastian, I haven't had chance to try and reproduce the bug yet. The description sounds like there an initialization order issue with the osg::State. In theory the osg::State object now does the initalization, and the osg::GraphicsContext on the first makeCurrent() should ensure that it's set up correctly, in theory this should be the first set of OpenGL calls made. What is application you are testing within? What is the platform? Robert. On 19 January 2015 at 10:07, Sebastian Messerschmidt sebastian.messerschm...@gmx.de wrote: Hi Robert, as already written, the problem is an invalidated _extensions object. It seems to be invalidated by the State destructor, which causes the destructor of the GLExtensions object to be called. (I've got there using a memory breakpoint) I've attached a callstack for analysis. (i've added a destructor for the GLExtensions for testing) Cheers Sebastian snip osg116-osgd.dll!osg::Referenced::~Referenced() Line 234C++ osg116-osgd.dll!osg::GLExtensions::~GLExtensions() + 0x28 bytes C++ osg116-osgd.dll!osg::GLExtensions::`vector deleting destructor'() + 0x7d bytesC++ osg116-osgd.dll!osg::Referenced::signalObserversAndDelete(bool signalDelete, bool doDelete) Line 324 + 0x31 bytesC++ osg116-osgd.dll!osg::Referenced::unref() Line 200C++ osg116-osgd.dll!osg::ref_ptrosg::GLExtensions::operator=(osg::GLExtensions * ptr) Line 59C++ osg116-osgd.dll!osg::GLExtensions::Set(unsigned int contextID, osg::GLExtensions * extensions) Line 429C++ osg116-osgd.dll!osg::State::~State() Line 136C++ osg116-osgUtild.dll!osg::State::`scalar deleting destructor'() + 0x2d bytesC++ osg116-osgd.dll!osg::Referenced::signalObserversAndDelete(bool signalDelete, bool doDelete) Line 324 + 0x31 bytesC++ osg116-osgd.dll!osg::Referenced::unref() Line 200C++ osg116-osgUtild.dll!osg::ref_ptrosg::State::operator=(osg::State * ptr) Line 59C++ osg116-osgUtild.dll!osg::RenderInfo::setState(osg::State * state) Line 57 + 0x32 bytesC++ osg116-osgUtild.dll!osgUtil::SceneView::setState(osg::State * state) Line 184 + 0x3b bytesC++ osg116-osgViewerd.dll!osgViewer::Renderer::updateSceneView(osgUtil::SceneView * sceneView) Line 517C++ osg116-osgViewerd.dll!osgViewer::Renderer::cull() Line 625C++ osg116-osgViewerd.dll!osgViewer::ViewerBase::renderingTraversals() Line 826C++ osg116-osgViewerd.dll!osgViewer::ViewerBase::frame(double simulationTime) Line 677C++ osg116-osgViewerd.dll!osgViewer::ViewerBase::run() Line 647C++ osg116-osgViewerd.dll!osgViewer::Viewer::run() Line 420C++ RenderTest_d.exe!main(int argc, char * * argv) Line 66 + 0xb bytesC++ RenderTest_d.exe!__tmainCRTStartup() Line 555 + 0x19 bytesC RenderTest_d.exe!mainCRTStartup() Line 371C /snip Hi Robert, would you expect problems with old osgTerrain databases (build with ~3.2.0, osgb format)? I have some strange behaviour with a huge database, which simply not displayed anymore and somehow breaks state (See attached picture). Also there is a warning coming from an optimzer I guess: Warning: CollectLowestTransformsVisitor::removeTransforms() error, encountered a NULL Transform pointer A second, much smaller database is sometimes displayed, but crashes the viewer sometimes. Unfortunately my first email, containing a database didn't get through. It is really hard to find the culprit. Any hints? I'll investigate the issue further ... Cheers Sebastian ___ 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] OpenSceneGraph-3.3.3 developer release
Am 19.01.2015 21:27, schrieb Robert Osfield: Hi Sebastian, I haven't had chance to try and reproduce the bug yet. The description sounds like there an initialization order issue with the osg::State. In theory the osg::State object now does the initalization, and the osg::GraphicsContext on the first makeCurrent() should ensure that it's set up correctly, in theory this should be the first set of OpenGL calls made. What is application you are testing within? What is the platform? Windows 7, VisualStudio 2010. It is crashing in a minimal application as well as using osgviewer. Have you tried to use my minimal database? It reproduces the crash when loading it with the osgviewer and stiring around with the mouse a bit. (Also take a look at the attached picture: It shows a messed up State) I was able to fix the crash by removing the GLExentsions::Set(contextId,0) in the State destructor. But this seems plain wrong. I suspect on my platform, the State is cleared and reinitialized for some reason. When I can spent some time on this, I can try to create a minimal example. Just out of curiosity: Is there any reason for the State to remove the extensions for the ContextID? I suspect there is only one State per Context, which seems ok, but I cannot grasp, why it is released in my scenario. Also I had problems after the fix loading other databases; It seems the range lists in paging are invalid. It randomly displays the wrong tiles with wrong facing. I'll try to hunt this down too. Any suggestions how to narrow down the problem on my side? Cheers Sebastian Robert. On 19 January 2015 at 10:07, Sebastian Messerschmidt sebastian.messerschm...@gmx.de mailto:sebastian.messerschm...@gmx.de wrote: Hi Robert, as already written, the problem is an invalidated _extensions object. It seems to be invalidated by the State destructor, which causes the destructor of the GLExtensions object to be called. (I've got there using a memory breakpoint) I've attached a callstack for analysis. (i've added a destructor for the GLExtensions for testing) Cheers Sebastian snip osg116-osgd.dll!osg::Referenced::~Referenced() Line 234C++ osg116-osgd.dll!osg::GLExtensions::~GLExtensions() + 0x28 bytesC++ osg116-osgd.dll!osg::GLExtensions::`vector deleting destructor'() + 0x7d bytesC++ osg116-osgd.dll!osg::Referenced::signalObserversAndDelete(bool signalDelete, bool doDelete) Line 324 + 0x31 bytes C++ osg116-osgd.dll!osg::Referenced::unref() Line 200C++ osg116-osgd.dll!osg::ref_ptrosg::GLExtensions::operator=(osg::GLExtensions * ptr) Line 59C++ osg116-osgd.dll!osg::GLExtensions::Set(unsigned int contextID, osg::GLExtensions * extensions) Line 429 C++ osg116-osgd.dll!osg::State::~State() Line 136C++ osg116-osgUtild.dll!osg::State::`scalar deleting destructor'() + 0x2d bytesC++ osg116-osgd.dll!osg::Referenced::signalObserversAndDelete(bool signalDelete, bool doDelete) Line 324 + 0x31 bytes C++ osg116-osgd.dll!osg::Referenced::unref() Line 200C++ osg116-osgUtild.dll!osg::ref_ptrosg::State::operator=(osg::State * ptr) Line 59C++ osg116-osgUtild.dll!osg::RenderInfo::setState(osg::State * state) Line 57 + 0x32 bytesC++ osg116-osgUtild.dll!osgUtil::SceneView::setState(osg::State * state) Line 184 + 0x3b bytesC++ osg116-osgViewerd.dll!osgViewer::Renderer::updateSceneView(osgUtil::SceneView * sceneView) Line 517C++ osg116-osgViewerd.dll!osgViewer::Renderer::cull() Line 625C++ osg116-osgViewerd.dll!osgViewer::ViewerBase::renderingTraversals() Line 826C++ osg116-osgViewerd.dll!osgViewer::ViewerBase::frame(double simulationTime) Line 677C++ osg116-osgViewerd.dll!osgViewer::ViewerBase::run() Line 647C++ osg116-osgViewerd.dll!osgViewer::Viewer::run() Line 420C++ RenderTest_d.exe!main(int argc, char * * argv) Line 66 + 0xb bytesC++ RenderTest_d.exe!__tmainCRTStartup() Line 555 + 0x19 bytesC RenderTest_d.exe!mainCRTStartup() Line 371C /snip Hi Robert, would you expect problems with old osgTerrain databases (build with ~3.2.0, osgb format)? I have some strange behaviour with a huge database, which simply not displayed anymore and somehow breaks state (See attached picture). Also there is a warning coming from an optimzer I guess: Warning: CollectLowestTransformsVisitor::removeTransforms() error, encountered a NULL Transform pointer A second, much smaller database is sometimes displayed, but crashes the viewer sometimes. Unfortunately my first email, containing a database didn't get through. It is really hard to find the culprit. Any hints? I'll investigate the issue further ... Cheers
Re: [osg-users] Oldie, but goodie... Aero themes and OpenGL/MFC
Andrew, I think you will find that not many people really dug into using MFC with OSG ( as you can tell by the deafening silence on the forum on these topics) Yes, indeed... I am using a separate CMFC_OSG_MDIView for each CView. I am not sure why you see that would be a problem. It does mean a separate Camera and separate osgViewer::Viewer etc for each CView but as you can share ,osg::Group/osg::Geometry objects as needed between scene graphs, I am not sure why this would have any downside. OK, there's the difference. You're still using an osgViewer::Viewer instance per CMFC_OSG_MDIView, while on my side, I was trying to use one osgViewer::CompositeViewer to manage all the osgViewer::View inheriting the CMFC_OSG_MDIView window data. The big difference between what I do and the OSG MFC examples is that - I am single threaded I'm running a separate render thread. I found that the osg threading mechanism seemed to be flawed, as I had 4 osg threads using 100% of the CPU even when the app was idle. Perhaps I was missing something. But it seems fundamental that , for example, the cull thread is always running and never sleeping. Great for real-time games, not so much for applications that need to be 'nice'. Could it be that you're using continuous rendering (default option) rather than on-demand rendering? You can change this with osgViewer::ViewerBase::setRunFrameScheme(osgViewer::ViewerBase::ON_DEMAND). The drawback is that you'll thus have to override the MFC stack to trigger osgViewer::View::requestRedraw() when required (e.g. OnSize). - I then completely bypass the viewer OSG event handler and handle all events using the standard MFC event mechanism. That is I handle OnPaint, OnKeyDown,OnLButtonDown etc etc and do what is needed. For example, in my OnDraw(CDC *cdc) I call viewer()-frame(); I had to do a couple of funky things to get this to work properly . I can give you more details if you want to go that way. I see. In this case, the above on-demand rendering trick won't work as ViewerBase::run() performs various tests in order to determine if osgViewer::ViewerBase::frame() should be called to redraw the display. Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using pbuffer as a texture.
Hi Nicolas, Personally I'd just create a osg::Camera an assign a FBO attachments and a FinalDrawCallback to do a glReadPixels/osg::Image::readPixels() and then store the osg::Image. You could attach this Camera to the main GraphicsContext/Window of your application and just use it's NodeMask to toggle it on/off when you need to take a picture. There isn't any need to create a pbuffer these days, unless you want a totally offscreen application that never has an onscreen windows to associated an FBO with. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Some thoughts on the new DisplacementMapping technique
Hi Sebastian, On 19 January 2015 at 12:43, Sebastian Messerschmidt sebastian.messerschm...@gmx.de wrote: after inspecting the new DisplacementMappingTechnique I have some ideas. First of all, the shader source code should be configurable from the outside via interface in order to integrate it into own pipelines (in my case I have a CustomShaderProgram based pipeline. Making the methods of the osgTerrain::GeometryPool virtual might a means of achieving this. Allow you to overload the osg::Program creation. Another option might be to create an interface to let one set the program from the outside, alongside with an option to retrieve the defines that would have been injected. I am actually working on adding support to osg::State, osg::Program and osg::Shader for passing on #define's to the Shaders, and have these #define's match up to osg::StateSet::setMode(GLenum,..) management of glEnable/glDisable. This would eventually be user customizable, but in the first instance my intention is to have the normally toggling of GL_LIGHTING, or GL_TEXTURE_* map to #define GL_LIGHTING etc. that gets included infront of a Shader when it's compiled. This approach would allow use to blend fixed function style OSG usage with Shaders. Potentially this approach could be a new take on doing shader composition. Second suggestion: The use of tesselation shaders. Currently you are pushing a lot vertex buffers around for tiles with a regular grid. The idea of the GeometryPool is that most of the osg::Geometry are now shared so the number of VBO's being managed is now far lower than it used to be with the brute force GeometryTechnique. With Geocentric databases the grids aren't actually regular, it takes double maths to make sure the curvature it correct when you set up the osg::Geometry to share. It might be more efficient only pushing 4 vertices and letting the tesselation do the rest. It might be even more efficient to move the displacement there, since each vertex would be touched exactly once in terms of transform. My work I checked in last on using geometry shaders to toggle the edge of the triangles to fit with terrain has worked as I intended but performance hit is far greater than I expected - it's around 3 times slower on the GPU when using the geometry shader than when just using the vertex and fragment shaders to displacement mapping. For the small visual quality improvement the use of geometry shaders provide I'm incline to think for most users they aren't a good tradeoff. It's could be that tessellation shaders will be good solution, it's something I've only briefly looked at so can't comment on it more deeply. The issue of using double maths to compute the base mesh that is displaced is something that will require us to still do stuff on the CPU unless we start pushing double data down to the GPU, but here dragons lie... I'm open to suggestions, especially if you pony up some code to illustrate what you have in mind :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] left/right alternating stereo
Hi, does OpenSceneGraph supports left/right alternating stereo as output? I'm working on a system where I need to set this type of stereo because side by side stereo doesn't work on it but I have found working this type of stereo that is available on Bino open source video player. This type of stereo is described at the following link among supported output techniques: http://bino3d.org/doc/bino.html#Output-Techniques Does exist in OpenSceneGraph a similar type of stereo? Thank you! Cheers, Francesco Francesco Argese -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62373#62373 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
