Re: [osg-users] cullcallback and visitor ?
Hi,
If if do a nodevisitior, I've the problem that the operator() takes a
nodevisitor in parameter and so I can't obtain the cull state with that.
(method isCulled() not aviable from a node visitor)
Next, if I do a osg::drawable::Cullvisitor, I see how so implement the
cull() method, but It is a const method, so I can't add my own code in it to
memorize the cull state before looking at it.
How to implement the cull() method allowing my code to get the cull state
when I need it ?
I'm a bit lost...
Thanks.
Regards,
Vincent.
2008/9/26 Ulrich Hertlein [EMAIL PROTECTED]
Vincent Bourdier wrote:
_mainChild-getDrawable(0)-setCullCallback(new tileVisibleCallback());
***
tileVisibleCallback::tileVisibleCallback(){
_cull = false;
};
void tileVisibleCallback::operator()(osg::Node* node,
osgUtil::CullVisitor*
nv){
_cull = nv-isCulled(*node);
osg::notify(osg::NOTICE)Cull _cull\n;
};
bool tileVisibleCallback::isCulled(){
return _cull;
};
You're mixing up osg::Drawable::CullCallback and osg::NodeCallback and
consequently
osg::Node::setCullCallback and osg::Drawable::setCullCallback.
osg::Drawable::CullCallback has a virtual cull() function that tells if the
Drawable
*should* be culled by returning true or false.
osg::NodeCallback has a virtual operator() that does what you want.
You need to derive your callback from osg::NodeCallback, implement
operator() (as you
already do), and call:
_mainChild-setCullCallback(...)
instead of
_mainChild-getDrawable(0)-setCullCallback(...)
Hope this helps,
/ulrich
2008/9/25 Vincent Bourdier [EMAIL PROTECTED]
class tileVisibleCallback : public osg::Drawable::CullCallback{
public:
tileVisibleCallback();
virtual void operator()(osg::Node* node, osgUtil::CullVisitor* nv);
bool isCulled();
private:
bool _cull;
};
Does it sound good for you ?
(the mix between Cullcallback and osgUtil looks strange for me...
but...)
___
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] cullcallback and visitor ?
Hi Vincent,
Vincent Bourdier wrote:
If if do a nodevisitior, I've the problem that the operator() takes a
nodevisitor in parameter and so I can't obtain the cull state with that.
(method isCulled() not aviable from a node visitor)
The way I understood Robert, the fact that your operator() is called means the
node in
question is *not* culled so you could simple set your _isCulled=true. And
don't forget to
call traverse().
Next, if I do a osg::drawable::Cullvisitor, I see how so implement the
cull() method, but It is a const method, so I can't add my own code in it to
memorize the cull state before looking at it.
The Drawable::CullCallback serves a different purpose.
It can be used to actively cull Drawables.
Cheers,
/ulrich
Vincent Bourdier wrote:
_mainChild-getDrawable(0)-setCullCallback(new tileVisibleCallback());
***
tileVisibleCallback::tileVisibleCallback(){
_cull = false;
};
void tileVisibleCallback::operator()(osg::Node* node,
osgUtil::CullVisitor*
nv){
_cull = nv-isCulled(*node);
osg::notify(osg::NOTICE)Cull _cull\n;
};
bool tileVisibleCallback::isCulled(){
return _cull;
};
You're mixing up osg::Drawable::CullCallback and osg::NodeCallback and
consequently
osg::Node::setCullCallback and osg::Drawable::setCullCallback.
osg::Drawable::CullCallback has a virtual cull() function that tells if the
Drawable
*should* be culled by returning true or false.
osg::NodeCallback has a virtual operator() that does what you want.
You need to derive your callback from osg::NodeCallback, implement
operator() (as you
already do), and call:
_mainChild-setCullCallback(...)
instead of
_mainChild-getDrawable(0)-setCullCallback(...)
Hope this helps,
/ulrich
2008/9/25 Vincent Bourdier [EMAIL PROTECTED]
class tileVisibleCallback : public osg::Drawable::CullCallback{
public:
tileVisibleCallback();
virtual void operator()(osg::Node* node, osgUtil::CullVisitor* nv);
bool isCulled();
private:
bool _cull;
};
Does it sound good for you ?
(the mix between Cullcallback and osgUtil looks strange for me...
but...)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cullcallback and visitor ?
2008/9/26 Ulrich Hertlein [EMAIL PROTECTED]
Hi Vincent,
Vincent Bourdier wrote:
If if do a nodevisitior, I've the problem that the operator() takes a
nodevisitor in parameter and so I can't obtain the cull state with that.
(method isCulled() not aviable from a node visitor)
The way I understood Robert, the fact that your operator() is called means
the node in
question is *not* culled so you could simple set your _isCulled=true. And
don't forget to
call traverse().
Ok, this is a simple and good way to have the result, but not sufficient :
cull = true when operator() is called, but if the operator is not called,
cull still = true and will never be false...
Any idea to obtain the culled state when I want ?
(hoping it's the last question...)
Thanks a lot.
Regards,
Vincent.
Next, if I do a osg::drawable::Cullvisitor, I see how so implement the
cull() method, but It is a const method, so I can't add my own code in it
to
memorize the cull state before looking at it.
The Drawable::CullCallback serves a different purpose.
It can be used to actively cull Drawables.
Cheers,
/ulrich
Vincent Bourdier wrote:
_mainChild-getDrawable(0)-setCullCallback(new tileVisibleCallback());
***
tileVisibleCallback::tileVisibleCallback(){
_cull = false;
};
void tileVisibleCallback::operator()(osg::Node* node,
osgUtil::CullVisitor*
nv){
_cull = nv-isCulled(*node);
osg::notify(osg::NOTICE)Cull _cull\n;
};
bool tileVisibleCallback::isCulled(){
return _cull;
};
You're mixing up osg::Drawable::CullCallback and osg::NodeCallback and
consequently
osg::Node::setCullCallback and osg::Drawable::setCullCallback.
osg::Drawable::CullCallback has a virtual cull() function that tells if
the
Drawable
*should* be culled by returning true or false.
osg::NodeCallback has a virtual operator() that does what you want.
You need to derive your callback from osg::NodeCallback, implement
operator() (as you
already do), and call:
_mainChild-setCullCallback(...)
instead of
_mainChild-getDrawable(0)-setCullCallback(...)
Hope this helps,
/ulrich
2008/9/25 Vincent Bourdier [EMAIL PROTECTED]
class tileVisibleCallback : public osg::Drawable::CullCallback{
public:
tileVisibleCallback();
virtual void operator()(osg::Node* node, osgUtil::CullVisitor*
nv);
bool isCulled();
private:
bool _cull;
};
Does it sound good for you ?
(the mix between Cullcallback and osgUtil looks strange for me...
but...)
___
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] PagedLOD Terrain TexCoords Changing Problem while CubeMapping shader
Hi All, I have created a GLSL shader to create Caustics effect on PagedLOD terrain which was created by VPB with using CubeMap texturing on terrain. But there is a problem as you see from* VIDEO*http://www.fileden.com/files/2007/9/10/1423182/CausticsOnLODTerrain.wmv. Problem is changing texcoord in every LOD. So my main effect textured place changing. At that point I want to play texcoord to not change only for cubemap texture operation on shader. How can I fix this bug ? Best Regards. Umit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Textures not displaying properly when you open the OSG window the second t ime arround in a Win32 application
Hi, We are implementing a Windows application that opens an OSG viewer on a Windows window (lets call it 3d window) and displays some 3d graphics. The way we are implementing the application is similar to the MFC example (although I am not using MFC, but Win32 API instead), the only difference is that I use a CompositeViewer instead of a Viewer. Everything works fine when you open the 3d window for the first time, but if you close the 3d window and open it again (note that you don't close the main application, only the 3d window), the textures do not display properly anymore. Sometimes some textures are dark, sometimes some are white, sometimes they do not show at all, and sometimes some textures are swapped between objects. If you close and open again and again, you get a combination of those problems. If you exit the main application, start it again and open the 3d window, everything is displayed perfectly. I don't really know were the problem might be, so if somebody can guide me in the right direction as to where the problem might be, I will appreciate it . Thanks very much Juan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg-users Digest, Vol 15, Issue 70
Hi Paul. GenWrapper - no. I've just done a rebuild on OSG 2.6.0 to check, and didn't get a genwrapper error message. In 2.6.1, if I right click on the 'wrappers' target and select 'build', then genwrapper is found and runs normally -- no error. ... Did you build it from a genwrapper svn tree? Where did you put the executable after you built it? .. there's no way you could do an equivalent operation on 2.6 -- the 'wrappers' target didn't exist. The only difference at my side was that I downloaded 2.6.0 as a zip file from the OSG downloads page, but I got 2.6.1 from the svn url you specified. With both versions, I used the same batch of 3rd party libs, and I used VS's batch build to build everything. In general, you shouldn't need to build the 'wrappers' target, they should already be built and checked in. However, I see they are out of date on 2.6.1 That explains it, thanks Paul. I guess I wouldn't normally need genwrappers to compile OSG from source. Gary. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgscreencapture to videobuffer async
Hi Ralf, From my experience with writing osgscreencapture PBO readback is very very sensitive to frame buffer format and the image format you read back - only RGBA frame buffer really worked from my under Linux, but this is type of issue that is very sensitive to the drivers. Further to this restriction PBO read back also only provides good performance if you double buffer, I found a single buffer PBO worse than just a plain glReadPixels. So tweak your frame buffer and your image formats to see if you get get good performance, you can use the osgscreencapture example to iterate. Robert. On Thu, Sep 25, 2008 at 8:23 PM, Ralf Stokholm [EMAIL PROTECTED] wrote: Hi Robert / Jean Thanks for the responce I realise that glReadPixel has to be called by the drawthread, but as I understand it the advantage in using pixel buffer objects should be that glReadPixel would be async and therefore return in wery short time. The actual download and cost is then put on the glMapBuffer call. If this (glMapBuffer) was possible to do this in another thread then it would safe me 5-6 ms in my primary thread. If this is not possible then the value of the async glReadPixel seams to fall. Especially since it in many cases seams to be a bit slower than a simple glReadPixel; Brgs. Ralf 2008/9/25 Robert Osfield [EMAIL PROTECTED] Hi Ralf, You can only do the glReadPixel call from the graphics thread so you can't thread this, all you can do is hide the cost of download from the GPU by using a double buffered PBO, as the osgscreencapture example illustrates. To thread the writing of data you'll need to have a ring buffer of imagers that the draw thread writes to, and a background writing thread reads from. Robert. On Thu, Sep 25, 2008 at 2:57 PM, Ralf Stokholm [EMAIL PROTECTED] wrote: Hi All In our application we have added the option of capturing video from our playback stream. It works fine but performance is problematic. We are currently using a simple glReadPixels call to get the immage from the videocard, this takes around 5-6 ms in addition we append the immage to an AVI video stream this takes another 12 ms. It should be possible to put the 12 in another thread, but I was vondering if it would be possible to do the same with part of the glReadPixels call using PBO's. This is what I have in mind: From the Draw thread on initialrendercallback I would: glBindBuffer(GL_PIXEL_PACK_BUFFER_ARB, read_pbo) glReadPixels() //ASYNC SignalVideoThread() //Async and the in the video recorder thread when signaled glBindBuffer(GL_PIXEL_PACK_BUFFER_ARB, copy_pbo); GLubyte* src = (GLubyte*)ext-glMapBuffer(GL_PIXEL_PACK_BUFFER_ARB,GL_READ_ONLY_ARB); AVIStream.addframe(src) glUnmapBuffer(GL_PIXEL_PACK_BUFFER_ARB); glBindBuffer(GL_PIXEL_PACK_BUFFER_ARB, 0); Can someone tell me if this is feasable?, I was thinking that it would be problematic to do the gl calls from another thread? or should I use a compleately different approach? This is run on windowsXP, Core2 quad, Nvidia GX280 Brgs. Ralf Stokholm Arenalogic www.arenalogic.com ___ 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Svn server problems?
On Thu, Sep 25, 2008 at 9:00 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Paul, Is anyone else getting can't connect to openscenegraph.org messages when trying to do an svn update? Yep, even the web site and wiki (makes sense if they're on the same server). Both are accessible right now so I can only presume the server was taken down briefly. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2d texture messed up in big scene using OSG 2.6
Hi Leeten, My guess is that this isn't an OSG bug, and may not be a bug in the OpenGL drivers or hardware. If you find that the state of objects in your scene changes as you move around the scene then it normally suggests that the scene graph isn't set up with all the texture coords/normals etc that are required. Try a range of models from different source to find out if the problem is just isolated to a certain set of files from a specific import route. The second most likely cause would be a driver bug. What hardware and drivers are you using? Robert. On Fri, Sep 26, 2008 at 4:17 AM, Leeten [EMAIL PROTECTED] wrote: Hi, All I meet a weird problem when using OSG 2.6. Some texture messed up when the scene contains lots of node( osg::Geode ). If the main camera is near the node, its texture shows OK, but when the camera comes far, the node's texture turn to be others' texture which is wrong. I wonder if there is a num limit of texture 2d in OpenGL , OSG or Graphics Card? Or it occured by incrrect memeroy allocation? I'm using OSG 2.6 in VC 2003, Windows XP SP3. Any kind of help or hint would be appreciated. 2008-09-26 Leeten ___ 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] Textures not displaying properly when you open the OSG window the second t ime arround in a Win32 application
Hi Juan, This problem has arisen before and is related to the scene graph reusing the contextID from the previous context in the new context with the scene graph being flushed of OpenGL objects related to the original graphics context so the OSG then tries to use these OpenGL objects in the new context, but of course these objects have really been deleted so things don't work. The solution is to flush the GL objects for the context scene graph on closing of the first context, and the OSG will now do this, so should just work automatically, but if you detach parts of the scene graph before closing the context you'll need to flush these parts manually as the context itself won't know about them unless that are nested below a Camera that the context has. This leads to next question, which OSG version are you using? If it isn't 2.6 then upgrade to 2.6 as there is good chance you problem will disappear as it does a better job at cleaning up on context closure. Robert. On Fri, Sep 26, 2008 at 9:13 AM, Juan Sebastian Casanueva [EMAIL PROTECTED] wrote: Hi, We are implementing a Windows application that opens an OSG viewer on a Windows window (lets call it 3d window) and displays some 3d graphics. The way we are implementing the application is similar to the MFC example (although I am not using MFC, but Win32 API instead), the only difference is that I use a CompositeViewer instead of a Viewer. Everything works fine when you open the 3d window for the first time, but if you close the 3d window and open it again (note that you don't close the main application, only the 3d window), the textures do not display properly anymore. Sometimes some textures are dark, sometimes some are white, sometimes they do not show at all, and sometimes some textures are swapped between objects. If you close and open again and again, you get a combination of those problems. If you exit the main application, start it again and open the 3d window, everything is displayed perfectly. I don't really know were the problem might be, so if somebody can guide me in the right direction as to where the problem might be, I will appreciate it . Thanks very much Juan ___ 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] PagedLOD Terrain TexCoords Changing Problem while CubeMapping shader
HI Umit, Are you using object linear texgen for the caustics? If so switch to using eye linear texgen and use a TexGenNode to position the texgen planes. See examples like osgspotlight for an example of how to set this up. Once you've set up your TexGenNode your texture coordinates will span tiles without ever repeating (unless you decide to do so :-) Robert. On Fri, Sep 26, 2008 at 9:04 AM, Ümit Uzun [EMAIL PROTECTED] wrote: Hi All, I have created a GLSL shader to create Caustics effect on PagedLOD terrain which was created by VPB with using CubeMap texturing on terrain. But there is a problem as you see from VIDEO. Problem is changing texcoord in every LOD. So my main effect textured place changing. At that point I want to play texcoord to not change only for cubemap texture operation on shader. How can I fix this bug ? Best Regards. Umit Uzun ___ 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] cullcallback and visitor ?
Hi Vincent, Vincent Bourdier wrote: Vincent Bourdier wrote: If if do a nodevisitior, I've the problem that the operator() takes a nodevisitor in parameter and so I can't obtain the cull state with that. (method isCulled() not aviable from a node visitor) The way I understood Robert, the fact that your operator() is called means the node in question is *not* culled so you could simple set your _isCulled=true. And don't forget to call traverse(). Ok, this is a simple and good way to have the result, but not sufficient : cull = true when operator() is called, but if the operator is not called, cull still = true and will never be false... Yes it will never be reset by the cull traversal so you have to do that yourself e.g. just before cull or maybe after you've read the cull state from your class. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cullcallback and visitor ?
Hi, I found an other solution using a vector to store the visible elements and clearing this list each render loop. I is the more simple solution I think. thanks for your help. Regards, Vincent. 2008/9/26 Ulrich Hertlein [EMAIL PROTECTED] Hi Vincent, Vincent Bourdier wrote: Vincent Bourdier wrote: If if do a nodevisitior, I've the problem that the operator() takes a nodevisitor in parameter and so I can't obtain the cull state with that. (method isCulled() not aviable from a node visitor) The way I understood Robert, the fact that your operator() is called means the node in question is *not* culled so you could simple set your _isCulled=true. And don't forget to call traverse(). Ok, this is a simple and good way to have the result, but not sufficient : cull = true when operator() is called, but if the operator is not called, cull still = true and will never be false... Yes it will never be reset by the cull traversal so you have to do that yourself e.g. just before cull or maybe after you've read the cull state from your class. Cheers, /ulrich ___ 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] Problems getting a model to render using OSG in an MFC application
I tried changing my implementation to follow the osgviewermfc example very
closely with the rendering being done exactly as in the example. It didn't help
with the problem however.
I'm currently trying to take some screenshots at varying times to try to find
out if the model is being rendered and later blanked out.
I was using osgprerender as inspiration for taking screenshots, and I noticed
that if I changed the viewer.run() to while(!viewer.done()){viewer.frame()} in
the example, I would get the exact same problem as in my own application with
the model not being rendered, but the background being rendered.
regards, and thank in advance.
Jesper D. Thomsen
mailto:[EMAIL PROTECTED]
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Ümit Uzun [EMAIL
PROTECTED]
Sent: Thursday, September 25, 2008 11:00 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Problems getting a model to render using OSG in an MFC
application
Hi Jesper,
Anyone couldn't find your problem by this way, but problem looks like simple. I
advice you to look at cOSG class and Render threads activation way in
osgviewerMFC example. I think there is render thread activation problem. You
can change clear color but can't render scene. So I think problem is threading
activation.
I hope have answered your question.
Best Regards.
Umit Uzun
2008/9/25 Jesper D. Thomsen [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]
Hi all, first posting here, so be gentle.
I'm trying to integrate OSG in an existing MFC application in place of a
temporary custom OpenGL renderer.
I have looked at the osgviewermfc example and based my code on that. So far I
have got a viewer up and running with a single master camera. I have tested
that the camera is being redrawn by changing the clear-color to a random value
every frame. When I assign scenedata to the viewer there is nothing being drawn
however.
I am using the following code in my CView::Oncreate:
// Create a trackball manipulator
trackball =
new osgGA::TrackballManipulator();
// Create a Manipulator Switcher
keyswitchManipulator =
new osgGA::KeySwitchMatrixManipulator;
// Add our trackball manipulator to the switcher
keyswitchManipulator-addMatrixManipulator(
'1', Trackball, trackball);
// Init the switcher to the first manipulator (in this case the only
manipulator)
keyswitchManipulator-selectMatrixManipulator(0);
// Zero based index Value
// Init the main Root Node/Group
mRoot =
new osg::Group;
// Load the Model from the model name
mModel = osgDB::readNodeFile(
c:/cow.osg);
Optimize the model
//osgUtil::Optimizer optimizer;
//optimizer.optimize(mModel);
//optimizer.reset();
// Add the model to the scene
mRoot-addChild(mModel);
// Local Variable to hold window size data
RECT rect;
// Create the viewer for this window
mViewer =
new osgViewer::Viewer();
// Add a Stats Handler to the viewer
mViewer-addEventHandler(
new osgViewer::StatsHandler);
// Get the current window size
::GetWindowRect(m_hWnd, rect);
// Init the GraphicsContext Traits
traits =
new osg::GraphicsContext::Traits;
// Init the Windata Variable that holds the handle for the Window to display
OSG in.
windata =
new osgViewer::GraphicsWindowWin32::WindowData(m_hWnd);
// Setup the traits parameters
traits-x = 0;
traits-y = 0;
traits-width = rect.right - rect.left;
traits-height = rect.bottom - rect.top;
traits-windowDecoration =
false;
traits-doubleBuffer =
true;
traits-sharedContext = 0;
traits-setInheritedWindowPixelFormat =
true;
traits-inheritedWindowData = windata;
// Create the Graphics Context
gc = osg::GraphicsContext::createGraphicsContext(traits);
// Init a new Camera (Master for this View)
osg_camera =
new osg::Camera;
// Assign Graphics Context to the Camera
osg_camera-setGraphicsContext(gc);
// Set the viewport for the Camera
osg_camera-setViewport(
new osg::Viewport(traits-x, traits-y, traits-width, traits-height));
// Add the Camera to the Viewer
mViewer-addSlave(osg_camera);
// Add the Camera Manipulator to the Viewer
mViewer-setCameraManipulator(keyswitchManipulator);
// Set the Scene Data
mViewer-setSceneData(mRoot);
// Realize the Viewer
mViewer-realize();
-
And in my views OnDraw I use the following:
float r = (float) rand()/RAND_MAX;
float g = (float) rand()/RAND_MAX;
float b = (float) rand()/RAND_MAX;
float a = (float) rand()/RAND_MAX;
osg_camera-setClearColor( osg::Vec4(r,g,b,a) );
mViewer-frame();
As far as I can tell the osgviewermfc uses pretty much the same code.
Any and all help and hint as to what I'm doing wrong would be much appreciated.
Regards, and thanks in advance.
Jesper D. Thomsen
___
osg-users mailing list
osg-users@lists.openscenegraph.orgmailto:osg-users@lists.openscenegraph.org
[osg-users] segfault: osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply
As demanded by Robert, I repost an extended bug report that went to osg-submissions first. This segfault happened before Lionel's fix for that same function, and it still happens afterwards, using revision 8944: OS: Linux 2.6.25.2 (i86/Intel P4/32bit) gcc: (SUSE Linux) 4.3.1 20080507 libc: 2.8 (20080425) app: FlightGear (cvs/head) db: no idea; maybe some other fgfs developer could explain that :-) The crash happens every few flightgear runs, without obvious pattern. See the attached gdb log for details. More gdb or other info on request. m. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb3e24b90 (LWP 27878)] osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, stateset=0xef260a0) at /home/m/fgfs/osg/include/osgDB/DatabasePager:431 431 if ( texture-getTextureObject(*iter) == NULL ) return false; (gdb) bt #0 osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, stateset=0xef260a0) at /home/m/fgfs/osg/include/osgDB/DatabasePager:431 #1 0xb7bfaffe in osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osgDB/DatabasePager.cpp:206 #2 0xb7a9c80e in osg::Geode::accept (this=0x11460358, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/Geode:39 #3 0xb7ac75aa in osg::Group::traverse (this=0x114602c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/Group.cpp:62 #4 0xb7bfae89 in osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/NodeVisitor:181 #5 0xb7af399e in osg::NodeVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/NodeVisitor.cpp:86 #6 0xb7ac8efe in osg::Group::accept (this=0x114602c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/Group:38 #7 0xb7ac75aa in osg::Group::traverse (this=0x118b6c90, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/Group.cpp:62 #8 0xb7bfae89 in osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/NodeVisitor:181 #9 0xb7af399e in osg::NodeVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/NodeVisitor.cpp:86 #10 0xb7af3a54 in osg::NodeVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/NodeVisitor.cpp:121 #11 0xb7af3aa2 in osg::NodeVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/NodeVisitor.cpp:136 #12 0xb7ae904a in osg::MatrixTransform::accept (this=0x118b6c90, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/MatrixTransform:37 #13 0xb7ac75aa in osg::Group::traverse (this=0x1134eb78, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/Group.cpp:62 #14 0xb7bfae89 in osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/NodeVisitor:181 #15 0xb7af399e in osg::NodeVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/NodeVisitor.cpp:86 #16 0xb7ac8efe in osg::Group::accept (this=0x1134eb78, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/Group:38 #17 0xb7bf26d4 in osgDB::DatabasePager::DatabaseThread::run (this=0x904c140) at /home/m/fgfs/osg/src/osgDB/DatabasePager.cpp:675 #18 0xb79a3231 in OpenThreads::ThreadPrivateActions::StartThread (data=0x904c14c) at /home/m/fgfs/osg/src/OpenThreads/pthreads/PThread.c++:170 #19 0xb798d175 in start_thread () from /lib/libpthread.so.0 #20 0xb7524dce in clone () from /lib/libc.so.6 (gdb) print texture $1 = (osg::Texture2D *) 0x114febb8 (gdb) bt full #0 osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, stateset=0xef260a0) at /home/m/fgfs/osg/include/osgDB/DatabasePager:431 texture = (osg::Texture2D *) 0x114febb8 i = 0 #1 0xb7bfaffe in osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osgDB/DatabasePager.cpp:206 i = 6 #2 0xb7a9c80e in osg::Geode::accept (this=0x11460358, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/Geode:39 No locals. #3 0xb7ac75aa in osg::Group::traverse (this=0x114602c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/Group.cpp:62 No locals. #4 0xb7bfae89 in osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/NodeVisitor:181 No locals. #5 0xb7af399e in osg::NodeVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/NodeVisitor.cpp:86 No locals. #6 0xb7ac8efe in osg::Group::accept (this=0x114602c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/Group:38 No locals. #7 0xb7ac75aa in osg::Group::traverse (this=0x118b6c90, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/Group.cpp:62 No locals. #8 0xb7bfae89 in osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply
Re: [osg-users] segfault: osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply
Hi Melchoir, The stack trace suggests that the texture object or the iterator is corrupted or null for some reason. At this stage of the game I couldn't speculate on why this might be. Testing on my linux system with various paged databases and svn/trunk doesn't reveal any problems so unfortunately I can't recreate your specific problem yet. Have you tested flight gear before on your machine? Is this crash a new problem that has recently arisen? Do you compile the OSG and FlightGear from source? Have others in the FligthGear community seen similar problems? Robert. On Fri, Sep 26, 2008 at 12:39 PM, Melchior FRANZ [EMAIL PROTECTED] wrote: As demanded by Robert, I repost an extended bug report that went to osg-submissions first. This segfault happened before Lionel's fix for that same function, and it still happens afterwards, using revision 8944: OS: Linux 2.6.25.2 (i86/Intel P4/32bit) gcc: (SUSE Linux) 4.3.1 20080507 libc: 2.8 (20080425) app: FlightGear (cvs/head) db: no idea; maybe some other fgfs developer could explain that :-) The crash happens every few flightgear runs, without obvious pattern. See the attached gdb log for details. More gdb or other info on request. m. ___ 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] Optimizer StateVisitor not working
Hi,
I am trying to find ways to optimize my scene by removing duplicate StateSets
using the Optimizer.
Unfortunately even though I could see inside the osg files (using an editor)
duplicate StateSets nothing was shared.
As an example the osg file below although consisting of 2 identical statesets,
running the optimizer nothing is shared.
You can simply see that that by just running the osgviewer with this file using
the environment variables
OSG_NOTIFY_LEVEL = INFO
OSG_OPTIMIZER = SHARE_DUPLICATE_STATE
osgviewer runs the optimizer by default. It prints out that 2 StateSet were
found but none shared!
It also spits out the stats before/after the optimization.
Why ist that?
Thanks
Dimi
MatrixTransform {
DataVariance STATIC
name TestCube2.xsi
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 -4.37114e-08 1 0
0 -1 -4.37114e-08 0
0 0 0 1
}
num_children 1
MatrixTransform {
name MDL-cube
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Geode {
DataVariance STATIC
name MSH-cube
nodeMask 0x
cullingActive TRUE
num_drawables 2
Geometry {
DataVariance STATIC
StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_CULL_FACE ON
GL_LIGHTING ON
GL_BLEND OFF
Material {
ColorMode OFF
ambientColor FRONT 0.5 0.5 0.5 1
ambientColor BACK 0.2 0.2 0.2 1
diffuseColor FRONT 1 1 1 1
diffuseColor BACK 0.8 0.8 0.8 1
specularColor FRONT 0 0 0 1
specularColor BACK 0 0 0 1
emissionColor FRONT 0 0 0 1
emissionColor BACK 0 0 0 1
shininess FRONT 0
shininess BACK 0
}
CullFace {
mode BACK
}
textureUnit 0 {
GL_TEXTURE_2D ON
Texture2D {
name Priene-Stadio_Ground.rgb
file Priene-Stadio_Ground.rgb
wrap_s REPEAT
wrap_t REPEAT
wrap_r CLAMP
min_filter LINEAR_MIPMAP_LINEAR
mag_filter LINEAR
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth 0
useHardwareMipMapGeneration TRUE
unRefImageDataAfterApply TRUE
internalFormatMode USE_IMAGE_DATA_FORMAT
resizeNonPowerOfTwo TRUE
}
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 3
{
DrawElementsUShort TRIANGLE_STRIP 4
{
1 2 0 3
}
DrawElementsUShort TRIANGLE_STRIP 4
{
7 4 6 5
}
DrawElementsUShort TRIANGLE_STRIP 4
{
9 10 8 11
}
}
VertexArray Vec3Array 12
{
-4 -4 -4
-4 4 -4
4 4 -4
4 -4 -4
-4 -4 -4
4 -4 -4
4 -4 4
-4 -4 4
-4 -4 4
4 -4 4
4 4 4
-4 4 4
}
NormalBinding PER_VERTEX
NormalArray Vec3Array 12
{
0 -0 -1
0 -0 -1
0 -0 -1
0 -0 -1
-0 -1 0
-0 -1 0
-0 -1 0
-0 -1 0
0 0 1
0 0 1
0 0 1
0 0 1
}
TexCoordArray 0 Vec2Array 12
{
0 0
0 1
1 1
1 0
0 0
1 0
1 0
0 0
0 0
1 0
1 1
0 1
}
}
Geometry {
DataVariance STATIC
StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_CULL_FACE ON
GL_LIGHTING ON
GL_BLEND OFF
Material {
ColorMode OFF
ambientColor FRONT 0.5 0.5 0.5 1
ambientColor BACK 0.2 0.2 0.2 1
diffuseColor FRONT 1 1 1 1
diffuseColor BACK 0.8 0.8 0.8 1
specularColor FRONT 0 0 0 1
specularColor BACK 0 0 0 1
emissionColor FRONT 0 0 0 1
emissionColor BACK 0 0 0 1
shininess FRONT 0
shininess BACK 0
}
CullFace {
mode BACK
}
textureUnit 0 {
GL_TEXTURE_2D ON
Texture2D {
name Priene-Stadio_Ground.rgb
file Priene-Stadio_Ground.rgb
wrap_s REPEAT
wrap_t REPEAT
wrap_r CLAMP
min_filter LINEAR_MIPMAP_LINEAR
mag_filter LINEAR
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth
[osg-users] 2.6.1 RC1 tag created
Hi folks -- I'm pleased to announce that I've created an RC1 tag for the 2.6.1 bug fix release. As with any OSG release, community testing will improve the release quality and would be greatly appreciated. Check out a 2.6.1 tree from here: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags\OpenSceneGraph-2. 6.1-rc1 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags\OpenSceneGraph-2.6 .1-rc1 This release includes the following changes, which have been made to the trunk since the 2.6.0 release: 8765 - Fix to OverlayNode from Jason Beverage. 8775,8776 - BlendEquation support in .osg/.ive 8791 - Fix to FLT exporter to properly export PositionAttitudeTransform nodes. 8795 - Change OcclusionQueryNode to workaround an OpenGL implementation issue on NVIDIA devices with Linux drivers. The workaround is to wait (in a loop) until the query result is ready before we retrieve it. This workaround can be enabled in cmake but is disabled by default. 8799, 8800 - cmake targets for wrappers and changelog 8804 - Change AutoTransform interface to use doubles; osgTerrain wrapper modification for Layer.cpp. 8821 - cmake 'maintainer' enhancements for tags. 8853 - Fix to osgUtil::Simplifier to handle shared vertex arrays correctly. Changes the Geometry interface, so forces a recompile. - Fix for uninitialized strip texture path option in OpenFlight exporter. 8900 - Fix for FLT plugin user data handling. In addition, the wrappers have been regenerated, and the revision number has been bumped to 2.6.1. If there are other changes you'd like to see in this release, please notify me immediately. If there are no other change requests and no other significant issues found, I'll move forward with the final release. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Optimizer StateVisitor not working
HI Demi,
There are range of reasons why the visitor will deem some duplicate
state as not being appropriate for merging, so it could be one of
these mechinism rather than a bug that is preventing the merge. For
instance it won't merge objects that have don't have a DataVariance
set to STATIC, and this may well be what is prevent the merge in your
case.
Try setting you objects DataVariance to STATIC and then do the
optimizer pass again.
Robert.
On Fri, Sep 26, 2008 at 2:52 PM, dimi christop [EMAIL PROTECTED] wrote:
Hi,
I am trying to find ways to optimize my scene by removing duplicate StateSets
using the Optimizer.
Unfortunately even though I could see inside the osg files (using an editor)
duplicate StateSets nothing was shared.
As an example the osg file below although consisting of 2 identical
statesets, running the optimizer nothing is shared.
You can simply see that that by just running the osgviewer with this file
using the environment variables
OSG_NOTIFY_LEVEL = INFO
OSG_OPTIMIZER = SHARE_DUPLICATE_STATE
osgviewer runs the optimizer by default. It prints out that 2 StateSet were
found but none shared!
It also spits out the stats before/after the optimization.
Why ist that?
Thanks
Dimi
MatrixTransform {
DataVariance STATIC
name TestCube2.xsi
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 -4.37114e-08 1 0
0 -1 -4.37114e-08 0
0 0 0 1
}
num_children 1
MatrixTransform {
name MDL-cube
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Geode {
DataVariance STATIC
name MSH-cube
nodeMask 0x
cullingActive TRUE
num_drawables 2
Geometry {
DataVariance STATIC
StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_CULL_FACE ON
GL_LIGHTING ON
GL_BLEND OFF
Material {
ColorMode OFF
ambientColor FRONT 0.5 0.5 0.5 1
ambientColor BACK 0.2 0.2 0.2 1
diffuseColor FRONT 1 1 1 1
diffuseColor BACK 0.8 0.8 0.8 1
specularColor FRONT 0 0 0 1
specularColor BACK 0 0 0 1
emissionColor FRONT 0 0 0 1
emissionColor BACK 0 0 0 1
shininess FRONT 0
shininess BACK 0
}
CullFace {
mode BACK
}
textureUnit 0 {
GL_TEXTURE_2D ON
Texture2D {
name Priene-Stadio_Ground.rgb
file Priene-Stadio_Ground.rgb
wrap_s REPEAT
wrap_t REPEAT
wrap_r CLAMP
min_filter LINEAR_MIPMAP_LINEAR
mag_filter LINEAR
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth 0
useHardwareMipMapGeneration TRUE
unRefImageDataAfterApply TRUE
internalFormatMode USE_IMAGE_DATA_FORMAT
resizeNonPowerOfTwo TRUE
}
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 3
{
DrawElementsUShort TRIANGLE_STRIP 4
{
1 2 0 3
}
DrawElementsUShort TRIANGLE_STRIP 4
{
7 4 6 5
}
DrawElementsUShort TRIANGLE_STRIP 4
{
9 10 8 11
}
}
VertexArray Vec3Array 12
{
-4 -4 -4
-4 4 -4
4 4 -4
4 -4 -4
-4 -4 -4
4 -4 -4
4 -4 4
-4 -4 4
-4 -4 4
4 -4 4
4 4 4
-4 4 4
}
NormalBinding PER_VERTEX
NormalArray Vec3Array 12
{
0 -0 -1
0 -0 -1
0 -0 -1
0 -0 -1
-0 -1 0
-0 -1 0
-0 -1 0
-0 -1 0
0 0 1
0 0 1
0 0 1
0 0 1
}
TexCoordArray 0 Vec2Array 12
{
0 0
0 1
1 1
1 0
0 0
1 0
1 0
0 0
0 0
1 0
1 1
0 1
}
}
Geometry {
DataVariance STATIC
StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_CULL_FACE ON
GL_LIGHTING ON
GL_BLEND OFF
Material {
ColorMode OFF
ambientColor FRONT 0.5 0.5 0.5 1
ambientColor BACK 0.2 0.2 0.2 1
diffuseColor FRONT 1 1 1 1
diffuseColor BACK 0.8 0.8 0.8 1
specularColor FRONT 0 0 0 1
specularColor BACK 0 0 0 1
emissionColor FRONT 0 0 0 1
emissionColor BACK 0 0 0 1
Re: [osg-users] 2.6.1 RC1 tag created
Hi Paul, Thanks for pursuing the 2.6.1 release, both a weight of my shoulders and a benefit to the community :-) On Fri, Sep 26, 2008 at 3:26 PM, Paul Martz [EMAIL PROTECTED] wrote: As with any OSG release, community testing will improve the release quality and would be greatly appreciated. Check out a 2.6.1 tree from here: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags\OpenSceneGraph-2.6.1-rc1 I just tried checking out this tag under Linux to test, but got an error due to the \ in the url, changing to / fixed the problem. The checkout that worked for me was: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.6.1-rc1 Once the check out is completed and do a compile and test and let you know how it goes. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.6.1 RC1 tag created
I just tried checking out this tag under Linux to test, but got an error due to the \ in the url, changing to / fixed the problem. The checkout that worked for me was: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/Open SceneGraph-2.6.1-rc1 Ah yes, the hazards of cross-platform development... Thanks for the correction. Once the check out is completed and do a compile and test and let you know how it goes. I appreciate it. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VPB 1.0 schedule and database size improvements
What is the latest projection of a VPB 1.0 stable release, and will it be tied to OSG 2.6.0 or a more recent OSG version? For various reasons, I can only build from the *zip files, and the latest on the website is VPB 0.9.7. I realize development is going strong now, but need to know for scheduling purposes for my apps. Also, has anybody tested how much smaller (or faster) the resulting *.ive files will be with heightfield compression (is there a significant reason to wait until 1.0 comes out to build multi-TB databases)? Robert Kramer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgPPU and multiple processor
Hi, I was wondering if it's a good practice to build 2 or more ppu graph and then altern them to render differents effects. Example : I instanciate a osgPPU::Processor * processor1 and add some unit to it : processor1-addChild( osgPPU::Unit* aUnit ) processor1-addChild( osgPPU::Unit* aUnit ) processor1-addChild( osgPPU::Unit* aUnit ) ... processor1-addChild( osgPPU::UnitOut* ppuOut ) and then a second osgPPU::Processor * processor2 and add different unit to it : processor2-addChild( osgPPU::Unit* aUnit ) processor2-addChild( osgPPU::Unit* aUnit ) processor2-addChild( osgPPU::Unit* aUnit ) ... processor2-addChild( osgPPU::UnitOut* ppuOut ) Now my application need to cange the effect every 45 seconds, so when its time I remove the current processor from my main osg::Node and add the second processor to it. Is this ok to do this ? It seems to work fine for a while but then a random crash appears in the viewer_.frame() call just after I switch processor. This crash never come if I dont alternate processor1 and 2. thanks again Alex ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgstereomatch not working on Windows, NVIDIA 8800
I've compiled OSG from svn HEAD (revision 8952)on Windows XP, but osgstereomatch isn't working. I have an NVIDIA 8800 card; I tried driver version 169 and 175 with the same results. I'm using OpenSceneGraph-Data from svn HEAD (revision 8952) as well. When I run osgstereomatch --left Images/dog_left_eye.jpg --right Images/dog_right_eye.jpg --min 0 --max 31 --window 9 --single I see the two dog images with a flat red rectangle above them on the left and a flat white rectangle above on the right. Isn't this example supposed to show the pixel difference between these images? I tried without '--single' as well, and the only difference is the red rectangle is blue. The only sign of something going wrong are warnings are printed from compiling the shaders with OSG_NOTIFY_LEVEL=DEBUG_FP (see attached log). Also, there was an additional warning that said sampler2DRect couldn't be used without adding the following to the shaders: #extension GL_ARB_texture_rectangle : enable But adding that didn't resolve the problem. On a possibly related note, osgstereoimage doesn't display anything, and osgmultiplerendertargets only displays a blue rectangle (which I'm not sure is correct). Is anyone else having similar problems? Any suggestions? -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] osgstereomatch.log Description: osgstereomatch.log ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPPU and multiple processor
Hi Alexandre, I have never tried to alternate osgppu's processors dynamicly while rendering. I am not sure if it is a good idea at all (even also for other kind of osg nodes), since osg provides a mechanism called osg::SwitchNode which do the trick. Could you try to use the SwitchNode as a parent node for the processors. This will force to render only the active processor hence changing effects on the fly. I think this wouldn't make troubles, however I am not sure ;) If this doesn't help, could you then provide me with a small example code reproducing the error. This would be helpful to eliminate the issue. Cheers, art --- alexandre amyot murray [EMAIL PROTECTED] schrieb am Fr, 26.9.2008: Von: alexandre amyot murray [EMAIL PROTECTED] Betreff: [osg-users] osgPPU and multiple processor An: osg-users@lists.openscenegraph.org Datum: Freitag, 26. September 2008, 21:16 Hi, I was wondering if it's a good practice to build 2 or more ppu graph and then altern them to render differents effects. Example : I instanciate a osgPPU::Processor * processor1 and add some unit to it : processor1-addChild( osgPPU::Unit* aUnit ) processor1-addChild( osgPPU::Unit* aUnit ) processor1-addChild( osgPPU::Unit* aUnit ) ... processor1-addChild( osgPPU::UnitOut* ppuOut ) and then a second osgPPU::Processor * processor2 and add different unit to it : processor2-addChild( osgPPU::Unit* aUnit ) processor2-addChild( osgPPU::Unit* aUnit ) processor2-addChild( osgPPU::Unit* aUnit ) ... processor2-addChild( osgPPU::UnitOut* ppuOut ) Now my application need to cange the effect every 45 seconds, so when its time I remove the current processor from my main osg::Node and add the second processor to it. Is this ok to do this ? It seems to work fine for a while but then a random crash appears in the viewer_.frame() call just after I switch processor. This crash never come if I dont alternate processor1 and 2. thanks again Alex ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB 1.0 schedule and database size improvements
Robert, Do you have a web link or any documentation in the VPB trac page on what will (or at least likely) constitute the VPB 1.0 release? Thanks, Brandon Hamm SimAuthor, Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, September 26, 2008 13:28 To: OpenSceneGraph Users Subject: Re: [osg-users] VPB 1.0 schedule and database size improvements Hi Robert, VPB 1.0 will require an OSG 2.8, OSG 2.6.x won't be sufficient as I had to add code to OSG to enable some of the final VPB features. My Aim for VPB 1.0 and OSG 2.8 is presently end of October. Prior to 1.0 and 2.8 I will be make a series of coupled dev releases so if you need a release to go on before VPB-1.0 this is what you'll need to use. Robert. On Fri, Sep 26, 2008 at 8:14 PM, Kramer, Robert W [EMAIL PROTECTED] wrote: What is the latest projection of a VPB 1.0 stable release, and will it be tied to OSG 2.6.0 or a more recent OSG version? For various reasons, I can only build from the *zip files, and the latest on the website is VPB 0.9.7. I realize development is going strong now, but need to know for scheduling purposes for my apps. Also, has anybody tested how much smaller (or faster) the resulting *.ive files will be with heightfield compression (is there a significant reason to wait until 1.0 comes out to build multi-TB databases)? Robert Kramer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] segfault: osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply
* Robert Osfield -- Friday 26 September 2008: Have you tested flight gear before on your machine? yes (for years) Is this crash a new problem that has recently arisen? yes. Meanwhile I switched back to OSG revision 8779 and the problem is gone. Do you compile the OSG and FlightGear from source? yes Have others in the FligthGear community seen similar problems? I don't know of any, but it looks like most people don't update that often. OSG takes a long time to compile, and it doesn't seem to profit much from ccache. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Sharing PagedLOD node in multiple osgViewer::Viewer windows
My application utilizes a osg::PagedLOD node for terrain that is shared across multiple osgViewer::Viewer instances. The terrain paging works beautifully when I only have a single window open; however, there are issues whenever I open a second window. Some of the issues I see are: 1) Window 1 appears to revert to the lowest LOD 2) Window 1 and 2 seem to flicker as if fighting over which texture or tile should be visible 3) Sometimes window 2 textures are missing for some tiles (i.e. white background) I suspect that I might be using osgDB::DatabasePager improperly. I have tried sharing the same osgDB::DatabasePager across all osgViewer::Viewer instances, and I have also tried using a unique osgDB::DatabasePager for each osgViewer::Viewer instance. What is the correct approach? Any ideas as to what I am doing wrong? Any suggestions for me to try? I am using OSG 2.4. Thanks, Justin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
