Re: [osg-users] What's the difference between put rttcamera under root node and viewer?
Hi silver In our project we have a driving simulator using rear view mirrors. And we had the same issues about what should be seen in the mirror and what in the main view. First we had no shadows and light effects in the mirrors, but after some time, we figured that light effects are essential in the mirrors to, but shadows are to expensive... So we ended up having the following scene graph: RootNode - PostProcessingNode - MainView PreRenderer - VisualRootNode - ShadowedScene - Terrain - Models - Particles - Environment (Sky, Clouds) - Common PreRenderers (LightMap, Tracks, etc) So in other words we defined an VisualRootNode that holds all the Content that is common for every viewer (main or mirror). The upper most RootNode contains all the Postpro stuff and Prerenderers that are only for the main view. Then to render the Mirrors we created PreRender Cameras that are not owned by the scenegraph but share the same GraphicsContext. This is an important Point. They work like the StatsHandler or HelpHandler with their apropriate PostRender Cameras, which never appear in a scene graph but still the use the main GraphicsContext... These cameras render the VisualRootNode Content to a texture, and this texture can then be applied to a mirror geometry somewhere in our car model. So there is a decision you have to take what you want to display in the main view and what in the mirrors. I hope this gave you some ideas. Now I have a question for you: How did you integrate SpeedTree? Can you provide your implementation? I am working on it, but stuck somehow.You can also write to me personnaly... Cheers, Daniel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65803#65803 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer Node render order problem Win32 osg 3.4
Hi Ted, With a quick scan of your post I can't spot a reason for the redendering order issue, in general I would expect that OSG-3.4 will be functioning more correctly than OSG-2.8.x as there have been lots of improvements over the years, sometimes fixes actually mean that something that worked by fluke before no longer works as the OSG is actually doing what the settings are telling it to rather than ignoring them. So spotting the undefined elements may well be key. As a general note, osgViewer::CompositeViewer should have osgViewer::View attached to it NOT osgViewer::Viewer as you are doing - it's a composite of View's not composite of Viewer. If you look at all the OSG example they illustrate the correct usage. It might be that this helps address the problem you are seeing. If it doesn't then modifying an existing OSG example to illustrate your usage case and share this as a complete example so that others can reproduce the problem first hand. Robert. On 30 November 2015 at 16:39, ted morris wrote: > > Greetings OSG'ers. > > I have a program which utilizes CompositeViewer to render a "corner > window" view of my scene graph, within a bigger main window view. To > achieve a boarder effect around the corner window viewport, a HUD overlay > used to render a grey box underneath the 2nd view corner window. > > It worked without a hitch in an older version, 2.8.5 win32 of > OpenSceneGraph (build with VisualStudio). > > But when I recompiled the program with a later built version (CMake.exe/VS > 2013), I get rather strange object rendering order problems with the > objects in the same scene graph with the **2nd, corner window** of the > osgCompositeViewer. The **first main window** renders perfectly fine. The > essence of the code is below. A lot of extra code is used for determining > the appropriate window and HUD boarder 'frame' dimensions and camera view > frustums, but barring that, it is pretty straight forward and not much to > it, I think. > > To simplify the code a little bit for brevity, I have the removed > Trackball code because with much testing on various configurations this > doesn't change the observed behavior anyway (nor does any lighting mode). > > I did try clone(osg::CopyOp::SHALLOW_COPY) of the entire scene graph > model, and even re-creating parts ofit from scratch and the same > strange rendering order behavior resulted. > > Any advice or insights would be greatly appreciated, > > thanks all, > > ted > > > > . > . > . > // osgViewers decl on the heap > osg::ref_ptr m_viewer; > osg::ref_ptr m_OVERLAYviewer; > osg::ref_ptr m_dualviewer; > osg::Camera * m_HUDcam; > // view manipulators configured and constrained as appropriate... > // <-- code removed for brevity...> > osgGA::NodeTrackerManipulator * m_Camera_followcar; > osgGA::NodeTrackerManipulator::TrackerMode m_trackerMode; > osgGA::NodeTrackerManipulator::RotationMode m_rotationMode; > osgGA::TrackballManipulator * m_tbm; > > // NOTE: gw is a wxWidgets OpenGL context canvas set up earlier... > m_viewer->getCamera()->setGraphicsContext(gw); > m_viewer->getCamera()->setClearColor(osg::Vec4(153./0xff, 216./0xff, > 238./0xff, 1.0)); > // use CullMask to hide rendering of specific nodes in the scene > m_viewer->getCamera()->setCullMask(0x04); > > m_viewer->getCamera()->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); > > // create a camera to set up the projection and model view matrices, and > the subgraph to drawn in the HUD > osg::Camera* camera = new osg::Camera; > > // set the projection matrix > //camera->setProjectionMatrix(osg::Matrix::ortho2D(0,1280,0,1024)); > m_width_fraction_of_mainW = 0.225; // 0.25; > m_height_fraction_of_mainW = 0.275; //(1.0/3.0); > // ll => "lower left", ur => "upper right" > int xll = -(int)(m_width_fraction_of_mainW * m_viewersize.GetX())/2; > int yll = -(int)(m_height_fraction_of_mainW * m_viewersize.GetY())/2; > int yur = -yll; > double left = (double)xll/(double)(yur-yll); > double right = -left; > double bottom = -0.5; > double top = 0.5; > double zfar = 13000.0; // make arbitrarily huge ... but not too big so for > things like a skydome won't get clipped > double znear = 4.5; > // scale everything so clipping plane is about 0.25 meters > double scale_fac = 0.5/znear; > > znear *= scale_fac; > left *= scale_fac; > right *= scale_fac; > top*= scale_fac; > bottom *= scale_fac; > > camera->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); > // draw subgraph after main camera view. > > // we don't want the camera to grab event focus from the viewers main > camera(s). > //camera->setAllowEventFocus(true); > camera->setAllowEventFocus(false); > > double cornerX0 = 1.0 - m_width_fraction_of_mainW; > double cornerY0 = 1.0 - m_height_fraction_of_mainW; > camera->setViewport( > (int)( cornerX0 * m_viewersize.GetX()+5 ), > (int)( cornerY0 * m_viewersize.GetY()+5 ), > (int)( m_width_fractio
[osg-users] CompositeViewer Node render order problem Win32 osg 3.4
Greetings OSG'ers. I have a program which utilizes CompositeViewer to render a "corner window" view of my scene graph, within a bigger main window view. To achieve a boarder effect around the corner window viewport, a HUD overlay used to render a grey box underneath the 2nd view corner window. It worked without a hitch in an older version, 2.8.5 win32 of OpenSceneGraph (build with VisualStudio). But when I recompiled the program with a later built version (CMake.exe/VS 2013), I get rather strange object rendering order problems with the objects in the same scene graph with the **2nd, corner window** of the osgCompositeViewer. The **first main window** renders perfectly fine. The essence of the code is below. A lot of extra code is used for determining the appropriate window and HUD boarder 'frame' dimensions and camera view frustums, but barring that, it is pretty straight forward and not much to it, I think. To simplify the code a little bit for brevity, I have the removed Trackball code because with much testing on various configurations this doesn't change the observed behavior anyway (nor does any lighting mode). I did try clone(osg::CopyOp::SHALLOW_COPY) of the entire scene graph model, and even re-creating parts ofit from scratch and the same strange rendering order behavior resulted. Any advice or insights would be greatly appreciated, thanks all, ted . . . // osgViewers decl on the heap osg::ref_ptr m_viewer; osg::ref_ptr m_OVERLAYviewer; osg::ref_ptr m_dualviewer; osg::Camera * m_HUDcam; // view manipulators configured and constrained as appropriate... // <-- code removed for brevity...> osgGA::NodeTrackerManipulator * m_Camera_followcar; osgGA::NodeTrackerManipulator::TrackerMode m_trackerMode; osgGA::NodeTrackerManipulator::RotationMode m_rotationMode; osgGA::TrackballManipulator * m_tbm; // NOTE: gw is a wxWidgets OpenGL context canvas set up earlier... m_viewer->getCamera()->setGraphicsContext(gw); m_viewer->getCamera()->setClearColor(osg::Vec4(153./0xff, 216./0xff, 238./0xff, 1.0)); // use CullMask to hide rendering of specific nodes in the scene m_viewer->getCamera()->setCullMask(0x04); m_viewer->getCamera()->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); // create a camera to set up the projection and model view matrices, and the subgraph to drawn in the HUD osg::Camera* camera = new osg::Camera; // set the projection matrix //camera->setProjectionMatrix(osg::Matrix::ortho2D(0,1280,0,1024)); m_width_fraction_of_mainW = 0.225; // 0.25; m_height_fraction_of_mainW = 0.275; //(1.0/3.0); // ll => "lower left", ur => "upper right" int xll = -(int)(m_width_fraction_of_mainW * m_viewersize.GetX())/2; int yll = -(int)(m_height_fraction_of_mainW * m_viewersize.GetY())/2; int yur = -yll; double left = (double)xll/(double)(yur-yll); double right = -left; double bottom = -0.5; double top = 0.5; double zfar = 13000.0; // make arbitrarily huge ... but not too big so for things like a skydome won't get clipped double znear = 4.5; // scale everything so clipping plane is about 0.25 meters double scale_fac = 0.5/znear; znear *= scale_fac; left *= scale_fac; right *= scale_fac; top*= scale_fac; bottom *= scale_fac; camera->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); // draw subgraph after main camera view. // we don't want the camera to grab event focus from the viewers main camera(s). //camera->setAllowEventFocus(true); camera->setAllowEventFocus(false); double cornerX0 = 1.0 - m_width_fraction_of_mainW; double cornerY0 = 1.0 - m_height_fraction_of_mainW; camera->setViewport( (int)( cornerX0 * m_viewersize.GetX()+5 ), (int)( cornerY0 * m_viewersize.GetY()+5 ), (int)( m_width_fraction_of_mainW * m_viewersize.GetX()-5 ), (int)( m_height_fraction_of_mainW * m_viewersize.GetY()-5 ) ); zfar = 1; camera->setProjectionMatrixAsFrustum(left,right, bottom, top, znear, zfar); camera->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); camera->setGraphicsContext(gw); camera->setCullMask(0x02); camera->setRenderOrder(osg::Camera::POST_RENDER,1); // =false: we don't want the camera to grab event focus from the viewers main camera(s). camera->setAllowEventFocus(true); //(false); m_OVERLAYviewer->setCamera(camera); m_OVERLAYviewer->getCamera()->setGraphicsContext(gw); // m_Camera_followcar = new osgGA::NodeTrackerManipulator; . . . // set up the scene for the camera and camera view using the loaded scene // model m_OVERLAYviewer->setSceneData(themodel); // try HUD slave cam for drawing a boarder m_HUDcam = new osg::Camera; //HUDcam->setProjectionMatrixAsOrtho(0.5*xll,0.5*xur,0.5*yll, 0.5*yur, -1000.0,1000.0); m_HUDcam->setProjectionMatrix( osg::Matrix::ortho2D(0, m_viewersize.GetX(),0, m_viewersize.GetY())); // don't let other cam influence this camera's transform view matrix m_HUDcam->setReferenceFrame(osg::Transform::ABSOLUTE_RF); // only clear the depth b
Re: [osg-users] osgUtil::DelaunayTriangulator's QUESTION?
Have you considered using constraints? http://trac.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00200.html -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Stats Handler showing prerender cameras
Hi all, Currently the statshandler can show the main camera plus slave cameras. The available cameras are fetched via viewer->getcameras method. It would be great if the list of interesting cameras could be customized to show for instance an interesting prerender camera. Adding it via customstatline is kindof stupid since the whole functionality is already there... Anybody else had this need? I think of writing a submission... Cheers, Daniel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65798#65798 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GraphicContext null
marchingcubes wrote: > This may be due to the fact that Fedora now runs gdm on its own screen. > > e.g. it used to be that you could more or less assume setting DISPLAY=:0 and > running an X11 application would show the app on the machines 'local' > display. With Fedora 22+ this is now DISPLAY=:1 > > It looks to me, after glancing at the window setup code, that the Traits used > to configure a 'single screen' will default to 0 as the screen number, and > thus fail to create the context, as the logged-in user is not authed to > create resources on the gdm screen. > I tried to set the variable to :1 and xeyes run but I am still getting 0 from getNumScreens(). The sequence I'm using is: Code: osg::GraphicsContext::WindowingSystemInterface* wsi = osg::GraphicsContext::getWindowingSystemInterface(); if (wsi) _maxPipes = wsi->getNumScreens(); Is this correct? Tony V -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65797#65797 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
