Re: [osg-users] osgViewer::GraphicsWindowEmbeded causing OpenGL error
Hi Joshua,
I don't know CAVElib personally so can't answer specifics about
integration with it.
A couple of general comments though:
1) Is the CAVElib creating multiple graphics contexts? If so there you'll
need a GraphicsWindow on the OSG per context you can't reuse the
same window per context.
2) Do you really need to use CAVElib? The OSG itself can render
to a cave just by setting up the Viewer slave Camera appropriately.
There is also integration with other 3rd party VR libs.
Robert.
On 9 November 2011 20:53, Joshua Cook countryartis...@gmail.com wrote:
So, comes the hard part of my asignment. I'm now tasked with taking the
wonderful viewer that I've written using OSG and making it play nice with
CAVElib. Well, CAVElib does not like to play nice. It must own the OpenGL
context and controll everything except the drawing of the objects. Well, the
only way I could see to do this was use a GraphicsWindowEmbeded. Now, if I
just run CAVElib in the background, so to speak, I can see the example .iv
file perfectly. However, there is a constant barage of warnings that an
OpenGL error has been detected starting with Warning: detected OpenGL error
'invalid operation' at Before Renderer::compile, once for each pipe, and then
a constant stream of Warning: detected OpenGL error 'invalid operation' at
after RenderBin::draw(..). If I let CAVElib determine my view frustrum and
look at matrix I get a screen of garbage because both frustrum and view
matrixes are identity matrixes which I attribute to the OpenGL issues.
the simple code I'm running to show a .iv file is as follows
Code:
osg::Node* node = NULL;
osg::PositionAttitudeTransform* pat = NULL;
std::vectorosgViewer::Viewer* viewVec;
OpenThreads::Mutex m;
osg::GraphicsContext* gc = NULL;
void init()
{
osgViewer::Viewer* viewer = NULL;
{
OpenThreads::ScopedLockOpenThreads::Mutex lock(m);
viewer = new osgViewer::Viewer();
viewer-setReleaseContextAtEndOfFrameHint(false);
osg::ref_ptrosgViewer::GraphicsWindowEmbedded gw =
viewer-setUpViewerAsEmbeddedInWindow(100, 100, 500, 500);
viewer-getCamera()-setGraphicsContext(gw);
viewer-setSceneData(pat);
viewer-setThreadingModel(osgViewer::Viewer::SingleThreaded);
viewer-setCameraManipulator(new osgGA::TrackballManipulator);
viewer-setThreadSafeRefUnref(true);
viewer-realize();
viewVec.push_back(viewer);
}
CAVEDisplayBarrier();
}
void display()
{
//GLenum errorNo;
//glPushAttrib(GL_ALL_ATTRIB_BITS);
//glPushClientAttrib(GL_CLIENT_ALL_ATTRIB_BITS);
//glShadeModel(GL_SMOOTH);
//glMatrixMode(GL_TEXTURE);
//glPushMatrix();
//glLoadIdentity();
//glMatrixMode(GL_PROJECTION);
//glPushMatrix();
//glLoadIdentity();
//glMatrixMode(GL_MODELVIEW);
//glPushMatrix();
//glLoadIdentity();
int num = CAVEPipeNumber();
osgViewer::Viewer* viewer = viewVec[num];
viewer-frame();
//glMatrixMode(GL_TEXTURE);
//glPopMatrix();
//glMatrixMode(GL_PROJECTION);
//glPopMatrix();
//glMatrixMode(GL_MODELVIEW);
//glPopMatrix();
//glPopAttrib();
//glPopClientAttrib();
//errorNo = glGetError();
CAVEDisplayBarrier();
}
void frame()
{
if(CAVEMasterDisplay())
{
pat-setAttitude(pat-getAttitude() * osg::Quat(3.14 / 180.0,
osg::Y_AXIS));
}
pat-setPosition(osg::Vec3(-100, -100, -100));
int num = CAVEPipeNumber();
osgViewer::Viewer* viewer = viewVec[num];
osg::Camera* cam = viewer-getCamera();
int height = 0;
int width = 0;
int x = 0;
int y = 0;
CAVEGetViewport(x, y, width, height);
cam-setViewport(x, y, width, height);
float viewMatrixGL[16] = {0};
float projMatrixGL[16] = {0};
CAVENavTransform();
glGetFloatv( GL_MODELVIEW_MATRIX , (float*)viewMatrixGL );
glGetFloatv( GL_PROJECTION_MATRIX, (float*)projMatrixGL );
osg::Matrix viewMatrix(viewMatrixGL);
osg::Matrix projMatrix(projMatrixGL);
// set theproj
cam-setProjectionMatrix(projMatrix);
// set the view
cam-setViewMatrix(viewMatrix);
CAVEDisplayBarrier();
}
int main(int argv, char** argc)
{
node = osgDB::readNodeFile(test.iv);
pat = new osg::PositionAttitudeTransform();
pat-addChild(node);
CAVEConfigure(NULL, NULL, NULL);
CAVEInitApplication(init, 0);
CAVEDisplay(display, 0);
CAVEFrameFunction(frame, 0);
CAVEInit();
while(1)
{
OpenThreads::Thread::microSleep(1000);
}
}
I can't find a solution to my problem and I've scoured the forums, net,
contacted Mechdyne who owns CAVElib, prayed, and even contemplated
sacrificing a virgin but the alter is in for cleaning. So, any help, insite,
or the like would be greatly appreciated.
soulsabr[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43802#43802
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Re: [osg-users] UFOManipulator not repsponding to key events
Hi Andrew, You don't need to add a camera manipulator as an event handler, as the viewer will automatically call the manipulator on each frame. I also wouldn't recommend using GLUT, the OSG has far more powerful windowing support out of the box, no need to go complicating things with an ancient windowing API that was never meant for anything more than quick OpenGL demos. Robert. On 9 November 2011 04:47, Andrew Inscore andrew.insc...@gmail.com wrote: If I attempt to use the UFOManipulator like so, it does not move the camera. osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer; osgGA::UFOManipulator *fm = new osgGA::UFOManipulator(); fm-setHomePosition(osg::Vec3d(0,100,0),osg::Vec3d(0,0,0),osg::Vec3d(0,0,1),false); viewer-setCameraManipulator(fm); viewer-addEventHandler(fm); FlightManipulator works fine. I am using GLUT windowing, so this code is slightly different than my own. Other keyboard event handlers work fine(I turn them off when I try out UFOManipulator, so events are not captured). Anyone have any experience or examples using UFOManipulator? I am using version 3.0.1. Thanks! Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43787#43787 ___ 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] Simple window on windoews
Hi, Does anyone have a code snippet for building a simple window on windows? Thank you! Cheers, Paul -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43813#43813 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Simple window on windoews
ive created a window but cant draw anything 3d. any ideas why not?
Code:
#include osg/io_utils
#include osgWidget/Util
#include osgWidget/WindowManager
#include osg/ShapeDrawable
const unsigned int MASK_2D = 0xF000;
int main(int argc, char** argv) {
osgViewer::Viewer viewer;
osgWidget::WindowManager* wm = new osgWidget::WindowManager(
viewer,
1280.0f,
1024.0f,
MASK_2D,
// osgWidget::WindowManager::WM_USE_RENDERBINS |
osgWidget::WindowManager::WM_PICK_DEBUG
);
osg::Group* root = new osg::Group;
osg::Geode* geode = new osg::Geode();
osg::StateSet* stateset = new osg::StateSet();
stateset-setMode(GL_LIGHTING, osg::StateAttribute::ON);
geode-setStateSet( stateset );
geode-addDrawable(new osg::ShapeDrawable(new osg::Box
(osg::Vec3(-6,-5,-30), 1.0)));
root-addChild( geode );
viewer.setSceneData( root );
return osgWidget::createExample(viewer, wm);
}
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43814#43814
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Simple window on windoews
Hi Paul, The osgWidget NodeKit is just for placing gui elements into the scene graph so that they can be part of the 3D graphics window, it's not for creating the windows. osgViewer is the library that creates graphics windows and manages the viewer. For examples of how to create windows see osgwindows and osgcamera examples that illustrate how to set up the windows in a fine grained way. There are also convenience functions in osgViewer::View for setting up graphics windows and cameras that allow you to create a window in a single line of code, osgViewer::Viewer subclasses from View so you get all this functionality in the standard viewer. osgViewer::Viewer viewer; viewer.setUpViewInWindow(100,100,600,500); // create window viewer.setSceneData(osgDB::readNodeFile(cow.osg)); viewer.run(); ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Stereo and Render to Texture effects
Dear all, A while back I had to write a dual depth peeling routine to deal with some particularly troublesome transparency issues. The effect worked well. However, in order to render this in stereo I had to create separate frame buffer objects for each eye and then use node masks control which were used for the left and right eyes. The problem, which is particularly evident with dual depth peeling, is that this uses an awful lot of video memory to store all the render targets. Is there a way of reusing the FBOs so that I don't need to duplicate them all for each eye? I couldn't seem to find a way of doing that without the previous data being overwritten. Regards, Kim. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQt-Example
Hi,
#pragma once
#include QtOSG.h
#include osg/ShapeDrawable
osg::Camera* createCamera(int x, int y, int w, int h, QTOSG* myQTOSG, const
std::string name=, bool windowDecoration=false)
{
osg::DisplaySettings* ds = osg::DisplaySettings::instance().get();
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits;
traits-windowName = name;
traits-windowDecoration = windowDecoration;
traits-x = x;
traits-y = y;
traits-width = w;
traits-height = h;
traits-doubleBuffer = true;
traits-alpha = ds-getMinimumNumAlphaBits();
traits-stencil = ds-getMinimumNumStencilBits();
traits-sampleBuffers = ds-getMultiSamples();
traits-samples = ds-getNumMultiSamples();
traits-inheritedWindowData = new
osgQt::GraphicsWindowQt::WindowData(NULL, myQTOSG);
//neuer ref_ptr auf osg::Camera namens camera
osg::ref_ptrosg::Camera camera = new osg::Camera;
//neuer Pointer auf GraphicsWindowQt mit (traits) namens Window
osgQt::GraphicsWindowQt* Window = new
osgQt::GraphicsWindowQt(traits);
//Setzt den GraphicsContext der camera auf Window
camera-setGraphicsContext( Window );
camera-setClearColor( osg::Vec4(0.2, 0.2, 0.6, 1.0) );
camera-setViewport( new osg::Viewport(0, 0, traits-width,
traits-height) );
camera-setProjectionMatrixAsPerspective(
30.0f,
static_castdouble(traits-width)/static_castdouble(traits-height), 1.0f,
1.0f );
return camera.release();
}
QWidget* addViewWidget(osg::Camera* camera, osg::Node* scene)
{
/*QTOSG* _QTOSG = new QTOSG();*/
osgViewer::View* view = new osgViewer::View;
view-setCamera(camera);
osgViewer::CompositeViewer * cv = new osgViewer::CompositeViewer;
cv-addView( view );
view-setSceneData(scene);
view-addEventHandler(new osgViewer::StatsHandler);
view-setCameraManipulator( new osgGA::TrackballManipulator);
//Wenn camera auf ein GraphicsWindowQt zeigt, erhält man den gw-Zeiger,
der ein osgQt-zeiger ist, der auf osg::Camera zeigt. Schlägt der Cast fehl,
gibts einen Nullzeiger zurück.
osgQt::GraphicsWindowQt* gw =
dynamic_castosgQt::GraphicsWindowQt*(camera-getGraphicsContext());
//wenn gw nicht NULL ist, return getGLWidget(), sonst return NULL
return gw ? gw-getGLWidget() : NULL;
}
QTOSG::QTOSG() : QWidget()
{
root = new osg::Group();
QWidget* widget1 = addViewWidget(createCamera(0,0,100,100, this),
createPILLE());
QGridLayout* grid = new QGridLayout;
grid-addWidget(widget1, 0, 0 );
setLayout( grid );
connect( _timer, SIGNAL(timeout()), this, SLOT(update()) );
_timer.start( 10 );
}
QTOSG::~QTOSG()
{
}
void QTOSG::paintEvent(QPaintEvent* event)
{
frame();
}
osg::Node* QTOSG::createPILLE()
{
/*osg::Node* on = new osg::Node();*/
//Create a new geode node, derived from the osg::Node class, holds
osg::Drawable
osg::ref_ptrosg::Geode myshapegeode (new osg::Geode);
//Create the Capsule
osg::ref_ptrosg::Capsule myCapsule (new
osg::Capsule(osg::Vec3f(),0.1,2));
osg::ref_ptrosg::ShapeDrawable capsuledrawable (new
osg::ShapeDrawable(myCapsule.get()));
myshapegeode-addDrawable(capsuledrawable.get());
//Capsule being added to the Scenegraph using the osg::Geode
root-addChild(myshapegeode.get());
return root;
}
This is my current code; displays a grey window (not white anymore!!)
wheee help?
Thank you!
Cheers,
Patrick
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43817#43817
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Image pixel format conversion
Hi Robert- Yeah no worries, I just ended up mucking with the bits directly, I was just wanting to use built-in functions if they were available. For anyone searching with a similar issue (this was in Windows btw), I ended up just setting all of the alpha elements to 0xFF within my GL_BGRA image. I was going to take it to GL_BGR, but the CF_DIB clipboard format wants a 4-byte aligned width, so instead of padding or cropping the original captured image, I just kept it in a 4-byte per-element format. If you were to keep it in BGR and you don't have it properly aligned the image will be sheared and look very wrong. Thanks-- Baker robertosfield wrote: Hi Baker, On 7 November 2011 19:32, Bradley Baker Searles How would you use gluScaleImage to convert formats? It only takes one format parameter, and internally it uses that one format to compute the size of the before and after image? It seems suited only to scale the image, not change formats... Am I missing something? You are right I there is only one format parameter, I was thinking about the GLenum typeIn, typeOut parameters which are for the data type, so won't be suitable for your purpose. The include/osg/ImageUtils header contains a number help functions for processing image data so you could probably use this. However, if you know that you have GL_RGBA and GL_UNSIGNED_BYTE then it would be easier to write a quick converter function that flips the 0 and 2 bytes to give you GL_BGRA. Robert. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43818#43818 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ViewDependentShadowMap - Everything shadowed in subsequent panes.
Hi Robert- I built and tested the shiny new ViewDependentShadowMap code yesterday from trunk (r12877), in the hope that it would alleviate some issues we are seeing in a large scene with the LispSM technique (which works great most of the time, but from some camera angles the light source camera's mapping into the shadow texture goes haywire). The new method works much better in our use case, as far as having a stable usage of the shadow texture is concerned. One issue I'm seeing is that we can hop back and forth between a single window, and a multi-screen setup, and the first time I hop into multi-screen it's fine, but subsequent attempts will have the second window showing everything within the shadow volume as being in shadow. This issue does not happen with LispSM. We're using wxWidgets for our window management, along with wxGLCanvas. A slave camera does the render to the additional windows (just 1 extra in this case). We use custom shaders, and I have VDSM using texture channel 7 for the shadow map. I'd imagine there is an example that can bring up multiple windows (to see if it's a general issue, or ours), but one doesn't come to mind immediately. I did 2 windows with osgViewer, but it doesn't appear you can take one down and then bring it back up again, like we're doing in our app. I apologize that I don't have concise repro steps here. I may be able to spend more time on this later, and I'll update this thread if I have more information. Thanks- Baker [/list] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43819#43819 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stereo and Render to Texture effects
Hi Kim, On Thu, Nov 10, 2011 at 6:21 AM, Kim Bale kcb...@googlemail.com wrote: Is there a way of reusing the FBOs so that I don't need to duplicate them all for each eye? I couldn't seem to find a way of doing that without the previous data being overwritten. Which stereo mode are you using? I run into this problem a lot as well. I believe the reason the previous data gets overwritten is that osgUtil::SceneView explicitly calls RenderStage::drawPreRenderStages() on both eyes, before drawing the main render stage. You might be able to fix this by commenting out these calls and letting RenderStage::draw() take care of the prerender stages, depending on which stereo mode you are using. I believe these explicit calls are necessary for the anaglyphic and interlace stereo modes, because you wouldn't want the color/stencil mask affecting the prerender stages. However, for the split and quad buffer stereo modes, I don't believe these calls are necessary and it should be safe to comment those lines out. With a slight modification to SceneView::draw() it should be possible to get this working with anaglyphics/interlace modes as well. This is something that's been on my todo list for a while. Now might be a good time to try and tackle the issue :) Cheers, Farshid Regards, Kim. ___ 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] Stereo and Render to Texture effects
Hi Farshid, Thanks for your reply. Fortunately I'm working with quad buffered stereo so I'll have a dig around in the SceneView code and see if your idea works. Cheers, K. On 10 November 2011 16:14, Farshid Lashkari fla...@gmail.com wrote: Hi Kim, On Thu, Nov 10, 2011 at 6:21 AM, Kim Bale kcb...@googlemail.com wrote: Is there a way of reusing the FBOs so that I don't need to duplicate them all for each eye? I couldn't seem to find a way of doing that without the previous data being overwritten. Which stereo mode are you using? I run into this problem a lot as well. I believe the reason the previous data gets overwritten is that osgUtil::SceneView explicitly calls RenderStage::drawPreRenderStages() on both eyes, before drawing the main render stage. You might be able to fix this by commenting out these calls and letting RenderStage::draw() take care of the prerender stages, depending on which stereo mode you are using. I believe these explicit calls are necessary for the anaglyphic and interlace stereo modes, because you wouldn't want the color/stencil mask affecting the prerender stages. However, for the split and quad buffer stereo modes, I don't believe these calls are necessary and it should be safe to comment those lines out. With a slight modification to SceneView::draw() it should be possible to get this working with anaglyphics/interlace modes as well. This is something that's been on my todo list for a while. Now might be a good time to try and tackle the issue :) Cheers, Farshid Regards, Kim. ___ 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
[osg-users] osgEarth binary builds now available.
I just wanted to mention that we've now added osgEarth binary builds to the automated build system and now have them available in 32 and 64-bit flavors for Linux, Mac and Windows (VC++ 2008 and 2010). It was quite labor intensive to produce and maintain these, given the number of complex dependencies. Since we don't really ever get any donations to help run the build and distribution system, for the time being the osgEarth binaries (and future osg-ecosystem packages like osgWorks, osgAudio, osgOcean, etc) will be available for download by paid monthly subscription. If anyone is interested in this, drop me a note. -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Gstreamer within OSG
Hello all, I am planning to write some code to allow blitting of gstreamer buffers into osg textures. Eg for playing a video file or a network stream on to OSG primitives. I did a preliminary search and did not see anyone having gone down this path before. I thought I would post a message in case anyone has been down this path and knows any pertinent information. Thanks ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Gstreamer within OSG
On Thu, Nov 10, 2011 at 04:17:55PM -0700, Brad Huber wrote: I am planning to write some code to allow blitting of gstreamer buffers into osg textures. Eg for playing a video file or a network stream on to OSG primitives. I did a preliminary search and did not see anyone having gone down this path before. OpenSceneGraph has basic support for using ffmpeg to render video into textures and hand the audio out to the application. I've fixed some issues with the ffmpeg plugin myself, but others remain. If you haven't already looked at osg::AudioStream and osg::ImageStream you'll want to see what you can do to match the API to allow programs to have the same interface for the different back end renders. I see the current ImageStream and AudioStream API as just for basic playback and as such it isn't all that feature rich, and I don't think it needs to be. I would have looked at it myself, but I haven't had time for it, but I think the most important addition is audio/video synchronization. The video has a reference time, but not the audio. It also needs to give an indication how much audio is left to read from the buffer. The buffer length might be redundant if you know what video frame the audio was supposed to play with. I actually got myself into a bind playing a live multicast rtsp stream with audio and video where I apparently wasn't reading audio fast enough causing the video to freeze, because the ffmpeg audio buffers must have filled up and it would stop decoding video. I could do without the audio in that case so I changed the code to just discard audio fast enough to prevent that problem. The other issue is the only way to get an audio stream is from the ImageStream, and to use the ImageStream with ffmpeg you have to have video. That means we couldn't playback a stream that only had audio, so we had to put some image frames in just to get the audio back out. -- David Fries da...@fries.netPGP pub CB1EE8F0 http://fries.net/~david/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] wrong calculation of bounding box
Wrong calculation a bounding box of model which contains biped or bones. I'm used this code to calculate bounding box: Code: model = (osg::Geode*) osgDB::readNodeFile(testmodel.fbx); //calculating bounding box of model osg::ComputeBoundsVisitor cbbv; model-accept(cbbv); osg::BoundingBox bb = cbbv.getBoundingBox(); osg::Vec3f sz = bb._max - bb._min; It returns double size of model which contains biped or bones. If model without biped or bones the size as expected. Does anyone have idea why so? Thanks Cheers, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43825#43825 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
