Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hi Doug, On Mon, Nov 9, 2009 at 5:54 PM, Doug McCorkle mc...@iastate.edu wrote: Candidly, I think that the VR Juggler configuration and device management is better than what is in OSG. I realize that is a personal preference but I like the VR Juggler windowing API and hardware management and configuration tools and implementation. There is nothing stopping you from using the VR juggler configuration to set the osgViewer Camera slaves up, osgViewer can happily be an implementation detail if VR juggler is flexible enough to not force it's own window creation. I also like the leanness (it is a word amazingly) of the VR Juggler approach and implementation for windowing and device management. But... it rather does hobble the OSG in the way you are present using the OSG. You don't get access to the more sophisticated threading models, RTT support, DatabasePager you have wire up yourself... Most of what is supported in osgViewer I do not need or want. I really like the core OSG scenegraph and the file loaders but beyond that we do not need all of the event handling, manipulator tools, or other nodekit integration that osgViewer provides. We need a flexible scenegraph that we can control much of what is going on under-the-hood with windowing and events. I believe you can do all this with using osgViewer and you'll get more out of the OSG as well. If you want to do windowing yourself then the ideal tool would be to create the windows and then using GraphicsWindow's ability to inherit the parent window to use. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG v2.8.0
Hi Jacob, On Mon, Nov 9, 2009 at 7:52 PM, Jacob Armstrong jaco...@hotmail.com wrote: Alright, I'll just ignore the link errors for ogr. My main concern is the absence of osgdem, which I was using from OSG-1.2. Any idea why that's not in 2.8? Also, any ideas on how to incorporate VPBMaster? Do I first need to set up OSG? Is VPBMaster just an add-on to OSG? I'm just looking to use VPBMaster as a replacement for OSGDem. VirtualPlanetBuilder contains osgdem, as well as set of other utitlities for building databases. You'll be able to use osgdem in much the same way as you did in the OSG-1.2 days. However, if you want to scale your databases up to multi-gibabyte all the way up to multi-terrabyte they you'll need to use vpbmaster. Have a look at the VPB website for more info. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL error 'out of memory'
Hi Cory, Are you using frame buffer objects and an nvidia card? Try running the osgprerender example and see if you get the same error. If you do it's a nvidia driver bug. I've come this a number of times and whilst there are legitimate reasons for getting the error in my case it's always been a driver bug. Kim. 2009/11/10 Cory Riddell c...@codeware.com: When I render my scene, I'm getting this in the log: Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) This is on a Windows XP machine with 4GB of RAM. I suspect it isn't complaining about running out of that memory though. Is it video RAM that I have run out of? Cory ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgWidget - menu and select from list
Hi all, I'd like to make a very simple GUI inside my OSG app [1]. All I need is a menu (osgwidgetmenu example is OK) and once a menu item is selected I need to create a list of choices. The choices are all strings, but can be too many to fit onto the screen. So, I need some kind of list box that can scroll. Is this possible with osgWidget? Any other easy alternatives? thanks jp [1] Assume the app is full-screen with default platform osg created windows, i.e. no Qt/Wx/... -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] LISPSM problem/question
Hi, I am using the LISPSM shadow technique. It works great for the most of the time. However i have noticed that the specular-light component doesn't seems to work. Is this a know issue or am I doing something wrong? /Fredrik -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19400#19400 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LISPSM problem/question
Hi Frederik, Default vertex shader ( see line 278 of osgShadow::StandardShadowMap) passes specular component through gl_SecondaryColor. If you expect specular to be mixed with diffuse and ambient on primary gl_Color then you may need to adjust the shaders. Use setMainVertexShader / setMainFragmentShader methods to alter default shaders. I cannot exclude there is a bug somewere. I did not test specular highlits with osgshadow example. If there is a bug, then again, above setXXXshader methods could be most probably used to apply workarounds. Cheers, Wojtek Lewandowski - Original Message - From: Fredrik HemstrAsm fre...@foi.se To: osg-users@lists.openscenegraph.org Sent: Tuesday, November 10, 2009 1:32 PM Subject: [osg-users] LISPSM problem/question Hi, I am using the LISPSM shadow technique. It works great for the most of the time. However i have noticed that the specular-light component doesn't seems to work. Is this a know issue or am I doing something wrong? /Fredrik -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19400#19400 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Bug in osgGA::SphericalManipulator
Hi, i tried to use -Y as up vector i set it in MatrixManipulator and i tried to set Code: SphericalManipulator *spm = new SphericalManipulator; spm -setHomePosition( osg::Vec3( 0,0,0 ),osg::Vec3( 0,0,0 ),osg::Vec3( 0,-1,0 ) ); both changes doesnt work because SphericalManipulator dont use the upvector for calculations Has anybody already changed this camera manipulator to another Up vector? Thank you! Cheers, Matthias -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19403#19403 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Setting CullVisitor
How do I set my own custom CullVisitor? I'm doing the following:
osg::Camera *camera = viewer.getCamera();
osgViewer::Renderer *render =
dynamic_castosgViewer::Renderer *(camera-getRenderer());
if (!render)
{
return false;
}
osgUtil::CullVisitor *cv = new myCullVisitor;
render-getSceneView(0)-setCullVisitor(cv);
I seem to be calling my cull visitor every other frame and it looks like the
renderer has multiple SceneViews. Should I be iteratoring over the scene views
attached to the renderer? Why do I have multiple SceneViews?
Is there a better way? I can not find examples on how to do this..
I need my own CullVisitor because I've defined my own node type that needs
special cull handling.
I'm using OSG 2.6.
Paul P.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget - menu and select from list
On Tue, 2009-11-10 at 12:43 +0200, J.P. Delport wrote: Hi all, I'd like to make a very simple GUI inside my OSG app [1]. All I need is a menu (osgwidgetmenu example is OK) and once a menu item is selected I need to create a list of choices. The choices are all strings, but can be too many to fit onto the screen. So, I need some kind of list box that can scroll. Is this possible with osgWidget? Any other easy alternatives? This should be fairly easy to do; I will modify the menu example and try to show you how it's done. thanks jp [1] Assume the app is full-screen with default platform osg created windows, i.e. no Qt/Wx/... -- Follow us on Twitter! http://twitter.com/emperorlinux EmperorLinux, Inc. http://www.emperorlinux.com 1-888-651-6686 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problems with transparency in the QOsgWidget for QT
Hi Mike, position-setScale(osg::Vec3(0.01,0.01,0.01)); When you use scale in a Transform, the geometry's normals also get scaled. The normals are used to compute lighting, so it's normal (geez, bad pun) that lighting is wrong. You just need to tell OpenGL to rescale normals: position-getOrCreateStateSet()-setMode(GL_RESCALE_NORMAL, osg::StateAttribute::ON); You could also use GL_NORMALIZE, same result. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting CullVisitor
Hi Paul,
Why do I have multiple SceneViews?
There are always two SceneViews if you're using multithreading - they're
used on alternating frames as you've seen. Just set your CullVisitor for
both, or a separate instance of your CullVisitor for each instance.
Whenever I've had to change something on SceneView instances, I had to
do it on both instances. I expect if your CullVisitor has some local
state, you'd have to use two separate instances, one for each SceneView,
so that threading works correctly and doesn't try to modify data that's
being read in another thread.
I need my own CullVisitor because I've defined my own node type that needs
special cull handling.
You could just override the traverse() method of your node type, that's
how I normally do it. It keeps changes local to the overridden node
class instead of propagating changes to other parts of the app.
void traverse(osg::NodeVisitor nv)
{
if (nv.getVisitorType() == osg::NodeVisitor::CULL_VISITOR)
{
osgUtil::CullVisitor* cv =
dynamic_castosgUtil::CullVisitor*(nv);
// ...
}
osg::Node::traverse(nv); // call base class version.
// (replace Node by whatever the base class of your overridden
// node type is)
}
Hope this helps,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hello Robert, On Nov 10, 2009, at 2:51 AM, Robert Osfield wrote: Hi Doug, On Mon, Nov 9, 2009 at 5:54 PM, Doug McCorkle mc...@iastate.edu wrote: Candidly, I think that the VR Juggler configuration and device management is better than what is in OSG. I realize that is a personal preference but I like the VR Juggler windowing API and hardware management and configuration tools and implementation. There is nothing stopping you from using the VR juggler configuration to set the osgViewer Camera slaves up, Correct, this would be just like how Performer is handled in VR Juggler. We have looked at this off and on over the past ~2 years and there does not seem to be much upside for all the work this would require. osgViewer can happily be an implementation detail if VR juggler is flexible enough to not force it's own window creation. Correct, but again, that would assume that the OSG windowing implementation is better than what we already have. My personal opinion is that the windowing implementation in VR Juggler is better but we can disagree on this point. I also like the leanness (it is a word amazingly) of the VR Juggler approach and implementation for windowing and device management. But... it rather does hobble the OSG in the way you are present using the OSG. You don't get access to the more sophisticated threading models, RTT support, DatabasePager you have wire up yourself... You are assuming we do not already have these tools Most of what is supported in osgViewer I do not need or want. I really like the core OSG scenegraph and the file loaders but beyond that we do not need all of the event handling, manipulator tools, or other nodekit integration that osgViewer provides. We need a flexible scenegraph that we can control much of what is going on under-the-hood with windowing and events. I believe you can do all this with using osgViewer and you'll get more out of the OSG as well. If you want to do windowing yourself then the ideal tool would be to create the windows and then using GraphicsWindow's ability to inherit the parent window to use. Your comment above is the best option in my opinion but would require OSG to become a compile time dependency of VR Juggler. Right now OSG is included in 1 file of VR Juggler which makes VR Juggler very portable. I think another good option would be to figure out how to make GraphicsWindowEmbedded work with multiple contexts. If we did this then we would have a direct SceneView replacement where all SceneView apps could easily migrate to osgViewer. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting CullVisitor
Thanks for the quick response...
Did this:
render-getSceneView(0)-setCullVisitor(cv);
render-getSceneView(1)-setCullVisitor(cv);
and now I'm getting:
Warning:createOrReuseRenderLeaf() skipping multiply refrenced entry.
Warning:createOrReuseRenderLeaf() skipping multiply refrenced entry.
Warning:createOrReuseRenderLeaf() skipping multiply refrenced entry.
Warning:createOrReuseRenderLeaf() skipping multiply refrenced entry.
Paul P.
- Original Message
From: Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Tue, November 10, 2009 8:57:38 AM
Subject: Re: [osg-users] Setting CullVisitor
Hi Paul,
Why do I have multiple SceneViews?
There are always two SceneViews if you're using multithreading - they're used
on alternating frames as you've seen. Just set your CullVisitor for both, or a
separate instance of your CullVisitor for each instance.
Whenever I've had to change something on SceneView instances, I had to do it on
both instances. I expect if your CullVisitor has some local state, you'd have
to use two separate instances, one for each SceneView, so that threading works
correctly and doesn't try to modify data that's being read in another thread.
I need my own CullVisitor because I've defined my own node type that needs
special cull handling.
You could just override the traverse() method of your node type, that's how I
normally do it. It keeps changes local to the overridden node class instead of
propagating changes to other parts of the app.
void traverse(osg::NodeVisitor nv)
{
if (nv.getVisitorType() == osg::NodeVisitor::CULL_VISITOR)
{
osgUtil::CullVisitor* cv =
dynamic_castosgUtil::CullVisitor*(nv);
// ...
}
osg::Node::traverse(nv); // call base class version.
// (replace Node by whatever the base class of your overridden
// node type is)
}
Hope this helps,
J-S
-- __
Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL error 'out of memory'
Nope. Running an ATI FireGL V7700 card. What are some of the legitimate reasons that OpenGL may be unable to allocate memory? Is it likely to be video memory or some other type of memory? Cory Kim Bale wrote: Hi Cory, Are you using frame buffer objects and an nvidia card? Try running the osgprerender example and see if you get the same error. If you do it's a nvidia driver bug. I've come this a number of times and whilst there are legitimate reasons for getting the error in my case it's always been a driver bug. Kim. 2009/11/10 Cory Riddell c...@codeware.com: When I render my scene, I'm getting this in the log: Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) This is on a Windows XP machine with 4GB of RAM. I suspect it isn't complaining about running out of that memory though. Is it video RAM that I have run out of? Cory ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL error 'out of memory'
You can monitor gfx mem usage with this tool: http://www.nuclearplayground.com/NuclearPlayground/ Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Tue, Nov 10, 2009 at 9:36 AM, Cory Riddell c...@codeware.com wrote: Nope. Running an ATI FireGL V7700 card. What are some of the legitimate reasons that OpenGL may be unable to allocate memory? Is it likely to be video memory or some other type of memory? Cory Kim Bale wrote: Hi Cory, Are you using frame buffer objects and an nvidia card? Try running the osgprerender example and see if you get the same error. If you do it's a nvidia driver bug. I've come this a number of times and whilst there are legitimate reasons for getting the error in my case it's always been a driver bug. Kim. 2009/11/10 Cory Riddell c...@codeware.com c...@codeware.com: When I render my scene, I'm getting this in the log: Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) This is on a Windows XP machine with 4GB of RAM. I suspect it isn't complaining about running out of that memory though. Is it video RAM that I have run out of? Cory ___ osg-users mailing listosg-us...@lists.openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing listosg-us...@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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hi Doug, On Tue, Nov 10, 2009 at 2:20 PM, Doug McCorkle mc...@iastate.edu wrote: osgViewer can happily be an implementation detail if VR juggler is flexible enough to not force it's own window creation. Correct, but again, that would assume that the OSG windowing implementation is better than what we already have. My personal opinion is that the windowing implementation in VR Juggler is better but we can disagree on this point. With the next rev of the OSG osgViewer will support both OpenGL 3.x, OpenGL ES 1.1 and OpenGL ES 2.0, if VR Juggler supported osgViewer with it's native windowing support then you'd get all this for free. Without using osgViewer you'd need to implement your own windowing support for these. But... it rather does hobble the OSG in the way you are present using the OSG. You don't get access to the more sophisticated threading models, RTT support, DatabasePager you have wire up yourself... You are assuming we do not already have these tools RTT support in the OSG relies upon the ability to create on FBO and PBuffers on demand, unless you've implemented your own integration of PBuffers with the OSG then you'll be missing this capability. I believe you can do all this with using osgViewer and you'll get more out of the OSG as well. If you want to do windowing yourself then the ideal tool would be to create the windows and then using GraphicsWindow's ability to inherit the parent window to use. Your comment above is the best option in my opinion but would require OSG to become a compile time dependency of VR Juggler. Right now OSG is included in 1 file of VR Juggler which makes VR Juggler very portable. I don't thinking using window inheritance would require much more OSG/VRJuggler glue code than you presently have, it just be different code. Window inheritance would leave the OSG able to create the GL3 and GLES contexts as well, so you'd get these features for free :-) I think another good option would be to figure out how to make GraphicsWindowEmbedded work with multiple contexts. If we did this then we would have a direct SceneView replacement where all SceneView apps could easily migrate to osgViewer. Once of the goals of GraphicsWindowEmedded is to provide similar support to that of using SceneView directly, if you aren't able to use it in this role then it's something I need to look at. Window inheritance is still far more flexible and powerful w.r.t OSG capabilities so this is the route I'd recommend. SceneView and GraphicsWindowEmbedded on their own hobble the OSG. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problems with transparency in the QOsgWidget for QT
Thank you! it works!! Cheers, Mike -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19414#19414 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG with QGLWidget and Anti Aliasing
Hi there
I am absolutly new to the OSG stuff (and it's the first time I attend in
a mailing list) and trying to get my OSG work in a Qt environment. I
made my own OSG/Qt class, which inherits from QGLWidget and
osgViewer::Viewer. Most of the OSG stuff works, but I can't enable the
anti aliasing or the multi sampling.
I tried the following two configurations:
1.
ref_ptr DisplaySettings displaySettings = new DisplaySettings;
displaySettings-setNumMultiSamples(16);
modelView-setDisplaySettings( displaySettings.get() );
2.
osg::DisplaySettings::instance()-setNumMultiSamples(8);
But this didn't work. Does anybody had the same problems or have some
ideas to solve this problem. I attached my class and header files.
If I'm doing something wrong concerning the mailing list rules, just
let me know.
Thanks a lot and regards
Dominic
/**
* File: qwtqlwidget.cpp
* Authors: Dominic Stalder, Thomas Bruederli
*
* Implementation of a codeQGLWidget/code and a
codeosgViewer::Viewer/code extension
* with implemented virtual functions:
*
* - initializeGL()
* - resizeGL(int width, int height)
* - paintGL()
*
* Furthermore the class is the base codeosgViewer::Viewer/code
implementation to support
* osg in our game.
*
* This file is part of the Qt-based cross-platform Wii Tetris Game
*
* Copyright (C) 2009-2010, Dominic Stalder Thomas Bruederli
* Licensed under the GNU Lesser General Public License (LGPL) as published
* by the Free Software Foundation at http://www.gnu.org/licenses/lgpl-3.0.txt
*
* $Id: qwtglwidget.cpp 237 2009-11-01 17:08:27Z stald3 $
*/
#include QtOpenGL
#include ui/components/qwtglwidget.h
/**
* Class constructor.
*
* Inherited from codeQGLWidget/code and codeosgViewer::Viewer/code for
the use with wii tetris.
*
* @param parent parent instance of an codeQGLWidget/code object
*/
QwtGLWidget::QwtGLWidget(QWidget *parent) : QGLWidget(parent)
{
osg::DisplaySettings::instance()-setNumMultiSamples(4);
// creates a new osg graphics window
osgGraphicsWindow = new osgViewer::GraphicsWindowEmbedded(0, 0,
width(), height());
// sets the open gl widget to accept focus by clicking
setFocusPolicy(Qt::ClickFocus);
// enables the automatic OpenGL buffer swapping (default = true) of the
QGLWidget
setAutoBufferSwap(true);
// enables the mouse tracking of the QGLWidget
setMouseTracking(true);
}
/**
* Class destructor.
*
* Frees all the memory used in the codeQwtGLWidget/code instance.
*/
QwtGLWidget::~QwtGLWidget()
{
// adapts close window events
osgGraphicsWindow-getEventQueue()-closeWindow();
}
/**
* Implementation of the virtual function, is called before the first call of
paintGL() and resizeGL
* and once whenever the codeQGLWidget/code has been assigned a new
codeQGLContext/code.
*/
void QwtGLWidget::initializeGL()
{
// gets the master camera of the view
osg::Camera *masterCamera = getCamera();
// sets the default viewport (full width and full height) of the master
camera
masterCamera-setViewport(new osg::Viewport(0, 0, width(), height()));
// sets the graphics context that provides the machanism for managing
the OpenGL graphcis context associated with this camera
masterCamera-setGraphicsContext(osgGraphicsWindow.get());
// sets the threading model the rendering traversals will use
setThreadingModel(osgViewer::Viewer::SingleThreaded);
// connects the timeout() signal of the QTimer with the updateGL slot
// the updateGL slot will call glDraw() and this will call paintGL()
connect(repaintTimer, SIGNAL(timeout()), this, SLOT(updateGL()));
// starts the repaint timer with an interval of 10 ms - repaint with a
frequency of 100 Hz
repaintTimer.start(10);
}
/**
* Implementation of the virtual function, is called whenever the
codeQGLWidget/code has been resized.
*
* @param width new width of the codeQGLWidget/code
* @param height new height of the codeQGLWidget/code
*/
void QwtGLWidget::resizeGL(int width, int height)
{
// returns the viewers event queue and placing the window resize event
on the back of the event queue
osgGraphicsWindow-getEventQueue()-windowResize(0, 0, width, height);
// calls the resized method and updates the underlyning window and the
associated cameras to stay in sync
osgGraphicsWindow-resized(0, 0, width, height);
}
/**
* Implementation of the virtual function, is called whenever the
codeQGLWidget/code needs to be painted.
*/
void QwtGLWidget::paintGL()
{
// draws one frame of the osg scene on to the screen
frame();
}
/**
* Translates the codeQInputEvent/code to a
codeosgGA::GUIEventAdapter/code.
*
* @param event user input of type codeQInputEvent/code
*/
void
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hello Robert, On Nov 10, 2009, at 8:42 AM, Robert Osfield wrote: Hi Doug, On Tue, Nov 10, 2009 at 2:20 PM, Doug McCorkle mc...@iastate.edu wrote: osgViewer can happily be an implementation detail if VR juggler is flexible enough to not force it's own window creation. Correct, but again, that would assume that the OSG windowing implementation is better than what we already have. My personal opinion is that the windowing implementation in VR Juggler is better but we can disagree on this point. With the next rev of the OSG osgViewer will support both OpenGL 3.x, OpenGL ES 1.1 and OpenGL ES 2.0, if VR Juggler supported osgViewer with it's native windowing support then you'd get all this for free. Without using osgViewer you'd need to implement your own windowing support for these. We had OGL 3 context creation in VR Juggler last March. But... it rather does hobble the OSG in the way you are present using the OSG. You don't get access to the more sophisticated threading models, RTT support, DatabasePager you have wire up yourself... You are assuming we do not already have these tools RTT support in the OSG relies upon the ability to create on FBO and PBuffers on demand, unless you've implemented your own integration of PBuffers with the OSG then you'll be missing this capability. No we have not and I can create an RTT camera without osgViewer. I believe you can do all this with using osgViewer and you'll get more out of the OSG as well. If you want to do windowing yourself then the ideal tool would be to create the windows and then using GraphicsWindow's ability to inherit the parent window to use. Your comment above is the best option in my opinion but would require OSG to become a compile time dependency of VR Juggler. Right now OSG is included in 1 file of VR Juggler which makes VR Juggler very portable. I don't thinking using window inheritance would require much more OSG/VRJuggler glue code than you presently have, it just be different code. Window inheritance would leave the OSG able to create the GL3 and GLES contexts as well, so you'd get these features for free :-) Very true but I am willing to pay the price to use a different windowing API. Again, just another personal preference we can disagree on. I think another good option would be to figure out how to make GraphicsWindowEmbedded work with multiple contexts. If we did this then we would have a direct SceneView replacement where all SceneView apps could easily migrate to osgViewer. Once of the goals of GraphicsWindowEmedded is to provide similar support to that of using SceneView directly, if you aren't able to use it in this role then it's something I need to look at. I was incorrect in my statement above. I can create an osgViewer for every context which would be equivalent to creating an SceneView for every context. I got some threads crossed in my mind. Window inheritance is still far more flexible and powerful w.r.t OSG capabilities so this is the route I'd recommend. SceneView and GraphicsWindowEmbedded on their own hobble the OSG. But this is your opinion that they are hobbling OSG. For folks like me and I am sure some others in the OSG community both of these interfaces provide a slick and easy way to get a majority of the OSG support that they need with another software API. This enables the OSG community to be larger and more active than without these interfaces in place. I think this is one of the great things about the OSG. I can grab as much or as little of the OSG as I need too. If I as a developer am willing to give up some functionality in the OSG in using these interfaces why should that matter? Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OsgViewer and Windows Forms
I have a .NET Windows Forms application with 2 OSG-based classes: 1. A UserControl/OsgViewer based class, and 2. An OSG-based engine that handles file loading, scenegraph mods, etc. The .NET example from the OSG website gets the viewer initialized: http://www.openscenegraph.org/projects/osg/wiki/Support/FAQ#HowdoIembedanOSGviewerina.NETcontrol My question is: What is the best way to call the viewer frame function in this application? I have tried updating the viewer in a new thread. It appears to perform well, but it presents thread safety problems because my scenegraph modifications (from the engine) mostly take place in the UI thread (button press events, etc). I can simplify the engine code (avoid mutexes around function calls) if I can get the viewer to update on that thread. To move the viewer onto the UI thread, I am calling the viewer frame function in an override of the OnPaint method of the UserControl class. I've created a Forms timer that periodically calls Invalidate on the UserControl to make sure OnPaint is called with some regularity. Other timer-related code insures that the Invalidate call isn't made at a greater frequency than we expect the viewer to be able to render. It appears to be working OK, but I'm worried that this approach will be fragile as we run this application on different systems with different scene contents. Comments or suggestions? Thanks, Todd ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problems with transparency in the QOsgWidget for QT
now a screenshot AdapterWidget for QT -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19419#19419 attachment: nice.jpg___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OsgViewer and Windows Forms
Hi there, I'm doing something very similar - OSG hosted in .NET. The way I've done this is I have my render thread running in a loop and instead of rendering continuously, I have a StackRenderArgs hosted in the OSG .NET control. Then if I want to render, I push a RenderArgs onto the stack. Inside the render thread, I check if there is an item in the stack, if so, pop it out and render. That way I have control over rendering (I only render when I need to in my app, as its a visualisation and doesn't need to run continuously). Also in the render thread, if there are no stack objects I will Thread.Sleep(1) to pause the render thread for 1ms (The minimum allowed time). This is just one solution. You could alternatively call frame directly and just use some object to handle the thread locking (Lock keyword in C# or Monitor::Enter/Exit in C++/CLI). Calling frame from within MainForm_Paint is not that bad an idea, I've donet his myself for DirectX visualisation applications before. Cheers, Andrew On Tue, Nov 10, 2009 at 3:48 PM, Smelik, R.M. (Ruben) ruben.sme...@tno.nlwrote: Hi Todd, I've had the same choices to make for my .NET / OSG program. I'm not sure whether or not the .NET timer / Invalidate is a stable approach, FYI I'll just explain the solution I've chosen. To avoid all the mutexes and threading issues, I went for a very simple solution. A render thread loops to call frame() and a UI thread processes user actions. Changes to the scene graph are made in two steps: * The UI thread sets a flag indicating what kind of change to the scenegraph is required; * Each iteration, the render threads checks (and clears) all flags and makes the required scenegraph changes before calling frame(). Of course, depending on your application, this can be kind of awkward (although you can replace flags with more detailed modification objects containing loaded models etc.). Kind regards, Ruben From: osg-users-boun...@lists.openscenegraph.org on behalf of Todd J. Furlong Sent: Tue 11/10/2009 4:11 PM To: OpenSceneGraph Users Subject: [osg-users] OsgViewer and Windows Forms I have a .NET Windows Forms application with 2 OSG-based classes: 1. A UserControl/OsgViewer based class, and 2. An OSG-based engine that handles file loading, scenegraph mods, etc. The .NET example from the OSG website gets the viewer initialized: http://www.openscenegraph.org/projects/osg/wiki/Support/FAQ#HowdoIembedanOSGviewerina.NETcontrol My question is: What is the best way to call the viewer frame function in this application? I have tried updating the viewer in a new thread. It appears to perform well, but it presents thread safety problems because my scenegraph modifications (from the engine) mostly take place in the UI thread (button press events, etc). I can simplify the engine code (avoid mutexes around function calls) if I can get the viewer to update on that thread. To move the viewer onto the UI thread, I am calling the viewer frame function in an override of the OnPaint method of the UserControl class. I've created a Forms timer that periodically calls Invalidate on the UserControl to make sure OnPaint is called with some regularity. Other timer-related code insures that the Invalidate call isn't made at a greater frequency than we expect the viewer to be able to render. It appears to be working OK, but I'm worried that this approach will be fragile as we run this application on different systems with different scene contents. Comments or suggestions? Thanks, Todd ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org https://tnoportal.tno.nl/listinfo.cgi/,DanaInfo=lists.openscenegraph.org+osg-users-openscenegraph.org This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ 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] OsgViewer and Windows Forms
Yes, just thinks like Maximise, Minimise, Resize. I also rendered on Activate in case the form lost and regained focus. There's no problems integrating OSG with .NET Windows Forms from what I can see. On Tue, Nov 10, 2009 at 4:11 PM, Todd J. Furlong t...@inv3rsion.com wrote: Thanks for the responses. Ruben: That sounds like a robust way to handle threading issues. We do something similar in VR Juggler based applications where one thread receives input but many have to render. Andrew: Did you have to hook up a lot of UI events to get your scene to refresh during window relocation, etc? We considered not rendering continuously to get around ToolTip transparency issues, but it seemed like it might be complicated to get the control to render when it needs to. -Todd On 11/10/2009 10:56 AM, Andrew Burnett-Thompson wrote: Hi there, I'm doing something very similar - OSG hosted in .NET. The way I've done this is I have my render thread running in a loop and instead of rendering continuously, I have a StackRenderArgs hosted in the OSG .NET control. Then if I want to render, I push a RenderArgs onto the stack. Inside the render thread, I check if there is an item in the stack, if so, pop it out and render. That way I have control over rendering (I only render when I need to in my app, as its a visualisation and doesn't need to run continuously). Also in the render thread, if there are no stack objects I will Thread.Sleep(1) to pause the render thread for 1ms (The minimum allowed time). This is just one solution. You could alternatively call frame directly and just use some object to handle the thread locking (Lock keyword in C# or Monitor::Enter/Exit in C++/CLI). Calling frame from within MainForm_Paint is not that bad an idea, I've donet his myself for DirectX visualisation applications before. Cheers, Andrew On Tue, Nov 10, 2009 at 3:48 PM, Smelik, R.M. (Ruben) ruben.sme...@tno.nl mailto:ruben.sme...@tno.nl wrote: Hi Todd, I've had the same choices to make for my .NET / OSG program. I'm not sure whether or not the .NET timer / Invalidate is a stable approach, FYI I'll just explain the solution I've chosen. To avoid all the mutexes and threading issues, I went for a very simple solution. A render thread loops to call frame() and a UI thread processes user actions. Changes to the scene graph are made in two steps: * The UI thread sets a flag indicating what kind of change to the scenegraph is required; * Each iteration, the render threads checks (and clears) all flags and makes the required scenegraph changes before calling frame(). Of course, depending on your application, this can be kind of awkward (although you can replace flags with more detailed modification objects containing loaded models etc.). Kind regards, Ruben From: osg-users-boun...@lists.openscenegraph.org mailto:osg-users-boun...@lists.openscenegraph.org on behalf of Todd J. Furlong Sent: Tue 11/10/2009 4:11 PM To: OpenSceneGraph Users Subject: [osg-users] OsgViewer and Windows Forms I have a .NET Windows Forms application with 2 OSG-based classes: 1. A UserControl/OsgViewer based class, and 2. An OSG-based engine that handles file loading, scenegraph mods, etc. The .NET example from the OSG website gets the viewer initialized: http://www.openscenegraph.org/projects/osg/wiki/Support/FAQ#HowdoIembedanOSGviewerina.NETcontrol My question is: What is the best way to call the viewer frame function in this application? I have tried updating the viewer in a new thread. It appears to perform well, but it presents thread safety problems because my scenegraph modifications (from the engine) mostly take place in the UI thread (button press events, etc). I can simplify the engine code (avoid mutexes around function calls) if I can get the viewer to update on that thread. To move the viewer onto the UI thread, I am calling the viewer frame function in an override of the OnPaint method of the UserControl class. I've created a Forms timer that periodically calls Invalidate on the UserControl to make sure OnPaint is called with some regularity. Other timer-related code insures that the Invalidate call isn't made at a greater frequency than we expect the viewer to be able to render. It appears to be working OK, but I'm worried that this approach will be fragile as we run this application on different systems with different scene contents. Comments or suggestions? Thanks, Todd ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting CullVisitor
Hi Paul,
I think there is a better way to set your own visitor, maybe doing:
osgUtil::CullVisitor::prototype()=new MyVisitor();
if you do this before realize() (or run()), then the viewer uses the
prototype of the cull visitor.
Rafa.
On Tue, Nov 10, 2009 at 3:23 PM, paul1...@yahoo.com wrote:
Thanks for the quick response...
Did this:
render-getSceneView(0)-setCullVisitor(cv);
render-getSceneView(1)-setCullVisitor(cv);
and now I'm getting:
Warning:createOrReuseRenderLeaf() skipping multiply refrenced entry.
Warning:createOrReuseRenderLeaf() skipping multiply refrenced entry.
Warning:createOrReuseRenderLeaf() skipping multiply refrenced entry.
Warning:createOrReuseRenderLeaf() skipping multiply refrenced entry.
Paul P.
- Original Message
From: Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Tue, November 10, 2009 8:57:38 AM
Subject: Re: [osg-users] Setting CullVisitor
Hi Paul,
Why do I have multiple SceneViews?
There are always two SceneViews if you're using multithreading - they're used
on alternating frames as you've seen. Just set your CullVisitor for both, or
a separate instance of your CullVisitor for each instance.
Whenever I've had to change something on SceneView instances, I had to do it
on both instances. I expect if your CullVisitor has some local state, you'd
have to use two separate instances, one for each SceneView, so that threading
works correctly and doesn't try to modify data that's being read in another
thread.
I need my own CullVisitor because I've defined my own node type that needs
special cull handling.
You could just override the traverse() method of your node type, that's how I
normally do it. It keeps changes local to the overridden node class instead
of propagating changes to other parts of the app.
void traverse(osg::NodeVisitor nv)
{
if (nv.getVisitorType() == osg::NodeVisitor::CULL_VISITOR)
{
osgUtil::CullVisitor* cv =
dynamic_castosgUtil::CullVisitor*(nv);
// ...
}
osg::Node::traverse(nv); // call base class version.
// (replace Node by whatever the base class of your overridden
// node type is)
}
Hope this helps,
J-S
-- __
Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Rafael Gaitán Linares
Instituto de Automática e Informática Industrial http://www.ai2.upv.es
Ciudad Politécnica de la Innovación
Universidad Politécnica de Valencia
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hi Doug, On Tue, Nov 10, 2009 at 3:00 PM, Doug McCorkle mc...@iastate.edu wrote: We had OGL 3 context creation in VR Juggler last March. Cool, what platforms do you have this support? Perhaps we can learn a little about adding it to osgViewer :-) RTT support in the OSG relies upon the ability to create on FBO and PBuffers on demand, unless you've implemented your own integration of PBuffers with the OSG then you'll be missing this capability. No we have not and I can create an RTT camera without osgViewer. You'll be limited to just using FBO's or frame buffer copies though. One of the things I've striven for with osg::Camera and it's RTT support is that it can handle using a range of different back end implementations, including Pbuffers which are the fallback for drivers that don't have FBOs. osgViewer provides the ability for RTT Camera's to create Pbuffers if and when they need them. Window inheritance is still far more flexible and powerful w.r.t OSG capabilities so this is the route I'd recommend. SceneView and GraphicsWindowEmbedded on their own hobble the OSG. But this is your opinion that they are hobbling OSG. For folks like me and I am sure some others in the OSG community both of these interfaces provide a slick and easy way to get a majority of the OSG support that they need with another software API. This enables the OSG community to be larger and more active than without these interfaces in place. I think this is one of the great things about the OSG. I can grab as much or as little of the OSG as I need too. If I as a developer am willing to give up some functionality in the OSG in using these interfaces why should that matter? The reasons why it matters to me are: 1) I just want the OSG to shine as best it can without any limitations 2) I want the OSG users to be able to reuse as much expertise as possible - so they can learn from OSG examples, tutorials and discussions on osg-users. The more differences there are in usage the less this is possible. 3) I want to be able to roll out new features to all users, so they all get to benefit quickly and without breaking existing apps. The lower level users dive in setting up the OSG the more difficult it is to avoid breaking things and the longer it'll take them to take advantage of them. 4) Get more users using and therefore testing the same code paths so that we can improve the quality of the OSG. 5) Avoid having to support users with obscure problems that I can't recreate myself because they have their own way of doing windowing threading. If I can recreate problems myself then it become very difficult to do support. Hence my desire to sheppard users into using API's that unify OSG usage, and if we get the OSG API's right then this needn't come with any compromises for end users application, rather the opposite, if we get it right it's a win-win, I get any easier life, and you get more features and more reliable software in an easier to use package. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting CullVisitor
Jean-Sébastien Guay wrote: I need my own CullVisitor because I've defined my own node type that needs special cull handling. You could just override the traverse() method of your node type, that's how I normally do it. It keeps changes local to the overridden node class instead of propagating changes to other parts of the app. J-S is right. If you're developing a Node that requires special handling during the cull traversal, writing a custom CullVisitor is overkill. You should just override traverse() in your custom node. If you ever submit your node for inclusion in OSG, you can migrate the cull handling code into osgUtil::CullVisitor at the time you make the submission. This is what I did when I developed OcclusionQueryNode. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting CullVisitor
Hi Paul, I know I risk making the thread diverge into unrelated concerns, but I wanted to ask: If you ever submit your node for inclusion in OSG, you can migrate the cull handling code into osgUtil::CullVisitor at the time you make the submission. This is what I did when I developed OcclusionQueryNode. Are there advantages to modifying CullVisitor rather than overriding traverse(), other than one dynamic_cast per frame per node? I think if that's the only advantage, I'd personally prefer keeping all the code related to the node type local to the type itself, even if that node type were to be included into OSG. But that's a coding style concern, I just want to know what you think about this and if there's something I have missed. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting CullVisitor
On 11/10/2009 06:07 PM, Paul Martz wrote: Jean-Sébastien Guay wrote: I know I risk making the thread diverge into unrelated concerns, but I wanted to ask: No actually, I think this is the right direction for this thread to take. :-) Are there advantages to modifying CullVisitor rather than overriding traverse(), other than one dynamic_cast per frame per node? I think if that's the only advantage, I'd personally prefer keeping all the code related to the node type local to the type itself, even if that node type were to be included into OSG. Not sure. When I looked into this for OcclusionQueryNode, I was just following the existing coding pattern for core OSG nodes. Most of them had the bulk of their cull traversal functionality in the CullVisitor::apply() for that particular node type, and did not override the traverse() member function. -Paul If you want to customize culling for a node that is a subclass of osg::Geode, you pretty much need to write your own cull visitor and override CullVisitor::apply(Geode); the low-level code that puts geometry into the render graph is contained in that function and is called after the traverse() function of the node class. Tim ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hello Robert, On Nov 10, 2009, at 10:31 AM, Robert Osfield wrote: Hi Doug, On Tue, Nov 10, 2009 at 3:00 PM, Doug McCorkle mc...@iastate.edu wrote: We had OGL 3 context creation in VR Juggler last March. Cool, what platforms do you have this support? We have windows and X. Cocoa is waiting until Apple gets their act together. Perhaps we can learn a little about adding it to osgViewer :-) You already are, you have Paul Martz doing the port and Todd Furlong is an active member of the community as well. RTT support in the OSG relies upon the ability to create on FBO and PBuffers on demand, unless you've implemented your own integration of PBuffers with the OSG then you'll be missing this capability. No we have not and I can create an RTT camera without osgViewer. You'll be limited to just using FBO's or frame buffer copies though. Correct, but again this is my choice as a developer. One of the things I've striven for with osg::Camera and it's RTT support is that it can handle using a range of different back end implementations, including Pbuffers which are the fallback for drivers that don't have FBOs. osgViewer provides the ability for RTT Camera's to create Pbuffers if and when they need them. Right but because OSG is flexible I can make this choice as a developer. Window inheritance is still far more flexible and powerful w.r.t OSG capabilities so this is the route I'd recommend. SceneView and GraphicsWindowEmbedded on their own hobble the OSG. But this is your opinion that they are hobbling OSG. For folks like me and I am sure some others in the OSG community both of these interfaces provide a slick and easy way to get a majority of the OSG support that they need with another software API. This enables the OSG community to be larger and more active than without these interfaces in place. I think this is one of the great things about the OSG. I can grab as much or as little of the OSG as I need too. If I as a developer am willing to give up some functionality in the OSG in using these interfaces why should that matter? The reasons why it matters to me are: 1) I just want the OSG to shine as best it can without any limitations 2) I want the OSG users to be able to reuse as much expertise as possible - so they can learn from OSG examples, tutorials and discussions on osg-users. The more differences there are in usage the less this is possible. 3) I want to be able to roll out new features to all users, so they all get to benefit quickly and without breaking existing apps. The lower level users dive in setting up the OSG the more difficult it is to avoid breaking things and the longer it'll take them to take advantage of them. This is a choice a developer can make knowing the disadvantages to it. The OSG should not force a specific usage type. Again, in my case, I am willing to put up with this extra work to take advantage of some other toolkits. 4) Get more users using and therefore testing the same code paths so that we can improve the quality of the OSG. 5) Avoid having to support users with obscure problems that I can't recreate myself because they have their own way of doing windowing threading. If I can recreate problems myself then it become very difficult to do support. In this case, I and am guessing others have other support methods which work well. Hence my desire to sheppard users into using API's that unify OSG usage, and if we get the OSG API's right then this needn't come with any compromises for end users application, rather the opposite, if we get it right it's a win-win, I get any easier life, and you get more features and more reliable software in an easier to use package. Those are all great goals for the OSG. As a developer for my application I only need the core functionality of OSG therefore by maintaining an interface that provides access to the core OSG we all can move forward. That is all that I request. Keep an interface available that provides easy access into core OSG. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Would someone be willing to help me diagnose a performance issue?
Hello, I have two applications, both of which are displaying basically the same scene. One application runs at 230+ fps while the other runs at about 45 fps. I'm trying to figure out what is causing this performance difference. Using high-precision timers, I've been able to determine that the difference occurs somewhere in the rendering of the scene graph, but I'm not 100% sure where. I have a couple of ideas, but each will take some amount of time to investigate, and so I was hoping someone might be able to lead me towards the most-correct answer. The first idea I had concerns differences in how the scene graphs are structured in each application. The quick app works simply by loading the three models that it needs (from FLT files, so these 'models' are in fact complex sub-graphs) and attaches them to the root node, and sets that root node as the scene data. The slow app loads every model that could possibly ever be used (52 in all, and again each 'model' could actually be a complex sub-graph). These 52 nodes are then attached to the root, and their visibility is turned off by setting their node mask to 0. Then, if the user of the application wants to see a model, the app will copy the node (and all of it's children) and then add this copy to the scene root group, with the visibility turned on. This way, if the user of the app wants to populate the scene with many instances of the same model, they can do so, because each time they do it, a separate copy of the node is made. I realize that there are a lot of things that can be done to make the slow app more memory-efficient. For instance, it could use lazy loading to load a model only when it is needed (although this may cause a noticeable delay, but that would probably be fine). And if the user wants to see several instances of this model, this could be accomplished without copying the model's entire subgraph. Instead, we could simply create a new matrix transform, and add THAT to the root, and add the model's node as a child of this new matrix transform (at which point, the model's node will have more than one Matrix Transform parent). However, these issues seem to pertain more towards memory efficiency than rendering efficiency, so I'm not sure if this is going to solve my immediate problem (although it is almost certainly something I will implement later on). Related to this, I was wondering if anyone had an explanation as to what the Camera / View statistics referred to. I read the Quick Start Guide, and it had excellent information about the Event/Update/Cull/Draw/GPU chart at the top of the statistics screen, but I'm not exactly sure what the statistics in the Camera / View windows refer to. For instance, does the Vertices stat refer to the total number of vertices in all of the drawables, whether those drawables are visible or not? The reason I ask is that, in terms of these statistics, both the Quick App and the Slow App have nearly-identical numbers in the View section, but in the Camera section, the Slow App's numbers are way, way, way higher. I wonder if this tells me something about how to optimize the Slow App to bring it up to speed. The other major difference I noticed was in the threading model. The Quick App uses DrawThreadPerContext and the Slow App uses SingleThreaded. I tried getting the slow app to use DrawThreadPerContext by setting the environment variable, but it ignored that value and chose the SingleThreaded model for me. I can probably figure out why this happens, but I'm curious to know if you think this will affect performance much? Thanks so much to whomever has patience to read all this! Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19436#19436 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Would someone be willing to help me diagnose a performance issue?
Slowly minimize the differences between the slow machine and the fast machine until the problem goes away. When it does, you have isolated the problem. Also bear in mind it could be the machine itself (hardware, drivers, etc.) On Nov 10, 2009 12:42 PM, Frank Sullivan knarf.navil...@gmail.com wrote: Hello, I have two applications, both of which are displaying basically the same scene. One application runs at 230+ fps while the other runs at about 45 fps. I'm trying to figure out what is causing this performance difference. Using high-precision timers, I've been able to determine that the difference occurs somewhere in the rendering of the scene graph, but I'm not 100% sure where. I have a couple of ideas, but each will take some amount of time to investigate, and so I was hoping someone might be able to lead me towards the most-correct answer. The first idea I had concerns differences in how the scene graphs are structured in each application. The quick app works simply by loading the three models that it needs (from FLT files, so these 'models' are in fact complex sub-graphs) and attaches them to the root node, and sets that root node as the scene data. The slow app loads every model that could possibly ever be used (52 in all, and again each 'model' could actually be a complex sub-graph). These 52 nodes are then attached to the root, and their visibility is turned off by setting their node mask to 0. Then, if the user of the application wants to see a model, the app will copy the node (and all of it's children) and then add this copy to the scene root group, with the visibility turned on. This way, if the user of the app wants to populate the scene with many instances of the same model, they can do so, because each time they do it, a separate copy of the node is made. I realize that there are a lot of things that can be done to make the slow app more memory-efficient. For instance, it could use lazy loading to load a model only when it is needed (although this may cause a noticeable delay, but that would probably be fine). And if the user wants to see several instances of this model, this could be accomplished without copying the model's entire subgraph. Instead, we could simply create a new matrix transform, and add THAT to the root, and add the model's node as a child of this new matrix transform (at which point, the model's node will have more than one Matrix Transform parent). However, these issues seem to pertain more towards memory efficiency than rendering efficiency, so I'm not sure if this is going to solve my immediate problem (although it is almost certainly something I will implement later on). Related to this, I was wondering if anyone had an explanation as to what the Camera / View statistics referred to. I read the Quick Start Guide, and it had excellent information about the Event/Update/Cull/Draw/GPU chart at the top of the statistics screen, but I'm not exactly sure what the statistics in the Camera / View windows refer to. For instance, does the Vertices stat refer to the total number of vertices in all of the drawables, whether those drawables are visible or not? The reason I ask is that, in terms of these statistics, both the Quick App and the Slow App have nearly-identical numbers in the View section, but in the Camera section, the Slow App's numbers are way, way, way higher. I wonder if this tells me something about how to optimize the Slow App to bring it up to speed. The other major difference I noticed was in the threading model. The Quick App uses DrawThreadPerContext and the Slow App uses SingleThreaded. I tried getting the slow app to use DrawThreadPerContext by setting the environment variable, but it ignored that value and chose the SingleThreaded model for me. I can probably figure out why this happens, but I'm curious to know if you think this will affect performance much? Thanks so much to whomever has patience to read all this! Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19436#19436 ___ 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] Would someone be willing to help me diagnose a performance issue?
At the highest level: Update - cpu processing your application is performing Cull - cpu processing performed by osg in traversing the scene graph and packaging drawing state Draw - cpu processing for sending drawing state to gpu and gpu processing of the drawing state If Update stage is large, you need to determine what part of your application is taking the time and optimize it. If Cull stage is large the scene hierarchy is too complex and needs to be optimized - spatial optimization, flatten static hierarchies, ... If Draw stage is large then you need to determine if you are vertex or pixel limited. If you grab the window corner and shrink/expand it's size and the performance increases/decreases significantly, then you are pixel/fill limited (too much depth complexity/too much pixel processing). If the performance doesn't change then you are probably vertex/transform limited (too many verts/too much vertex processing). It's actually much more complex than this, but it's how I start diagnosing performance issues. Run your scene in osgViewer to see how fast it renders. You might have to build the scene in your regular app and then save the scene root to an .ive file, which you can load into osgViewer. A really good tool to use is an OpenGL command logger. It logs all the actual OpenGL commands that OSG is issuing and can help identify problem areas. Brian -osg-users-boun...@lists.openscenegraph.org wrote: - To: osg-users@lists.openscenegraph.org From: Frank Sullivan knarf.navil...@gmail.com Sent by: osg-users-boun...@lists.openscenegraph.org Date: 11/10/2009 12:41PM Subject: [osg-users] Would someone be willing to help me diagnose a performance issue? Hello, I have two applications, both of which are displaying basically the same scene. One application runs at 230+ fps while the other runs at about 45 fps. I'm trying to figure out what is causing this performance difference. Using high-precision timers, I've been able to determine that the difference occurs somewhere in the rendering of the scene graph, but I'm not 100% sure where. I have a couple of ideas, but each will take some amount of time to investigate, and so I was hoping someone might be able to lead me towards the most-correct answer. The first idea I had concerns differences in how the scene graphs are structured in each application. The quick app works simply by loading the three models that it needs (from FLT files, so these 'models' are in fact complex sub-graphs) and attaches them to the root node, and sets that root node as the scene data. The slow app loads every model that could possibly ever be used (52 in all, and again each 'model' could actually be a complex sub-graph). These 52 nodes are then attached to the root, and their visibility is turned off by setting their node mask to 0. Then, if the user of the application wants to see a model, the app will copy the node (and all of it's children) and then add this copy to the scene root group, with the visibility turned on. This way, if the user of the app wants to populate the scene with many instances of the same model, they can do so, because each time they do it, a separate copy of the node is made. I realize that there are a lot of things that can be done to make the slow app more memory-efficient. For instance, it could use lazy loading to load a model only when it is needed (although this may cause a noticeable delay, but that would probably be fine). And if the user wants to see several instances of this model, this could be accomplished without copying the model's entire subgraph. Instead, we could simply create a new matrix transform, and add THAT to the root, and add the model's node as a child of this new matrix transform (at which point, the model's node will have more than one Matrix Transform parent). However, these issues seem to pertain more towards memory efficiency than rendering efficiency, so I'm not sure if this is going to solve my immediate problem (although it is almost certainly something I will implement later on). Related to this, I was wondering if anyone had an explanation as to what the Camera / View statistics referred to. I read the Quick Start Guide, and it had excellent information about the Event/Update/Cull/Draw/GPU chart at the top of the statistics screen, but I'm not exactly sure what the statistics in the Camera / View windows refer to. For instance, does the Vertices stat refer to the total number of vertices in all of the drawables, whether those drawables are visible or not? The reason I ask is that, in terms of these statistics, both the Quick App and the Slow App have nearly-identical numbers in the View section, but in the Camera section, the Slow App's numbers are way, way, way higher. I wonder if this tells me something about how to optimize the Slow App to bring it up to speed. The other major difference I noticed was in the threading model. The Quick App uses DrawThreadPerContext and the Slow App uses
Re: [osg-users] Would someone be willing to help me diagnose aperformance issue?
Hello Frank, You should try to create the 52 models cache outside the rendering tree (in a separate list or a distinct tree detached from the camera). Even if the visibility is turned off, I think the rendering visitors (update, cull, etc.) are still browsing the whole tree. Also, don't forget that if you full your RAM with all the cached models, you'll have to use virtual memory on the hard drive which is much less efficient. As for the threading model, I don't think this should affect performance much if you have only one display window. If you have multiple rendering context, it's very important to use multithreading if you wand reasonable performance. You can change the threading model through the osgViewer::Viewer::setThreadingModel() method. Hope this helps! Frederic Drolet, M. Sc. Computing Solutions and Experimentations | Solutions informatiques et expérimentations Systems of Systems | Systèmes de systèmes DRDC Valcartier | RDDC Valcartier 2459, boul. Pie-XI North Quebec, Quebec G3J 1X5 CANADA Phone | Téléphone: (418) 844-4000 ext : 4820 Fax | Télécopieur: (418) 844-4538 E-mail | Courriel: frederic.dro...@drdc-rddc.gc.ca Web : www.valcartier.drdc-rddc.gc.ca http://www.valcartier.drdc-rddc.gc.ca From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Philip Lowman Sent: November-10-09 12:52 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Would someone be willing to help me diagnose aperformance issue? Slowly minimize the differences between the slow machine and the fast machine until the problem goes away. When it does, you have isolated the problem. Also bear in mind it could be the machine itself (hardware, drivers, etc.) On Nov 10, 2009 12:42 PM, Frank Sullivan knarf.navil...@gmail.com wrote: Hello, I have two applications, both of which are displaying basically the same scene. One application runs at 230+ fps while the other runs at about 45 fps. I'm trying to figure out what is causing this performance difference. Using high-precision timers, I've been able to determine that the difference occurs somewhere in the rendering of the scene graph, but I'm not 100% sure where. I have a couple of ideas, but each will take some amount of time to investigate, and so I was hoping someone might be able to lead me towards the most-correct answer. The first idea I had concerns differences in how the scene graphs are structured in each application. The quick app works simply by loading the three models that it needs (from FLT files, so these 'models' are in fact complex sub-graphs) and attaches them to the root node, and sets that root node as the scene data. The slow app loads every model that could possibly ever be used (52 in all, and again each 'model' could actually be a complex sub-graph). These 52 nodes are then attached to the root, and their visibility is turned off by setting their node mask to 0. Then, if the user of the application wants to see a model, the app will copy the node (and all of it's children) and then add this copy to the scene root group, with the visibility turned on. This way, if the user of the app wants to populate the scene with many instances of the same model, they can do so, because each time they do it, a separate copy of the node is made. I realize that there are a lot of things that can be done to make the slow app more memory-efficient. For instance, it could use lazy loading to load a model only when it is needed (although this may cause a noticeable delay, but that would probably be fine). And if the user wants to see several instances of this model, this could be accomplished without copying the model's entire subgraph. Instead, we could simply create a new matrix transform, and add THAT to the root, and add the model's node as a child of this new matrix transform (at which point, the model's node will have more than one Matrix Transform parent). However, these issues seem to pertain more towards memory efficiency than rendering efficiency, so I'm not sure if this is going to solve my immediate problem (although it is almost certainly something I will implement later on). Related to this, I was wondering if anyone had an explanation as to what the Camera / View statistics referred to. I read the Quick Start Guide, and it had excellent information about the Event/Update/Cull/Draw/GPU chart at the top of the statistics screen, but I'm not exactly sure what the statistics in the Camera / View windows refer to. For instance, does the Vertices stat refer to the total number of vertices in all of the drawables, whether those drawables are visible or not? The reason I ask is that, in terms of these statistics, both the Quick App and the Slow App have nearly-identical numbers in the
Re: [osg-users] Setting CullVisitor
Jean-Sébastien Guay wrote on Tuesday, November 10, 2009 10:55 AM: Are there advantages to modifying CullVisitor rather than overriding traverse(), other than one dynamic_cast per frame per node? I think if that's the only advantage, I'd personally prefer keeping all the code related to the node type local to the type itself, even if that node type were to be included into OSG. But that's a coding style concern, I just want to know what you think about this and if there's something I have missed. From experience, I can say that one dynamic_cast per frame per node can really add up to hurt performance :) -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting CullVisitor
Hi Bryan, From experience, I can say that one dynamic_cast per frame per node can really add up to hurt performance :) Depends how many nodes. For example, for osgOcean::OceanScene, you should generally have only one in your whole scene. So in that case, one dynamic_cast per frame per node == one dynamic_cast per frame Of course, I wouldn't advocate doing one dynamic_cast per frame in a node that's going to be used all over the place, hundreds of thousands of times in the scene... :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ShadowMap problem...
I have taken the code I think I need from the osgShadow example and tried to
add shadows to my existing application.The problem is that the shadow
map displayed in the debug window is just a gray-ish circle centered on a
white-ish background, nothing at all what I expected and no details that
look anything like the objects in my scene. This remains the same
regardless of whare I put my light source. Any suggestions?
My code is as follows:
W
osgViewer::CompositeViewer viewer;
osgViewer::View* view = new osgViewer::View;
viewer.addView(view);
view-setUpViewInWindow(50, 50, currentWidth, currentHeight, 0);
osg::ref_ptrosgShadow::ShadowedScene shadowedScene = new
osgShadow::ShadowedScene;
shadowedScene-setReceivesShadowTraversalMask(ReceivesShadowTraversalMask);
shadowedScene-setCastsShadowTraversalMask(CastsShadowTraversalMask);
osg::ref_ptrosgShadow::ShadowMap sm = new osgShadow::ShadowMap;
shadowedScene-setShadowTechnique(sm.get());
int mapres = 1024;
sm-setTextureSize(osg::Vec2s(mapres,mapres));
m_World = new osg::Group;
// add some things to m_World.. Removed for brevity sake
// get the bounds of the model.
osg::ComputeBoundsVisitor cbbv;
m_World-accept(cbbv);
osg::BoundingBox bb = cbbv.getBoundingBox();
osg::Vec4 lightpos;
viewer.getView(0)-getEventHandlers().push_front(new
osgViewer::StatsHandler);
viewer.getView(0)-getEventHandlers().push_front(mykey);
std::vectorosg::Camera* cameras;
viewer.getCameras(cameras);
cameras[0]-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR
);
cameras[0]-setProjectionMatrixAsPerspective(40.0, 1.3, 1.0,
SKYDOME_RANGE*1.1f);
bool postionalLight = true;
if (postionalLight)
{
lightpos.set(bb.center().x(), bb.center().y(), bb.zMax() +
bb.radius()*2.0f ,1.0f);
}
else
{
lightpos.set(0.5f,0.25f,0.8f,0.0f);
}
osg::ref_ptrosg::LightSource ls = new osg::LightSource;
ls-getLight()-setPosition(lightpos);
shadowedScene-addChild((osg::Node*)m_World);
shadowedScene-addChild(ls.get());
bool updateLightPosition = true;
viewer.realize();
viewer.getView(0)-setSceneData(shadowedScene.get());
bool debugHUD = true;
if(debugHUD)
{
osgViewer::Viewer::Windows windows;
viewer.getWindows(windows);
if (windows.empty()) return 1;
osgShadow::ShadowMap* sm =
dynamic_castosgShadow::ShadowMap*(shadowedScene-getShadowTechnique());
if( sm ) {
osg::ref_ptrosg::Camera hudCamera = sm-makeDebugHUD();
// set up cameras to rendering on the first window available.
hudCamera-setGraphicsContext(windows[0]);
hudCamera-setViewport(0,0,windows[0]-getTraits()-width,
windows[0]-getTraits()-height);
viewer.getView(0)-addSlave(hudCamera.get(), false);
}
}
// display the help
key-showHelp();
while( !viewer.done() )
{
cameras[0]-setViewMatrix(key-getViewMat());
if (updateLightPosition)
{
float t = viewer.getFrameStamp()-getSimulationTime();
if (postionalLight)
{
lightpos.set(bb.center().x()+sinf(t)*bb.radius(),
bb.center().y() + cosf(t)*bb.radius(), bb.zMax() + bb.radius()*3.0f ,1.0f);
}
else
{
lightpos.set(sinf(t),cosf(t),1.0f,0.0f);
}
ls-getLight()-setPosition(lightpos);
osg::Vec3f lightDir(-lightpos.x(),-lightpos.y(),-lightpos.z());
lightDir.normalize();
ls-getLight()-setDirection(lightDir);
}
viewer.frame();
}
I also must add that I am using my own shaders and have reproduced the
shadowmap shader code as follows:
uniform sampler2D osgShadow_baseTexture;
uniform sampler2DShadow osgShadow_shadowTexture;
uniform vec2 osgShadow_ambientBias;
vec4 myCalculations()
{
// Details Omitted;
}
void main (void)
{
// My shader code details omitted
// shadow mapping
vec4 color = gl_Color * texture2D( osgShadow_baseTexture,
gl_TexCoord[0].xy );
gl_FragColor = color * (osgShadow_ambientBias.x + shadow2DProj(
osgShadow_shadowTexture, gl_TexCoord[1] ) * osgShadow_ambientBias.y);
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap problem...
Thanks, That seem to make some change, instead of a grayish circle, I now see a moving roundish object... W -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, November 10, 2009 1:31 PM To: OpenSceneGraph Users Subject: Re: [osg-users] ShadowMap problem... Hi Wyatt, Any suggestions? I haven't tried your code, but I don't see you calling ShadowMap::setLight() anywhere... Try to add this once your light source is initialized: sm-setLight(ls-getLight()); Other than that, at first glance your code seems OK. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap problem...
Hi Wyatt, Thanks, That seem to make some change, instead of a grayish circle, I now see a moving roundish object... Sounds familiar... Han Solo: [flying across the deserts of Tatooine] I think my eyes are getting better. Instead of a big dark blur, I see a big bright blur. http://www.imdb.com/character/ch002/quotes /goofing off Give me a minute, I'll try it out and see. Just have to ask, if you try with only one object and a ground plane (a really simple scene) do you get the same results? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap problem...
Hi Wyatt,
Just have to ask, if you try with only one object and a ground plane (a
really simple scene) do you get the same results?
I just tested, and your code seems to work. I've attached a source file
which is the osgshadow example, with the main() commented out and your
code in its place. Have a look, the only changes were to put the
ModelThree scene as child of your m_World group and to make sure I had a
manipulator, and make everything compile...
You seem to be using a skydome (based on a variable called SKYDOME_RANGE
in the code). You did set your skydome's node mask to ~cast right?
Otherwise what you're seeing is probably your skydome's shadow being
cast over everything... That's one thing about using osgShadow, you need
to make sure things that you don't want to cast shadows don't have the
cast shadow bit in their node mask. Also HUDs should be set that way.
Keep an iron grip on your node masks or you'll have unpleasant
surprises... :-)
The receive shadow node mask is not used for ShadowMap classes, but you
can implement a node that doesn't receive shadows by adding a case in
your shader (a test on a boolean uniform that skips the shadow test) and
set that uniform to true at your scene's root and false for each node
that you don't want to receive shadows.
And btw, osgShadow::ShadowMap is not really designed for positional
lights, because they're omnidirectional and would need 6 full-scene RTT
passes (like a cube map) to be totally accurate. I think (IIRC)
osgShadow::ShadowMap and the ViewDependentShadow classes try to
approximate a directional in that case, but the approximation breaks
down if the light source is positioned inside the bounding box of the
scene... You're better off either approximating the sun with a
directional, or using a spot light for an interior scene.
Hope this helps,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
/* OpenSceneGraph example, osgshadow.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include osg/ArgumentParser
#include osg/ComputeBoundsVisitor
#include osg/Texture2D
#include osg/ShapeDrawable
#include osg/MatrixTransform
#include osg/Geometry
#include osgGA/TrackballManipulator
#include osgGA/FlightManipulator
#include osgGA/DriveManipulator
#include osgGA/KeySwitchMatrixManipulator
#include osgGA/AnimationPathManipulator
#include osgGA/TerrainManipulator
#include osgGA/AnimationPathManipulator
#include osgGA/StateSetManipulator
#include osgViewer/CompositeViewer
#include osgViewer/ViewerEventHandlers
#include osgShadow/ShadowedScene
#include osgShadow/ShadowVolume
#include osgShadow/ShadowTexture
#include osgShadow/ShadowMap
#include osgShadow/SoftShadowMap
#include osgShadow/ParallelSplitShadowMap
#include osgShadow/LightSpacePerspectiveShadowMap
#include osgShadow/StandardShadowMap
#include osgDB/ReadFile
#include osgDB/WriteFile
#include iostream
// for the grid data..
#include terrain_coords.h
// for the model number four - island scene
#include IslandScene.h
static int ReceivesShadowTraversalMask = 0x1;
static int CastsShadowTraversalMask = 0x2;
/*
namespace ModelOne
{
enum Faces
{
FRONT_FACE = 1,
BACK_FACE = 2,
LEFT_FACE = 4,
RIGHT_FACE = 8,
TOP_FACE = 16,
BOTTOM_FACE = 32
};
osg::Node* createCube(unsigned int mask)
{
osg::Geode* geode = new osg::Geode;
osg::Geometry* geometry = new osg::Geometry;
geode-addDrawable(geometry);
osg::Vec3Array* vertices = new osg::Vec3Array;
geometry-setVertexArray(vertices);
osg::Vec3Array* normals = new osg::Vec3Array;
geometry-setNormalArray(normals);
geometry-setNormalBinding(osg::Geometry::BIND_PER_VERTEX);
osg::Vec4Array* colours = new osg::Vec4Array;
geometry-setColorArray(colours);
geometry-setColorBinding(osg::Geometry::BIND_OVERALL);
Re: [osg-users] ShadowMap problem...
No but I'll try it... -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, November 10, 2009 2:11 PM To: OpenSceneGraph Users Subject: Re: [osg-users] ShadowMap problem... Just have to ask, if you try with only one object and a ground plane (a really simple scene) do you get the same results? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Would someone be willing to help me diagnose a performance issue?
Thanks for all of your help and suggestions, people. My plan for the last hour or so has been to first follow Philip's suggestion to see if I can get the Quick App to start behaving like the Slow App. My first step toward that goal was to replicate that 'object cache' by loading all 52 objects, adding them to the scene graph, each with their node masks zero'ed out. Then, for the three objects I actually want to display, I add them again separately. It turns out that this had little effect on frame rate. The Quick App is still quick. Although I still find Frederic's suggestion helpful and I plan on implementing it later, it doesn't look like it will affect the frame rate much, which is what I'm after at this point. So for my next step, I forced the Quick App to use the SingleThreaded model, which is the one that the Slow App uses. This actually seemed to give me a slight performance boost! Probably because, as Frederick mentioned, I only need a single thread for one display window (which is what I have) and so if anything, changing to SingleThreaded sped things up a bit, perhaps by getting rid of the overhead of managing multiple threads. So, the culprit is neither the 'object cache' nor the threading model. I will have to keep plugging ahead I guess. One difference I did notice, though, is that the numbers in the Camera stats window are still much, much higher in the Slow App than either versions of the Quick App. Slow App - Lights: 0 Bins: 30 Depth: 0 Matrices: 15,789 Imposters: 0 Drawables: 15,789 Vertices: 1,361,039 Quick App (without Object Cache) - Lights: 0 Bins: 9 Depth: 0 Matrices: 1,379 Imposters: 0 Drawables: 1,379 Vertices: 299,982 Quick App (with Object Cache) - Lights: 0 Bins: 9 Depth: 0 Matrices: 1,379 Imposters: 0 Drawables: 1379 Vertices: 300,530 I'm not sure exactly what these numbers mean. I thought that perhaps they referred to the total number of objects in the scene graph, whether visible or invisible, and whether or not they are in the viewing frustum. However, I noticed that the numbers change slightly depending on where I place the camera (therefore, I tried to place the camera in the same position for each of the data samples above to get the most comparable results). Also, if that were the case, then Quick App (with Object Cache) should have numbers comparable to Slow App -- they both have the exact same objects loaded and attached to the scene graph. However, both versions of the Quick App have similar numbers, while the Slow App numbers are way, way higher. If anyone can help explain what these stats actually refer to, I think I may be able to track this problem down. Thanks again, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19453#19453 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Would someone be willing to help me diagnose aperformance issue?
Frank Sullivan wrote on Tuesday, November 10, 2009 3:26 PM: Slow App - Lights: 0 Bins: 30 Depth: 0 Matrices: 15,789 Imposters: 0 Drawables: 15,789 Vertices: 1,361,039 Quick App (without Object Cache) - Lights: 0 Bins: 9 Depth: 0 Matrices: 1,379 Imposters: 0 Drawables: 1,379 Vertices: 299,982 Quick App (with Object Cache) - Lights: 0 Bins: 9 Depth: 0 Matrices: 1,379 Imposters: 0 Drawables: 1379 Vertices: 300,530 I'm not sure exactly what these numbers mean. I thought that perhaps they referred to the total number of objects in the scene graph, whether visible or invisible, and whether or not they are in the viewing frustum. However, I noticed that the numbers change slightly depending on where I place the camera (therefore, I tried to place the camera in the same position for each of the data samples above to get the most comparable results). Also, if that were the case, then Quick App (with Object Cache) should have numbers comparable to Slow App -- they both have the exact same objects loaded and attached to the scene graph. However, both versions of the Quick App have similar numbers, while the Slow App numbers are way, way higher. If anyone can help explain what these stats actually refer to, I think I may be able to track this problem down. I believe they refer to the number of Drawables, Vertices, etc. that are actually rendered. It appears that your slow app is rendering about 4-5 times the number of objects. Perhaps it has multiple cameras or render passes that the quick app does not? Perhaps models are getting added multiple times at the same location? How do the numbers change when you add a single model and how is that change different between the two apps? HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Would someone be willing to help me diagnose a performance issue?
Hello Frank, I'm not sure exactly what these numbers mean. You were on the right track. The Camera numbers are the objects that are not culled, and the View numbers are the objects that are in the view's scene, whether they're culled or not. When you set a node's mask to 0, you're force-culling the node. The traversals (whether the update, cull or draw traversals) will visit the top node (that has its node mask to 0), binary-and that with their traversal mask, the result will be 0 so they will not traverse down into them. It's pretty cheap to test, as long as the node mask is really set on the root node of a whole hierarchy, and not on the leaf nodes (Geodes), because that would force the visitors to traverse the whole hierarchy only to find that at the bottom there's nothing to draw. You modified the quick app to have the same object cache as the slow app, but the numbers for the quick app with object cache are actually very similar to those of the quick app without object cache. So that suggests that all the objects you added to the graph (i.e. the object cache) are not being visited by the cull visitor, so they don't affect the stats. Now, you need to examine why the numbers are so much higher for the slow app. Can you modify that one so that it doesn't load up as many objects into the object cache? Also, how many of the loaded objects are visible when you get those stats? And are the objects from the object cache really hidden by setting their root node's node mask to 0, or are they hidden by setting the node mask on some lower node in the hierarchy? It seems to me that some of the hierarchy of the invisible objects is being visited even if they're not being displayed. The number of transforms (Matrices in the stats) and drawables seems pretty high to me for the number of vertices you have visible, so I really think there's something fishy in the way you're hiding the nodes. If you analyze your graph, in the slow app, you've got about 86 vertices per drawable (straight division), and one transform per drawable. In the quick app, you've got 217 vertices per drawable (again straight division) and again one transform per drawable. So in the quick app the geometry is batched better (but only slightly - vertices in the thousands or tens of thousands per drawable would be better on modern cards), and you've got a pretty flat graph (one transform per drawable), though that's pretty normal for a modeling tool (which is what I assume you're working on, or similar tool). There's been much written on how to optimize the graph in the past, so for further reading you could search the archives on that subject. But you've got something weird in the slow app already, as I said above... My hunch is that the way you hide the nodes is different and not optimal. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Would someone be willing to help me diagnose a performance issue?
Thanks, Bryan, I'll try and see if there's anything causing multiple re-draws of the geometry or something. Do you happen to know what the stats under the 'View' column refer to, in this case? E.g., StateSet, Group, Transform, Geode, Drawable, etc. These seem to refer more to higher-level osg concepts, except that this window, too, has a Vertices state which is slightly different than the one under the Camera column (in the Slow App's case, it's 231,648 Unique and 1,389,888 Instance). -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19455#19455 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Would someone be willing to help me diagnose aperformance issue?
Frank Sullivan wrote on Tuesday, November 10, 2009 3:51 PM: Thanks, Bryan, I'll try and see if there's anything causing multiple re-draws of the geometry or something. Do you happen to know what the stats under the 'View' column refer to, in this case? E.g., StateSet, Group, Transform, Geode, Drawable, etc. These seem to refer more to higher-level osg concepts, except that this window, too, has a Vertices state which is slightly different than the one under the Camera column (in the Slow App's case, it's 231,648 Unique and 1,389,888 Instance). I haven't really dug into the stats stuff yet, but you can look at osgViewer/StatsHandler.cpp in the source to get a start. Basically, it uses osg::Stats, which has a map of strings (such as Number of unique Primitives) to values. The values must be updated somewhere in the code; likely, you can search for the string to figure out how exactly they are calculated. HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg::Notify log archive creation
Hi all there, People I´m new to OSG I´m trying to use it wit QT framework and ARToolKit to develop my first Augmented Reality application. First I have integrated OSG ARToolKit and QT quite good, I saw the live video stream from my webcam, but when I tried to add marker detection the application close without any message. Then I need to know how to redirect osg::Notify messages to a log archive to know what is happening with my application. Thanks in advance Ernest ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL error 'out of memory'
Hi, I have the same problem as Cory. I am using svn/trunk. My last tests were using rev 10710 approx (i am not sure). My config is : Seven 64bits (OSG compiled in 32bits), 4GB of RAM, 2 x GTX280 Nvidia cards. I didn't have this problem before. Strangely, I don't have the same problem with another config : XP 64bits (OSG in 32bits), 12GB, Quadro 2700M Nvidia card. Regards, On Tue, Nov 10, 2009 at 3:39 PM, Glenn Waldron wrote: You can monitor gfx mem usage with this tool: http://www.nuclearplayground.com/NuclearPlayground/ Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Tue, Nov 10, 2009 at 9:36 AM, Cory Riddell wrote: Nope. Running an ATI FireGL V7700 card. What are some of the legitimate reasons that OpenGL may be unable to allocate memory? Is it likely to be video memory or some other type of memory? Cory Kim Bale wrote: Hi Cory, Are you using frame buffer objects and an nvidia card? Try running the osgprerender example and see if you get the same error. If you do it's a nvidia driver bug. I've come this a number of times and whilst there are legitimate reasons for getting the error in my case it's always been a driver bug. Kim. 2009/11/10 Cory Riddell : When I render my scene, I'm getting this in the log: Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) This is on a Windows XP machine with 4GB of RAM. I suspect it isn't complaining about running out of that memory though. Is it video RAM that I have run out of? Cory ___ osg-users mailing listosg-us...@lists.openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing listosg-us...@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 ___ 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] Would someone be willing to help me diagnose a performance issue?
Thanks again, guys. Jean-Sebastien, I apologize, but I did not notice your reply until just now! I didn't write the Slow App code myself, but I do have the power to change it, if only on my local machine to test things. You are correct that, in both apps, the hierarchy is very flat, with a single group node, which I'll call the 'Scene Root', and all of the objects in the scene are children of this Scene Root, and siblings of one another. Although, by 'Object', what I really mean is a MatrixTransform that has, as its child, the root of a subgraph that contains many geodes, drawables, statesets, etc. It is the Matrix Transform that is given the 0x00 node mask in both the Quick App and in the Slow App. So, it SHOULD be enough to stop the cull visitor right away, and prevent it from looking any deeper into these objects' subgraphs. However, the way I did it in my Quick App is much simpler than how it is done in the Slow App. In the Quick App, for each object in the scene, I: - Load the FLT file assign the result to a Node* - Create a new Matrix Transform - Set the Node* as a child of the Matrix Transform - Set the Matrix Transform as a child of the Scene Root - Set the Matrix Transform's node mask to 0x00 However, in the Slow App, there's actually a Model class of our own making, that has an osg::Group* member that stores a reference to the model's parent node, and an osg::MatrixTransform* that stores a reference to the model's Matrix Transform. The constructor of this class follows the same basic steps I outlined above, in order to wire everything together, but it's possible that I'm overlooking something amongst the added complexity. Thanks again, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19459#19459 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap problem...
Getting closer to having this working like I think it should, but I have noticed something. When I have one or two objects, say the size of a car, or truck, only. The shadow map looks correct. But when I add my terrain which is approximately x = 5100 by y = 5100, I no longer see the car/truck shadows on the shadow map. Similarly, if I increase the length and width of the bottom box in the osgShadow example, I no longer see the other objects in the shadow map. I assume I am running into some shadow map texture resolution limit or something. What is going on? Tnanks, W -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, November 10, 2009 3:08 PM To: OpenSceneGraph Users Subject: Re: [osg-users] ShadowMap problem... Hi Wyatt, Just have to ask, if you try with only one object and a ground plane (a really simple scene) do you get the same results? I just tested, and your code seems to work. I've attached a source file which is the osgshadow example, with the main() commented out and your code in its place. Have a look, the only changes were to put the ModelThree scene as child of your m_World group and to make sure I had a manipulator, and make everything compile... You seem to be using a skydome (based on a variable called SKYDOME_RANGE in the code). You did set your skydome's node mask to ~cast right? Otherwise what you're seeing is probably your skydome's shadow being cast over everything... That's one thing about using osgShadow, you need to make sure things that you don't want to cast shadows don't have the cast shadow bit in their node mask. Also HUDs should be set that way. Keep an iron grip on your node masks or you'll have unpleasant surprises... :-) The receive shadow node mask is not used for ShadowMap classes, but you can implement a node that doesn't receive shadows by adding a case in your shader (a test on a boolean uniform that skips the shadow test) and set that uniform to true at your scene's root and false for each node that you don't want to receive shadows. And btw, osgShadow::ShadowMap is not really designed for positional lights, because they're omnidirectional and would need 6 full-scene RTT passes (like a cube map) to be totally accurate. I think (IIRC) osgShadow::ShadowMap and the ViewDependentShadow classes try to approximate a directional in that case, but the approximation breaks down if the light source is positioned inside the bounding box of the scene... You're better off either approximating the sun with a directional, or using a spot light for an interior scene. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Would someone be willing to help me diagnose a performance issue?
Hey guys, Just an update: it looks like someone turned off the side culling in the Slow App. This wasn't the case in my Quick App, so I guess that explains both the low frame rates and the comparatively high stats. The Slow App is still only running at 65 fps or so, but my profile data now indicates that the scene graph / rendering is no longer the bottleneck. So, I think that about wraps it up! Thanks to everyone for your help. Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19463#19463 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap problem...
My shadow map is looking mostly correct now after making changes to light type, position etc. However shadows are not appearing in the final rendering. The app I am trying to add shadow mapping to uses textures bound to tex units 0-3. I noticed in the ShadowMap class there were methods for setting the texture unit and wondered if this possibly why I am not seeing the shadows. That is, is my use of tex units 0-3 conflicting with ShadowMaps use of texture units and should I reassign one or the others texture units? W -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, November 10, 2009 3:08 PM To: OpenSceneGraph Users Subject: Re: [osg-users] ShadowMap problem... Hi Wyatt, Just have to ask, if you try with only one object and a ground plane (a really simple scene) do you get the same results? I just tested, and your code seems to work. I've attached a source file which is the osgshadow example, with the main() commented out and your code in its place. Have a look, the only changes were to put the ModelThree scene as child of your m_World group and to make sure I had a manipulator, and make everything compile... You seem to be using a skydome (based on a variable called SKYDOME_RANGE in the code). You did set your skydome's node mask to ~cast right? Otherwise what you're seeing is probably your skydome's shadow being cast over everything... That's one thing about using osgShadow, you need to make sure things that you don't want to cast shadows don't have the cast shadow bit in their node mask. Also HUDs should be set that way. Keep an iron grip on your node masks or you'll have unpleasant surprises... :-) The receive shadow node mask is not used for ShadowMap classes, but you can implement a node that doesn't receive shadows by adding a case in your shader (a test on a boolean uniform that skips the shadow test) and set that uniform to true at your scene's root and false for each node that you don't want to receive shadows. And btw, osgShadow::ShadowMap is not really designed for positional lights, because they're omnidirectional and would need 6 full-scene RTT passes (like a cube map) to be totally accurate. I think (IIRC) osgShadow::ShadowMap and the ViewDependentShadow classes try to approximate a directional in that case, but the approximation breaks down if the light source is positioned inside the bounding box of the scene... You're better off either approximating the sun with a directional, or using a spot light for an interior scene. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] a question about blender and osgExport
Hi Cedric, :D the version of osg is 2.80. and the version of osgExport is the lastest version Thank you! Cheers, ren -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19465#19465 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget - menu and select from list
Hi Jeremy, Jeremy Moles wrote: On Tue, 2009-11-10 at 12:43 +0200, J.P. Delport wrote: Hi all, I'd like to make a very simple GUI inside my OSG app [1]. All I need is a menu (osgwidgetmenu example is OK) and once a menu item is selected I need to create a list of choices. The choices are all strings, but can be too many to fit onto the screen. So, I need some kind of list box that can scroll. Is this possible with osgWidget? Any other easy alternatives? This should be fairly easy to do; I will modify the menu example and try to show you how it's done. thanks, I'm just beginning with osgWidget. jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL error 'out of memory'
Hi all, maybe have a look at the osgmemorytest example and compare numbers between machines/cards/osg versions/driver versions/... If you can show the problem using the example it should be easier to track it down. jp Mourad Boufarguine wrote: Hi, I have the same problem as Cory. I am using svn/trunk. My last tests were using rev 10710 approx (i am not sure). My config is : Seven 64bits (OSG compiled in 32bits), 4GB of RAM, 2 x GTX280 Nvidia cards. I didn't have this problem before. Strangely, I don't have the same problem with another config : XP 64bits (OSG in 32bits), 12GB, Quadro 2700M Nvidia card. Regards, On Tue, Nov 10, 2009 at 3:39 PM, Glenn Waldron wrote: You can monitor gfx mem usage with this tool: http://www.nuclearplayground.com/NuclearPlayground/ Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Tue, Nov 10, 2009 at 9:36 AM, Cory Riddell wrote: Nope. Running an ATI FireGL V7700 card. What are some of the legitimate reasons that OpenGL may be unable to allocate memory? Is it likely to be video memory or some other type of memory? Cory Kim Bale wrote: Hi Cory, Are you using frame buffer objects and an nvidia card? Try running the osgprerender example and see if you get the same error. If you do it's a nvidia driver bug. I've come this a number of times and whilst there are legitimate reasons for getting the error in my case it's always been a driver bug. Kim. 2009/11/10 Cory Riddell : When I render my scene, I'm getting this in the log: Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) This is on a Windows XP machine with 4GB of RAM. I suspect it isn't complaining about running out of that memory though. Is it video RAM that I have run out of? Cory ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto: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 message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
