Re: [osg-users] Different line types
Hi Andre, There is nothing I or anyone else can do to suggest how you fix your problem as there really isn't any where near enough information in your emails to help us even guess at what the problem. It's like me telling you I have a piece of string in my hand and telling you that while I don't know how long it is, could you please tell me how long it is. osg::LineStipple works just fine, so if it isn't working then you are either expecting something that OpenGL itself doesn't do, or that you are not setting things up at your end. Robert. On Wed, Aug 13, 2008 at 6:01 PM, Andre Simoes <[EMAIL PROTECTED]> wrote: > Hello Robert. I know that this topic is a little old. But I'm Still having > that problem with LineStipple > > I've been debugging Osg src with my implementation. And I've realized that > when I'm adding the Line inside my PAT object I just can't see it calling > Drawable::compileGLObjects( State &state ) ( OSG 1.x ) > > Is there any way that I could do it by hand ? > > 2008/6/26 Robert Osfield <[EMAIL PROTECTED]> >> >> Hi Andre, >> >> If your lines are coming out stippled then it suggests that either >> your own OpenGL code is setting the line stippling on, or that the OSG >> has a osg::LineStipple assigned to enable this. >> >> Robert. >> >> On Wed, Jun 25, 2008 at 3:02 PM, Andre Simoes <[EMAIL PROTECTED]> >> wrote: >> > Hi For all. >> > >> > Does anyone had such problem ? >> > >> > I'm using a system that merges calls between pure openscenegraph updates >> > and >> > opengl updates. And I also have a component (PositionAttitudeTransform) >> > with >> > a couple of child drawing objects that must be connected each other by a >> > simple line >> > >> > But when I try to add a new line as a common glBegin( GL_LINES ) under >> > openscenegraph, the drawing is rendered as LINE_STIPPLE, even if I >> > change it >> > from LINES to LINE_LOOP or other stuff... >> > >> > A don't know if StateSet could resolve the problem. Because I've already >> > tried to use it but I guess that I did not make the correct code struct >> > for >> > its calling, and the results were the same. >> > >> > Also, if I use standalone openscenegraph application based on >> > osgViewer, the following code (applied to the compound GL-OSG system) >> > works >> > with no problem: >> > >> > >> > /*/ >> > Symbol *s1 = getSymbol( str_symbol1 ); >> > Symbol *s2 = getSymbol( str_symbol2 ); >> > >> > osg::Vec3 p1 = s1->getPosition(); >> > osg::Vec3 p2 = s2->getPosition(); >> > >> > osg::Vec4 color = s1->getTextColor(); >> > >> > osg::ref_ptr< osg::Geometry > line = new osg::Geometry; >> > >> > osg::ref_ptr< osg::Vec3Array > vertex = new osg::Vec3Array; >> > vertex->push_back( p1 ); >> > vertex->push_back( p2 ); >> > line->setVertexArray( vertex.get() ); >> > >> > /// the problem should be resolved here with osg::DrawArrays::LINES >> > declaration >> > osg::ref_ptr< osg::DrawArrays > vindex = new osg::DrawArrays( >> > osg::DrawArrays::LINES, 0, 2 ); >> > line->addPrimitiveSet( vindex.get() ); >> > >> > >> > /*/ >> > >> > Thanks anyway if anyone spend a time reading the message >> > >> > I'm new to openscenegraph with just a couple of tests as experience and >> > a >> > complex system that already use osg to be studied in my hands >> > >> > Kindly >> > Andre >> > >> > ___ >> > 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] osgViewer::WindowSizeHandler
On Wed, Aug 13, 2008 at 7:03 PM, Jeremy Moles <[EMAIL PROTECTED]> wrote: >> Running a true fullscreen mode - not a maximized window - should *not* >> generate a resize event, since there is no window being resized. Rather, >> you are switching from a window-based rendering mode to a screen-based >> rendering mode. Typically, the windowing system will be acting on a >> different message (sometimes linked to a message from the renderer, i.e. >> OGL here) when switching to fullscreen mode. Windows and fullscreen >> modes require different handling methods due to the differences in their >> inherent nature. > > This seems to be a good summary of the situation. Given this > information, would it be reasonable to introduce a new event for this > action, or should I (and others needing to know when a window has gone > fullscreen) derive our own WindowSizeHandler to intercept the request > the go into a scree-based rendering mode? The place to add the code is in the GraphicsWindowX11.cpp, rather than the WindowSizeHandler, as this handler is not the only way that users can resize the windows. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer's turns up black when run from different threads.
Hi David, I really don't know what is up with your usage, there really isn't enough info about how you set up things to know where things are going astray. A window being black suggest to be that rendering itself hasn't started yet, just that the window has been realized. The osgViewer doesn't support multiple viewers sharing a single GraphicsContext (this is what you should use osgViewer::CompositeViewer for so you can have multiple views sharing a single context). Robert. On Wed, Aug 13, 2008 at 7:09 PM, David Johansson <[EMAIL PROTECTED]> wrote: > Hi Everyone, > > I have a problem with threading and osg::Viewer. > > Basically i create and recreate a bunch of threads that runs a new > Viewer instance and the problem is that the viewers 'draw area' turns > up black if i ever close a Viewer. > > Thread1 creates Window1 - viewing Node1 - OK. > Thread2 creates Window2 - viewing Node1 - Ok. > User closes Window1 > Thread1 dies. > Thread3 creates Window3 - viewing Node1 -- Will turn up black > Thread4 creates Window4 - viewing Node1 -- All Ok.. > Thread5 creates Window5 - viewing Node1 -- Also Ok > User closes window 2 > Thread2 dies. > Thread6 creates Window6 - viewing Node1 -- Will turn up black > Thread7 creates Window7 - viewing Node1 -- Ok again. > User closes all windows > Thread3 - 7 dies. > Thread8 creates Window8 - viewing Node1 -- Black. > Thread9 creates Window9 - viewing Node1 -- Black. > Thread10 creates Window10 - viewing Node1 -- Black. > Thread11 creates Window11 - viewing Node1 -- Black. > Thread12 creates Window12 - viewing Node1 -- Black. > Thread13 creates Window13 - viewing Node1 -- Ok! > > I noticed that After closing all windows, i had 5 windows running that > acctually showed something(5 new Contexts??). After that i had to > create 5 threads (that were black) until getting a new view that > wasn't black. > > Looking through the code my guess is that "graphicsContexts" are > getting reused, however not reset or something like that. > > This is the code i use to set-up my viewers: > > osgViewer::Viewer viewer; > viewer.addEventHandler(new osgViewer::StatsHandler()); > viewer.addEventHandler(new osgViewer::ThreadingHandler()); > viewer.addEventHandler(new osgViewer::WindowSizeHandler()); > viewer.setSceneData(g); > viewer.setThreadingModel(osgViewer::Viewer::ThreadPerContext); /**/ > viewer.run(); > > Any help would be great! > > Regards, > > David Johansson > ___ > 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] pick on specific subgraph / nodepath
I've checked the source code about this, and after using the nodepath to unproject the 2D coordinates and retrieve the 3d start and end points of the line-intersector, the visit is called like this: osgUtil::IntersectionVisitor iv(picker); iv.setTraversalMask(traversalMask); nodePath.back()->accept(iv); so I expected it to start visiting from the last node of the nodepath downwards into its subgraph. Is it the case? Ricky -Original Message- From: [EMAIL PROTECTED] on behalf of Gordon Tomlinson Sent: Thu 14/08/2008 2.38 To: 'OpenSceneGraph Users' Cc: Subject:Re: [osg-users] pick on specific subgraph / nodepath I think the problem might be the pHudRootNode->getParentalNodePaths()[0] What this will do is traverse only the node getParentalNodePaths()[0] and is direct SceneGraph descendants As far as I know it will not traverse paths only the first node which may or may not be a node your after Perhaps you want pHudRootNode->getParent() or just pHudRootNode __ Gordon Tomlinson [EMAIL PROTECTED] IM: [EMAIL PROTECTED] www.vis-sim.com www.gordontomlinson.com __ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Riccardo Corsi Sent: Wednesday, August 13, 2008 7:30 PM To: OpenSceneGraph Users Subject: Re: [osg-users] pick on specific subgraph / nodepath Hi Gordon, I know the nodemask is an often suggested solution, but what I don't like about it is that it forces me to touch also other nodes/subgraphs I'm not interested in, that I would ignore, while I must go and set a mask on them. Instead, when I know a priori the small subgraph I want to pick on (one representing a manipulator, for instance) I would consider more straightforward and less "polluting" to pick on a single nodepath, instead of excluding all of the others via nodemask. Does this make sense? Or there's a better use of nodemasks I'm not aware of?? Thank you, Ricky -Original Message- From: [EMAIL PROTECTED] on behalf of Tomlinson, Gordon Sent: Wed 13/08/2008 20.38 To: OpenSceneGraph Users Cc: Subject:Re: [osg-users] pick on specific subgraph / nodepath Err that should be 'use' not used (as you don't know were they may have been ;) ) SetNodeMask( 0x0 ) for those nodes you don't want to touch SetNodeMask( 0x) on the Nodes you want to touch as well as on the visitor/isector -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomlinson, Gordon Sent: Wednesday, August 13, 2008 2:24 PM To: OpenSceneGraph Users Subject: Re: [osg-users] pick on specific subgraph / nodepath Why not just used node masks ? This is the typical way to approach this problem Gordon __ Gordon Tomlinson Email : gtomlinson @ overwatch.textron.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Riccardo Corsi Sent: Wednesday, August 13, 2008 2:07 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] pick on specific subgraph / nodepath Hi All, I'm trying to do some picking only in a specific subgraph, so I was thinking to use the version of "computeIntersections" which include a nodepath option. Unfortunately it didn't work as aspected, and I don't know where I'm wrong. I modified the osgpick example (attached) to pick, for instance, only the rectangles in the HUD. What I do is: - store the root of the HUD in a pHudRootNode - pick with the funtion viewer->computeIntersections(ea.getX(), ea.getY(), pHudRootNode->getParentalNodePaths()[0], intersections) but I don't get any result. I've also tried to limit the nodepath to the view's SceneData, like this: pHudRootNode->getParentalNodePaths(viewer->getSceneData())[0] but it doesn't work either. Where am I wrong? Thank you! Ricky ___ 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 ___ 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] usb joystick in openscenegraph
You may also find that DIVERSE can fill your needs. It's a virtual reality controller that can be used with osg. See: http://diverse-vr.org/index.php?page=documentation/introduction -Eric On Tue, Aug 12, 2008 at 12:35 PM, Jan Ciger <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Mike (and Joe), > > Mike Connell wrote: > | Hi, > | > | I was in the same position this summer. Previously I'd used SDL for a > | gamepad, but now needed to resurrect that code and redo it for a > | wheel+pedals. > | > | I looked at vrpn but failed to really grok it. In the same time it > | took me to bash my head against the vrpn examples, I wrote the sdl > | code. The following should be enough for you to do a quick test. SDL > | also supports "hats", and force-feedback was part of the Google > | Summer of Code, but I haven't seen any results of that yet. > | > > SDL is good if you need only simple joysticks/wheels etc. and do not > need network transparency. > > On the other hand, if one requires network transparency because the > simulator machine(s) are separate from controller input or you need > support for HID controllers that are not joysticks - such as tablets, > the SpaceNavigator and similar, or virtual reality hardware, SDL will > not help you. VRPN was built for that. BTW, basic VRPN client is > probably even shorter than you SDL example. > > Regarding force feedback - there is no support for that in any > officially released SDL version. > > Regards, > > Jan > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFIoeX5n11XseNj94gRAlR8AKC2RXleH50RFXFUzBKnAAhUNiu/aACg0DI6 > JkOK/FuthnNucluwVmY05OI= > =Ogbu > -END PGP SIGNATURE- > > ___ > 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] Qt4, OSG and HUD
Hi all, Since Qt 4.4, we are able to mix OpenGL and Qt in a way which provides more possibility than the osgViewerQT do by using QGraphics framework, especially for HUD display. I joint the example I write to do this. The main function loads a model a display into my QGraphicsScene inheriting class. On top of it is drawn a simple semi-transparent QWidget but we can draw whatever we want as menu... I extended the example code from the Qt Quaterly to use the osg::Viewer. But I think it can interest other Qt/OSG users. I still have 2 problems I don't have the time to look forward: - The widget transparency only run with the composite viewer (run my example with the --composite argument) - The window resize produces a deformation of widgets inside but I think it more a Qt problem ;) I say this just for information. I hope this could be usefull for someone. Eric Z. main.cpp Description: main.cpp QOSGGraphics.cpp Description: QOSGGraphics.cpp QOSGGraphics.h Description: QOSGGraphics.h ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer's turns up black when run from different threads.
Hi Robert,
Here is code that produces the problem.
I'm building/running on Ubuntu 8.04 with osg 2.4
#include
#include
#include
#include
#include
#include
#include
#include
class viewerThread: public OpenThreads::Thread
{
public:
viewerThread( osg::Node* n ): OpenThreads::Thread(), _scene(n){}
virtual void run(){
osgViewer::Viewer viewer;
_pViewer = &viewer;
viewer.addEventHandler(new osgViewer::StatsHandler());
viewer.addEventHandler(new osgViewer::ThreadingHandler());
viewer.addEventHandler(new osgViewer::WindowSizeHandler());
viewer.setSceneData(_scene);
viewer.setThreadingModel(osgViewer::Viewer::ThreadPerContext);
viewer.run();
_pViewer = NULL;
}
void cancelViewer(){
if( _pViewer != NULL )
_pViewer->setDone( true );
}
private:
osg::Node* _scene;
osgViewer::Viewer* _pViewer;
};
int main(int argc, wchar_t* argv[])
{
std::vector garbage;
osg::ref_ptr n = osgDB::readNodeFile("cow.osg");
if( !n ) return -1;
bool bRun = true;
do{
std::wstring wsCommand;
std::wcout << L"Enter Command : ";
std::getline( std::wcin, wsCommand, L'\n' );
if( wsCommand == L"quit" ){
bRun = false;
}else if ( wsCommand == L"view" ){
viewerThread* vThread = new viewerThread( n.get() );
garbage.push_back( vThread );
vThread->startThread();
}
}while( bRun );
for( unsigned int i = 0; i < garbage.size(); i++ ){
viewerThread* p = garbage.at( i );
p->cancelViewer();
p->cancel();
while ( p->isRunning() )
{
OpenThreads::Thread::microSleep(50);
}
delete p;
}
garbage.clear();
return 1;
}
Regards,
David Johansson
On Thu, Aug 14, 2008 at 10:14 AM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
> Hi David,
>
> I really don't know what is up with your usage, there really isn't
> enough info about how you set up things to know where things are going
> astray.
>
> A window being black suggest to be that rendering itself hasn't
> started yet, just that the window has been realized. The osgViewer
> doesn't support multiple viewers sharing a single GraphicsContext
> (this is what you should use osgViewer::CompositeViewer for so you can
> have multiple views sharing a single context).
>
> Robert.
>
> On Wed, Aug 13, 2008 at 7:09 PM, David Johansson <[EMAIL PROTECTED]> wrote:
>> Hi Everyone,
>>
>> I have a problem with threading and osg::Viewer.
>>
>> Basically i create and recreate a bunch of threads that runs a new
>> Viewer instance and the problem is that the viewers 'draw area' turns
>> up black if i ever close a Viewer.
>>
>> Thread1 creates Window1 - viewing Node1 - OK.
>> Thread2 creates Window2 - viewing Node1 - Ok.
>> User closes Window1
>> Thread1 dies.
>> Thread3 creates Window3 - viewing Node1 -- Will turn up black
>> Thread4 creates Window4 - viewing Node1 -- All Ok..
>> Thread5 creates Window5 - viewing Node1 -- Also Ok
>> User closes window 2
>> Thread2 dies.
>> Thread6 creates Window6 - viewing Node1 -- Will turn up black
>> Thread7 creates Window7 - viewing Node1 -- Ok again.
>> User closes all windows
>> Thread3 - 7 dies.
>> Thread8 creates Window8 - viewing Node1 -- Black.
>> Thread9 creates Window9 - viewing Node1 -- Black.
>> Thread10 creates Window10 - viewing Node1 -- Black.
>> Thread11 creates Window11 - viewing Node1 -- Black.
>> Thread12 creates Window12 - viewing Node1 -- Black.
>> Thread13 creates Window13 - viewing Node1 -- Ok!
>>
>> I noticed that After closing all windows, i had 5 windows running that
>> acctually showed something(5 new Contexts??). After that i had to
>> create 5 threads (that were black) until getting a new view that
>> wasn't black.
>>
>> Looking through the code my guess is that "graphicsContexts" are
>> getting reused, however not reset or something like that.
>>
>> This is the code i use to set-up my viewers:
>>
>> osgViewer::Viewer viewer;
>> viewer.addEventHandler(new osgViewer::StatsHandler());
>> viewer.addEventHandler(new osgViewer::ThreadingHandler());
>> viewer.addEventHandler(new osgViewer::WindowSizeHandler());
>> viewer.setSceneData(g);
>> viewer.setThreadingModel(osgViewer::Viewer::ThreadPerContext); /**/
>> viewer.run();
>>
>> Any help would be great!
>>
>> Regards,
>>
>> David Johansson
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
> ___
Re: [osg-users] osgViewer's turns up black when run from different threads.
I've tried a different series of entering "view" one or more times,
followed by closing one or more of the shown windows and repeating. But
I've not seen any "black windows" yet. What is the sequence that
reproduces the problem for you?
This is on Linux, nVidia 96.43.01 driver
Paul
David Johansson wrote:
Hi Robert,
Here is code that produces the problem.
I'm building/running on Ubuntu 8.04 with osg 2.4
#include
#include
#include
#include
#include
#include
#include
#include
class viewerThread: public OpenThreads::Thread
{
public:
viewerThread( osg::Node* n ): OpenThreads::Thread(), _scene(n){}
virtual void run(){
osgViewer::Viewer viewer;
_pViewer = &viewer;
viewer.addEventHandler(new osgViewer::StatsHandler());
viewer.addEventHandler(new osgViewer::ThreadingHandler());
viewer.addEventHandler(new osgViewer::WindowSizeHandler());
viewer.setSceneData(_scene);
viewer.setThreadingModel(osgViewer::Viewer::ThreadPerContext);
viewer.run();
_pViewer = NULL;
}
void cancelViewer(){
if( _pViewer != NULL )
_pViewer->setDone( true );
}
private:
osg::Node* _scene;
osgViewer::Viewer* _pViewer;
};
int main(int argc, wchar_t* argv[])
{
std::vector garbage;
osg::ref_ptr n = osgDB::readNodeFile("cow.osg");
if( !n ) return -1;
bool bRun = true;
do{
std::wstring wsCommand;
std::wcout << L"Enter Command : ";
std::getline( std::wcin, wsCommand, L'\n' );
if( wsCommand == L"quit" ){
bRun = false;
}else if ( wsCommand == L"view" ){
viewerThread* vThread = new viewerThread( n.get() );
garbage.push_back( vThread );
vThread->startThread();
}
}while( bRun );
for( unsigned int i = 0; i < garbage.size(); i++ ){
viewerThread* p = garbage.at( i );
p->cancelViewer();
p->cancel();
while ( p->isRunning() )
{
OpenThreads::Thread::microSleep(50);
}
delete p;
}
garbage.clear();
return 1;
}
Regards,
David Johansson
On Thu, Aug 14, 2008 at 10:14 AM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
Hi David,
I really don't know what is up with your usage, there really isn't
enough info about how you set up things to know where things are going
astray.
A window being black suggest to be that rendering itself hasn't
started yet, just that the window has been realized. The osgViewer
doesn't support multiple viewers sharing a single GraphicsContext
(this is what you should use osgViewer::CompositeViewer for so you can
have multiple views sharing a single context).
Robert.
On Wed, Aug 13, 2008 at 7:09 PM, David Johansson <[EMAIL PROTECTED]> wrote:
Hi Everyone,
I have a problem with threading and osg::Viewer.
Basically i create and recreate a bunch of threads that runs a new
Viewer instance and the problem is that the viewers 'draw area' turns
up black if i ever close a Viewer.
Thread1 creates Window1 - viewing Node1 - OK.
Thread2 creates Window2 - viewing Node1 - Ok.
User closes Window1
Thread1 dies.
Thread3 creates Window3 - viewing Node1 -- Will turn up black
Thread4 creates Window4 - viewing Node1 -- All Ok..
Thread5 creates Window5 - viewing Node1 -- Also Ok
User closes window 2
Thread2 dies.
Thread6 creates Window6 - viewing Node1 -- Will turn up black
Thread7 creates Window7 - viewing Node1 -- Ok again.
User closes all windows
Thread3 - 7 dies.
Thread8 creates Window8 - viewing Node1 -- Black.
Thread9 creates Window9 - viewing Node1 -- Black.
Thread10 creates Window10 - viewing Node1 -- Black.
Thread11 creates Window11 - viewing Node1 -- Black.
Thread12 creates Window12 - viewing Node1 -- Black.
Thread13 creates Window13 - viewing Node1 -- Ok!
I noticed that After closing all windows, i had 5 windows running that
acctually showed something(5 new Contexts??). After that i had to
create 5 threads (that were black) until getting a new view that
wasn't black.
Looking through the code my guess is that "graphicsContexts" are
getting reused, however not reset or something like that.
This is the code i use to set-up my viewers:
osgViewer::Viewer viewer;
viewer.addEventHandler(new osgViewer::StatsHandler());
viewer.addEventHandler(new osgViewer::ThreadingHandler());
viewer.addEventHandler(new osgViewer::WindowSizeHandler());
viewer.setSceneData(g);
viewer.setThreadingModel(osgViewer::Viewer::ThreadPerContext); /**/
viewer.run();
Any help would be great!
Regards,
David Johansson
___
Re: [osg-users] osgViewer's turns up black when run from different threads.
Hi Paul,
type "view" 2 times to get 2 views.
close the first window, i always press 'f' to get out of fullscreen,
type "view" again.. turns up black.
Maybe this is my driver?
I'm using the default ubuntu Nvidia driver. Also, running Compiz in
the background..
Regards,
David Johansson
On Thu, Aug 14, 2008 at 3:08 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
> I've tried a different series of entering "view" one or more times, followed
> by closing one or more of the shown windows and repeating. But I've not seen
> any "black windows" yet. What is the sequence that reproduces the problem
> for you?
>
> This is on Linux, nVidia 96.43.01 driver
>
> Paul
>
> David Johansson wrote:
>>
>> Hi Robert,
>>
>> Here is code that produces the problem.
>>
>> I'm building/running on Ubuntu 8.04 with osg 2.4
>>
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> class viewerThread: public OpenThreads::Thread
>> {
>> public:
>>viewerThread( osg::Node* n ): OpenThreads::Thread(), _scene(n){}
>>virtual void run(){
>>osgViewer::Viewer viewer;
>>_pViewer = &viewer;
>>viewer.addEventHandler(new osgViewer::StatsHandler());
>>viewer.addEventHandler(new osgViewer::ThreadingHandler());
>>viewer.addEventHandler(new osgViewer::WindowSizeHandler());
>>viewer.setSceneData(_scene);
>>
>> viewer.setThreadingModel(osgViewer::Viewer::ThreadPerContext);
>>viewer.run();
>>_pViewer = NULL;
>>}
>>void cancelViewer(){
>>if( _pViewer != NULL )
>>_pViewer->setDone( true );
>>}
>> private:
>>osg::Node* _scene;
>>osgViewer::Viewer* _pViewer;
>>
>> };
>>
>> int main(int argc, wchar_t* argv[])
>> {
>>std::vector garbage;
>>osg::ref_ptr n = osgDB::readNodeFile("cow.osg");
>>if( !n ) return -1;
>>bool bRun = true;
>>do{
>>std::wstring wsCommand;
>>std::wcout << L"Enter Command : ";
>>std::getline( std::wcin, wsCommand, L'\n' );
>>
>>if( wsCommand == L"quit" ){
>>bRun = false;
>>}else if ( wsCommand == L"view" ){
>>viewerThread* vThread = new viewerThread( n.get()
>> );
>>garbage.push_back( vThread );
>>vThread->startThread();
>>}
>>}while( bRun );
>>
>>for( unsigned int i = 0; i < garbage.size(); i++ ){
>>viewerThread* p = garbage.at( i );
>>p->cancelViewer();
>>p->cancel();
>>while ( p->isRunning() )
>>{
>>OpenThreads::Thread::microSleep(50);
>>}
>>delete p;
>>}
>>garbage.clear();
>>return 1;
>> }
>>
>> Regards,
>>
>> David Johansson
>>
>>
>> On Thu, Aug 14, 2008 at 10:14 AM, Robert Osfield
>> <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> Hi David,
>>>
>>> I really don't know what is up with your usage, there really isn't
>>> enough info about how you set up things to know where things are going
>>> astray.
>>>
>>> A window being black suggest to be that rendering itself hasn't
>>> started yet, just that the window has been realized. The osgViewer
>>> doesn't support multiple viewers sharing a single GraphicsContext
>>> (this is what you should use osgViewer::CompositeViewer for so you can
>>> have multiple views sharing a single context).
>>>
>>> Robert.
>>>
>>> On Wed, Aug 13, 2008 at 7:09 PM, David Johansson <[EMAIL PROTECTED]>
>>> wrote:
>>>
Hi Everyone,
I have a problem with threading and osg::Viewer.
Basically i create and recreate a bunch of threads that runs a new
Viewer instance and the problem is that the viewers 'draw area' turns
up black if i ever close a Viewer.
Thread1 creates Window1 - viewing Node1 - OK.
Thread2 creates Window2 - viewing Node1 - Ok.
User closes Window1
Thread1 dies.
Thread3 creates Window3 - viewing Node1 -- Will turn up black
Thread4 creates Window4 - viewing Node1 -- All Ok..
Thread5 creates Window5 - viewing Node1 -- Also Ok
User closes window 2
Thread2 dies.
Thread6 creates Window6 - viewing Node1 -- Will turn up black
Thread7 creates Window7 - viewing Node1 -- Ok again.
User closes all windows
Thread3 - 7 dies.
Thread8 creates Window8 - viewing Node1 -- Black.
Thread9 creates Window9 - viewing Node1 -- Black.
Thread10 creates Window10 - viewing Node1 -- Black.
Thread11 creates Window11 - viewing Node1 -- Black.
Thread12 creates Window12 - viewing Node1 -- Black.
Thread13 creates Window13 - viewing Node1 -- Ok!
I noticed that After closing all windows, i had 5 windows running that
ac
Re: [osg-users] LineSegmentIntersector does not work with Billboards
Hi Judd,
I have done some work on osgUtil::IntersectionVisitor to add proper
support for Billboards. Could you try out the attached
IntersectionVisitor header/source files and let me know how you get
on. This builds against OSG-2.6/OSG-SVN, but might also compile
against 2.4.
In my own testing 'osgpick lz.osg' now works fine, whereas before this
fix it failed to pick the billboarded trees.
Robert.
IntersectionVisitor
Description: Binary data
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
using namespace osgUtil;
///
//
// IntersectorGroup
//
IntersectorGroup::IntersectorGroup()
{
}
void IntersectorGroup::addIntersector(Intersector* intersector)
{
_intersectors.push_back(intersector);
}
void IntersectorGroup::clear()
{
_intersectors.clear();
}
Intersector* IntersectorGroup::clone(osgUtil::IntersectionVisitor& iv)
{
IntersectorGroup* ig = new IntersectorGroup;
// now copy across all intersectors that arn't disabled.
for(Intersectors::iterator itr = _intersectors.begin();
itr != _intersectors.end();
++itr)
{
if (!(*itr)->disabled())
{
ig->addIntersector( (*itr)->clone(iv) );
}
}
return ig;
}
bool IntersectorGroup::enter(const osg::Node& node)
{
if (disabled()) return false;
bool foundIntersections = false;
for(Intersectors::iterator itr = _intersectors.begin();
itr != _intersectors.end();
++itr)
{
if ((*itr)->disabled()) (*itr)->incrementDisabledCount();
else if ((*itr)->enter(node)) foundIntersections = true;
else (*itr)->incrementDisabledCount();
}
if (!foundIntersections)
{
// need to call leave to clean up the DisabledCount's.
leave();
return false;
}
// we have found at least one suitable intersector, so return true
return true;
}
void IntersectorGroup::leave()
{
for(Intersectors::iterator itr = _intersectors.begin();
itr != _intersectors.end();
++itr)
{
if ((*itr)->disabled()) (*itr)->decrementDisabledCount();
}
}
void IntersectorGroup::intersect(osgUtil::IntersectionVisitor& iv, osg::Drawable* drawable)
{
if (disabled()) return;
unsigned int numTested = 0;
for(Intersectors::iterator itr = _intersectors.begin();
itr != _intersectors.end();
++itr)
{
if (!(*itr)->disabled())
{
(*itr)->intersect(iv, drawable);
++numTested;
}
}
// osg::notify(osg::NOTICE)<<"Number testing "containsIntersections()) return true;
}
return false;
}
///
//
// IntersectionVisitor
//
IntersectionVisitor::IntersectionVisitor(Intersector* intersector, ReadCallback* readCallback)
{
// override the default node visitor mode.
setTraversalMode(osg::NodeVisitor::TRAVERSE_ACTIVE_CHILDREN);
_useKdTreesWhenAvailable = true;
_dummyTraversal = false;
_lodSelectionMode = USE_HIGHEST_LEVEL_OF_DETAIL;
_eyePointDirty = true;
LineSegmentIntersector* ls = dynamic_cast(intersector);
if (ls)
{
setReferenceEyePoint(ls->getStart());
setReferenceEyePointCoordinateFrame(ls->getCoordinateFrame());
}
else
{
setReferenceEyePoint(osg::Vec3(0.0f,0.0f,0.0f));
setReferenceEyePointCoordinateFrame(Intersector::VIEW);
}
setIntersector(intersector);
setReadCallback(readCallback);
}
void IntersectionVisitor::setIntersector(Intersector* intersector)
{
// keep reference around just in case intersector is already in the _intersectorStack, otherwise the clear could delete it.
osg::ref_ptr temp = intersector;
_intersectorStack.clear();
if (intersector) _intersectorStack.push_back(intersector);
}
void IntersectionVisitor::reset()
{
if (!_in
Re: [osg-users] osgViewer's turns up black when run from different threads.
David Johansson wrote:
Hi Paul,
type "view" 2 times to get 2 views.
close the first window, i always press 'f' to get out of fullscreen,
type "view" again.. turns up black.
No problems here with that sequence...
Maybe this is my driver?
It could be
I'm using the default ubuntu Nvidia driver.
cat /proc/drivers/nvidia/version
to discover which version you're running.
Also, running Compiz in
the background..
Hmmm, can you easily try without compiz?
Paul
Regards,
David Johansson
On Thu, Aug 14, 2008 at 3:08 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
I've tried a different series of entering "view" one or more times, followed
by closing one or more of the shown windows and repeating. But I've not seen
any "black windows" yet. What is the sequence that reproduces the problem
for you?
This is on Linux, nVidia 96.43.01 driver
Paul
David Johansson wrote:
Hi Robert,
Here is code that produces the problem.
I'm building/running on Ubuntu 8.04 with osg 2.4
#include
#include
#include
#include
#include
#include
#include
#include
class viewerThread: public OpenThreads::Thread
{
public:
viewerThread( osg::Node* n ): OpenThreads::Thread(), _scene(n){}
virtual void run(){
osgViewer::Viewer viewer;
_pViewer = &viewer;
viewer.addEventHandler(new osgViewer::StatsHandler());
viewer.addEventHandler(new osgViewer::ThreadingHandler());
viewer.addEventHandler(new osgViewer::WindowSizeHandler());
viewer.setSceneData(_scene);
viewer.setThreadingModel(osgViewer::Viewer::ThreadPerContext);
viewer.run();
_pViewer = NULL;
}
void cancelViewer(){
if( _pViewer != NULL )
_pViewer->setDone( true );
}
private:
osg::Node* _scene;
osgViewer::Viewer* _pViewer;
};
int main(int argc, wchar_t* argv[])
{
std::vector garbage;
osg::ref_ptr n = osgDB::readNodeFile("cow.osg");
if( !n ) return -1;
bool bRun = true;
do{
std::wstring wsCommand;
std::wcout << L"Enter Command : ";
std::getline( std::wcin, wsCommand, L'\n' );
if( wsCommand == L"quit" ){
bRun = false;
}else if ( wsCommand == L"view" ){
viewerThread* vThread = new viewerThread( n.get()
);
garbage.push_back( vThread );
vThread->startThread();
}
}while( bRun );
for( unsigned int i = 0; i < garbage.size(); i++ ){
viewerThread* p = garbage.at( i );
p->cancelViewer();
p->cancel();
while ( p->isRunning() )
{
OpenThreads::Thread::microSleep(50);
}
delete p;
}
garbage.clear();
return 1;
}
Regards,
David Johansson
On Thu, Aug 14, 2008 at 10:14 AM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
Hi David,
I really don't know what is up with your usage, there really isn't
enough info about how you set up things to know where things are going
astray.
A window being black suggest to be that rendering itself hasn't
started yet, just that the window has been realized. The osgViewer
doesn't support multiple viewers sharing a single GraphicsContext
(this is what you should use osgViewer::CompositeViewer for so you can
have multiple views sharing a single context).
Robert.
On Wed, Aug 13, 2008 at 7:09 PM, David Johansson <[EMAIL PROTECTED]>
wrote:
Hi Everyone,
I have a problem with threading and osg::Viewer.
Basically i create and recreate a bunch of threads that runs a new
Viewer instance and the problem is that the viewers 'draw area' turns
up black if i ever close a Viewer.
Thread1 creates Window1 - viewing Node1 - OK.
Thread2 creates Window2 - viewing Node1 - Ok.
User closes Window1
Thread1 dies.
Thread3 creates Window3 - viewing Node1 -- Will turn up black
Thread4 creates Window4 - viewing Node1 -- All Ok..
Thread5 creates Window5 - viewing Node1 -- Also Ok
User closes window 2
Thread2 dies.
Thread6 creates Window6 - viewing Node1 -- Will turn up black
Thread7 creates Window7 - viewing Node1 -- Ok again.
User closes all windows
Thread3 - 7 dies.
Thread8 creates Window8 - viewing Node1 -- Black.
Thread9 creates Window9 - viewing Node1 -- Black.
Thread10 creates Window10 - viewing Node1 -- Black.
Thread11 creates Window11 - viewing Node1 -- Black.
Thread12 creates Window12 - viewing Node1 -- Black.
Thread13 creates Window13 - viewing Node1 -- Ok!
I noticed that After closing all windows, i had 5 windows running that
acctually showed something(5 new Contexts??). After that i had to
create 5 threads (that were black) until getting a new view that
wasn't black.
Looking through the code my guess is that "graphicsContexts" are
getting reused, however n
Re: [osg-users] osgViewer's turns up black when run from different threads.
Hi David,
Could you try OSG-2.6?
Robert.
On Thu, Aug 14, 2008 at 2:40 PM, David Johansson <[EMAIL PROTECTED]> wrote:
> Hi Paul,
>
> type "view" 2 times to get 2 views.
> close the first window, i always press 'f' to get out of fullscreen,
> type "view" again.. turns up black.
>
> Maybe this is my driver?
> I'm using the default ubuntu Nvidia driver. Also, running Compiz in
> the background..
>
>
> Regards,
>
> David Johansson
>
>
>
> On Thu, Aug 14, 2008 at 3:08 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
>> I've tried a different series of entering "view" one or more times, followed
>> by closing one or more of the shown windows and repeating. But I've not seen
>> any "black windows" yet. What is the sequence that reproduces the problem
>> for you?
>>
>> This is on Linux, nVidia 96.43.01 driver
>>
>> Paul
>>
>> David Johansson wrote:
>>>
>>> Hi Robert,
>>>
>>> Here is code that produces the problem.
>>>
>>> I'm building/running on Ubuntu 8.04 with osg 2.4
>>>
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>> class viewerThread: public OpenThreads::Thread
>>> {
>>> public:
>>>viewerThread( osg::Node* n ): OpenThreads::Thread(), _scene(n){}
>>>virtual void run(){
>>>osgViewer::Viewer viewer;
>>>_pViewer = &viewer;
>>>viewer.addEventHandler(new osgViewer::StatsHandler());
>>>viewer.addEventHandler(new osgViewer::ThreadingHandler());
>>>viewer.addEventHandler(new osgViewer::WindowSizeHandler());
>>>viewer.setSceneData(_scene);
>>>
>>> viewer.setThreadingModel(osgViewer::Viewer::ThreadPerContext);
>>>viewer.run();
>>>_pViewer = NULL;
>>>}
>>>void cancelViewer(){
>>>if( _pViewer != NULL )
>>>_pViewer->setDone( true );
>>>}
>>> private:
>>>osg::Node* _scene;
>>>osgViewer::Viewer* _pViewer;
>>>
>>> };
>>>
>>> int main(int argc, wchar_t* argv[])
>>> {
>>>std::vector garbage;
>>>osg::ref_ptr n = osgDB::readNodeFile("cow.osg");
>>>if( !n ) return -1;
>>>bool bRun = true;
>>>do{
>>>std::wstring wsCommand;
>>>std::wcout << L"Enter Command : ";
>>>std::getline( std::wcin, wsCommand, L'\n' );
>>>
>>>if( wsCommand == L"quit" ){
>>>bRun = false;
>>>}else if ( wsCommand == L"view" ){
>>>viewerThread* vThread = new viewerThread( n.get()
>>> );
>>>garbage.push_back( vThread );
>>>vThread->startThread();
>>>}
>>>}while( bRun );
>>>
>>>for( unsigned int i = 0; i < garbage.size(); i++ ){
>>>viewerThread* p = garbage.at( i );
>>>p->cancelViewer();
>>>p->cancel();
>>>while ( p->isRunning() )
>>>{
>>>OpenThreads::Thread::microSleep(50);
>>>}
>>>delete p;
>>>}
>>>garbage.clear();
>>>return 1;
>>> }
>>>
>>> Regards,
>>>
>>> David Johansson
>>>
>>>
>>> On Thu, Aug 14, 2008 at 10:14 AM, Robert Osfield
>>> <[EMAIL PROTECTED]> wrote:
>>>
Hi David,
I really don't know what is up with your usage, there really isn't
enough info about how you set up things to know where things are going
astray.
A window being black suggest to be that rendering itself hasn't
started yet, just that the window has been realized. The osgViewer
doesn't support multiple viewers sharing a single GraphicsContext
(this is what you should use osgViewer::CompositeViewer for so you can
have multiple views sharing a single context).
Robert.
On Wed, Aug 13, 2008 at 7:09 PM, David Johansson <[EMAIL PROTECTED]>
wrote:
>
> Hi Everyone,
>
> I have a problem with threading and osg::Viewer.
>
> Basically i create and recreate a bunch of threads that runs a new
> Viewer instance and the problem is that the viewers 'draw area' turns
> up black if i ever close a Viewer.
>
> Thread1 creates Window1 - viewing Node1 - OK.
> Thread2 creates Window2 - viewing Node1 - Ok.
> User closes Window1
> Thread1 dies.
> Thread3 creates Window3 - viewing Node1 -- Will turn up black
> Thread4 creates Window4 - viewing Node1 -- All Ok..
> Thread5 creates Window5 - viewing Node1 -- Also Ok
> User closes window 2
> Thread2 dies.
> Thread6 creates Window6 - viewing Node1 -- Will turn up black
> Thread7 creates Window7 - viewing Node1 -- Ok again.
> User closes all windows
> Thread3 - 7 dies.
> Thread8 creates Window8 - viewing Node1 -- Black.
> Thread9 creates Window9 - viewing Node1 -- Black.
> Thread10 creates Window
Re: [osg-users] osgViewer's turns up black when run from different threads.
Paul Melis wrote:
David Johansson wrote:
Hi Paul,
type "view" 2 times to get 2 views.
close the first window, i always press 'f' to get out of fullscreen,
type "view" again.. turns up black.
No problems here with that sequence...
This was with 2.4 btw
Paul
Maybe this is my driver?
It could be
I'm using the default ubuntu Nvidia driver.
cat /proc/drivers/nvidia/version
to discover which version you're running.
Also, running Compiz in
the background..
Hmmm, can you easily try without compiz?
Paul
Regards,
David Johansson
On Thu, Aug 14, 2008 at 3:08 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
I've tried a different series of entering "view" one or more times,
followed
by closing one or more of the shown windows and repeating. But I've
not seen
any "black windows" yet. What is the sequence that reproduces the
problem
for you?
This is on Linux, nVidia 96.43.01 driver
Paul
David Johansson wrote:
Hi Robert,
Here is code that produces the problem.
I'm building/running on Ubuntu 8.04 with osg 2.4
#include
#include
#include
#include
#include
#include
#include
#include
class viewerThread: public OpenThreads::Thread
{
public:
viewerThread( osg::Node* n ): OpenThreads::Thread(),
_scene(n){}
virtual void run(){
osgViewer::Viewer viewer;
_pViewer = &viewer;
viewer.addEventHandler(new osgViewer::StatsHandler());
viewer.addEventHandler(new
osgViewer::ThreadingHandler());
viewer.addEventHandler(new
osgViewer::WindowSizeHandler());
viewer.setSceneData(_scene);
viewer.setThreadingModel(osgViewer::Viewer::ThreadPerContext);
viewer.run();
_pViewer = NULL;
}
void cancelViewer(){
if( _pViewer != NULL )
_pViewer->setDone( true );
}
private:
osg::Node* _scene;
osgViewer::Viewer* _pViewer;
};
int main(int argc, wchar_t* argv[])
{
std::vector garbage;
osg::ref_ptr n = osgDB::readNodeFile("cow.osg");
if( !n ) return -1;
bool bRun = true;
do{
std::wstring wsCommand;
std::wcout << L"Enter Command : ";
std::getline( std::wcin, wsCommand, L'\n' );
if( wsCommand == L"quit" ){
bRun = false;
}else if ( wsCommand == L"view" ){
viewerThread* vThread = new viewerThread(
n.get()
);
garbage.push_back( vThread );
vThread->startThread();
}
}while( bRun );
for( unsigned int i = 0; i < garbage.size(); i++ ){
viewerThread* p = garbage.at( i );
p->cancelViewer();
p->cancel();
while ( p->isRunning() )
{
OpenThreads::Thread::microSleep(50);
}
delete p;
}
garbage.clear();
return 1;
}
Regards,
David Johansson
On Thu, Aug 14, 2008 at 10:14 AM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
Hi David,
I really don't know what is up with your usage, there really isn't
enough info about how you set up things to know where things are
going
astray.
A window being black suggest to be that rendering itself hasn't
started yet, just that the window has been realized. The osgViewer
doesn't support multiple viewers sharing a single GraphicsContext
(this is what you should use osgViewer::CompositeViewer for so you
can
have multiple views sharing a single context).
Robert.
On Wed, Aug 13, 2008 at 7:09 PM, David Johansson
<[EMAIL PROTECTED]>
wrote:
Hi Everyone,
I have a problem with threading and osg::Viewer.
Basically i create and recreate a bunch of threads that runs a new
Viewer instance and the problem is that the viewers 'draw area'
turns
up black if i ever close a Viewer.
Thread1 creates Window1 - viewing Node1 - OK.
Thread2 creates Window2 - viewing Node1 - Ok.
User closes Window1
Thread1 dies.
Thread3 creates Window3 - viewing Node1 -- Will turn up black
Thread4 creates Window4 - viewing Node1 -- All Ok..
Thread5 creates Window5 - viewing Node1 -- Also Ok
User closes window 2
Thread2 dies.
Thread6 creates Window6 - viewing Node1 -- Will turn up black
Thread7 creates Window7 - viewing Node1 -- Ok again.
User closes all windows
Thread3 - 7 dies.
Thread8 creates Window8 - viewing Node1 -- Black.
Thread9 creates Window9 - viewing Node1 -- Black.
Thread10 creates Window10 - viewing Node1 -- Black.
Thread11 creates Window11 - viewing Node1 -- Black.
Thread12 creates Window12 - viewing Node1 -- Black.
Thread13 creates Window13 - viewing Node1 -- Ok!
I noticed that After closing all windows, i had 5 windows running
that
acctually showed something(5 new Contexts??). After that i had to
create 5 threads (that were black) until getting a new view that
wasn't black.
Looking through the code m
Re: [osg-users] osgViewer's turns up black when run from different threads.
Hi Paul,
output of : cat /proc/drivers/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module 169.12 Thu Feb 14
17:51:09 PST 2008
GCC version: gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
Also running on GeForce 7950 GX2 (http://www.nvidia.com/page/geforce_7950.html)
It has 2 GPU's maybe there is some problem there?
> Hmmm, can you easily try without compiz?
Done, and it did nothing im afraid.
Regards,
David Johansson
On Thu, Aug 14, 2008 at 3:45 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
> David Johansson wrote:
>>
>> Hi Paul,
>>
>> type "view" 2 times to get 2 views.
>> close the first window, i always press 'f' to get out of fullscreen,
>> type "view" again.. turns up black.
>>
>
> No problems here with that sequence...
>>
>> Maybe this is my driver?
>>
>
> It could be
>>
>> I'm using the default ubuntu Nvidia driver.
>
> cat /proc/drivers/nvidia/version
> to discover which version you're running.
>>
>> Also, running Compiz in
>> the background..
>>
>
> Hmmm, can you easily try without compiz?
> Paul
>>
>> Regards,
>>
>> David Johansson
>>
>>
>>
>> On Thu, Aug 14, 2008 at 3:08 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> I've tried a different series of entering "view" one or more times,
>>> followed
>>> by closing one or more of the shown windows and repeating. But I've not
>>> seen
>>> any "black windows" yet. What is the sequence that reproduces the problem
>>> for you?
>>>
>>> This is on Linux, nVidia 96.43.01 driver
>>>
>>> Paul
>>>
>>> David Johansson wrote:
>>>
Hi Robert,
Here is code that produces the problem.
I'm building/running on Ubuntu 8.04 with osg 2.4
#include
#include
#include
#include
#include
#include
#include
#include
class viewerThread: public OpenThreads::Thread
{
public:
viewerThread( osg::Node* n ): OpenThreads::Thread(), _scene(n){}
virtual void run(){
osgViewer::Viewer viewer;
_pViewer = &viewer;
viewer.addEventHandler(new osgViewer::StatsHandler());
viewer.addEventHandler(new osgViewer::ThreadingHandler());
viewer.addEventHandler(new
osgViewer::WindowSizeHandler());
viewer.setSceneData(_scene);
viewer.setThreadingModel(osgViewer::Viewer::ThreadPerContext);
viewer.run();
_pViewer = NULL;
}
void cancelViewer(){
if( _pViewer != NULL )
_pViewer->setDone( true );
}
private:
osg::Node* _scene;
osgViewer::Viewer* _pViewer;
};
int main(int argc, wchar_t* argv[])
{
std::vector garbage;
osg::ref_ptr n = osgDB::readNodeFile("cow.osg");
if( !n ) return -1;
bool bRun = true;
do{
std::wstring wsCommand;
std::wcout << L"Enter Command : ";
std::getline( std::wcin, wsCommand, L'\n' );
if( wsCommand == L"quit" ){
bRun = false;
}else if ( wsCommand == L"view" ){
viewerThread* vThread = new viewerThread( n.get()
);
garbage.push_back( vThread );
vThread->startThread();
}
}while( bRun );
for( unsigned int i = 0; i < garbage.size(); i++ ){
viewerThread* p = garbage.at( i );
p->cancelViewer();
p->cancel();
while ( p->isRunning() )
{
OpenThreads::Thread::microSleep(50);
}
delete p;
}
garbage.clear();
return 1;
}
Regards,
David Johansson
On Thu, Aug 14, 2008 at 10:14 AM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
>
> Hi David,
>
> I really don't know what is up with your usage, there really isn't
> enough info about how you set up things to know where things are going
> astray.
>
> A window being black suggest to be that rendering itself hasn't
> started yet, just that the window has been realized. The osgViewer
> doesn't support multiple viewers sharing a single GraphicsContext
> (this is what you should use osgViewer::CompositeViewer for so you can
> have multiple views sharing a single context).
>
> Robert.
>
> On Wed, Aug 13, 2008 at 7:09 PM, David Johansson <[EMAIL PROTECTED]>
> wrote:
>
>
>>
>> Hi Everyone,
>>
>> I have a problem with threading and osg::Viewer.
>>
>> Basically i create and recreate a bunch of threads that runs a new
>> Viewer instance and the problem is that the viewers 'draw area' turns
Re: [osg-users] osgViewer's turns up black when run from different threads.
Hi Robert,
> Could you try OSG-2.6?
Sure
Regards
David Johansson
On Thu, Aug 14, 2008 at 3:46 PM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
> Hi David,
>
> Could you try OSG-2.6?
>
> Robert.
>
> On Thu, Aug 14, 2008 at 2:40 PM, David Johansson <[EMAIL PROTECTED]> wrote:
>> Hi Paul,
>>
>> type "view" 2 times to get 2 views.
>> close the first window, i always press 'f' to get out of fullscreen,
>> type "view" again.. turns up black.
>>
>> Maybe this is my driver?
>> I'm using the default ubuntu Nvidia driver. Also, running Compiz in
>> the background..
>>
>>
>> Regards,
>>
>> David Johansson
>>
>>
>>
>> On Thu, Aug 14, 2008 at 3:08 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
>>> I've tried a different series of entering "view" one or more times, followed
>>> by closing one or more of the shown windows and repeating. But I've not seen
>>> any "black windows" yet. What is the sequence that reproduces the problem
>>> for you?
>>>
>>> This is on Linux, nVidia 96.43.01 driver
>>>
>>> Paul
>>>
>>> David Johansson wrote:
Hi Robert,
Here is code that produces the problem.
I'm building/running on Ubuntu 8.04 with osg 2.4
#include
#include
#include
#include
#include
#include
#include
#include
class viewerThread: public OpenThreads::Thread
{
public:
viewerThread( osg::Node* n ): OpenThreads::Thread(), _scene(n){}
virtual void run(){
osgViewer::Viewer viewer;
_pViewer = &viewer;
viewer.addEventHandler(new osgViewer::StatsHandler());
viewer.addEventHandler(new osgViewer::ThreadingHandler());
viewer.addEventHandler(new osgViewer::WindowSizeHandler());
viewer.setSceneData(_scene);
viewer.setThreadingModel(osgViewer::Viewer::ThreadPerContext);
viewer.run();
_pViewer = NULL;
}
void cancelViewer(){
if( _pViewer != NULL )
_pViewer->setDone( true );
}
private:
osg::Node* _scene;
osgViewer::Viewer* _pViewer;
};
int main(int argc, wchar_t* argv[])
{
std::vector garbage;
osg::ref_ptr n = osgDB::readNodeFile("cow.osg");
if( !n ) return -1;
bool bRun = true;
do{
std::wstring wsCommand;
std::wcout << L"Enter Command : ";
std::getline( std::wcin, wsCommand, L'\n' );
if( wsCommand == L"quit" ){
bRun = false;
}else if ( wsCommand == L"view" ){
viewerThread* vThread = new viewerThread( n.get()
);
garbage.push_back( vThread );
vThread->startThread();
}
}while( bRun );
for( unsigned int i = 0; i < garbage.size(); i++ ){
viewerThread* p = garbage.at( i );
p->cancelViewer();
p->cancel();
while ( p->isRunning() )
{
OpenThreads::Thread::microSleep(50);
}
delete p;
}
garbage.clear();
return 1;
}
Regards,
David Johansson
On Thu, Aug 14, 2008 at 10:14 AM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
>
> Hi David,
>
> I really don't know what is up with your usage, there really isn't
> enough info about how you set up things to know where things are going
> astray.
>
> A window being black suggest to be that rendering itself hasn't
> started yet, just that the window has been realized. The osgViewer
> doesn't support multiple viewers sharing a single GraphicsContext
> (this is what you should use osgViewer::CompositeViewer for so you can
> have multiple views sharing a single context).
>
> Robert.
>
> On Wed, Aug 13, 2008 at 7:09 PM, David Johansson <[EMAIL PROTECTED]>
> wrote:
>
>>
>> Hi Everyone,
>>
>> I have a problem with threading and osg::Viewer.
>>
>> Basically i create and recreate a bunch of threads that runs a new
>> Viewer instance and the problem is that the viewers 'draw area' turns
>> up black if i ever close a Viewer.
>>
>> Thread1 creates Window1 - viewing Node1 - OK.
>> Thread2 creates Window2 - viewing Node1 - Ok.
>> User closes Window1
>> Thread1 dies.
>> Thread3 creates Window3 - viewing Node1 -- Will turn up black
>> Thread4 creates Window4 - viewing Node1 -- All Ok..
>> Thread5 creates Window5 - viewing Node1 -- Also Ok
>> User closes window 2
>> Thread2 dies.
>> Thread6 crea
Re: [osg-users] osgViewer's turns up black when run from different threads.
David Johansson wrote:
Hi Paul,
output of : cat /proc/drivers/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module 169.12 Thu Feb 14
17:51:09 PST 2008
GCC version: gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
Also running on GeForce 7950 GX2 (http://www.nvidia.com/page/geforce_7950.html)
It has 2 GPU's maybe there is some problem there?
Interesting, although I don't enough about OSG's use of threading to
judge that. Perhaps Robert has some insight.
Paul
Hmmm, can you easily try without compiz?
Done, and it did nothing im afraid.
Regards,
David Johansson
On Thu, Aug 14, 2008 at 3:45 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
David Johansson wrote:
Hi Paul,
type "view" 2 times to get 2 views.
close the first window, i always press 'f' to get out of fullscreen,
type "view" again.. turns up black.
No problems here with that sequence...
Maybe this is my driver?
It could be
I'm using the default ubuntu Nvidia driver.
cat /proc/drivers/nvidia/version
to discover which version you're running.
Also, running Compiz in
the background..
Hmmm, can you easily try without compiz?
Paul
Regards,
David Johansson
On Thu, Aug 14, 2008 at 3:08 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
I've tried a different series of entering "view" one or more times,
followed
by closing one or more of the shown windows and repeating. But I've not
seen
any "black windows" yet. What is the sequence that reproduces the problem
for you?
This is on Linux, nVidia 96.43.01 driver
Paul
David Johansson wrote:
Hi Robert,
Here is code that produces the problem.
I'm building/running on Ubuntu 8.04 with osg 2.4
#include
#include
#include
#include
#include
#include
#include
#include
class viewerThread: public OpenThreads::Thread
{
public:
viewerThread( osg::Node* n ): OpenThreads::Thread(), _scene(n){}
virtual void run(){
osgViewer::Viewer viewer;
_pViewer = &viewer;
viewer.addEventHandler(new osgViewer::StatsHandler());
viewer.addEventHandler(new osgViewer::ThreadingHandler());
viewer.addEventHandler(new
osgViewer::WindowSizeHandler());
viewer.setSceneData(_scene);
viewer.setThreadingModel(osgViewer::Viewer::ThreadPerContext);
viewer.run();
_pViewer = NULL;
}
void cancelViewer(){
if( _pViewer != NULL )
_pViewer->setDone( true );
}
private:
osg::Node* _scene;
osgViewer::Viewer* _pViewer;
};
int main(int argc, wchar_t* argv[])
{
std::vector garbage;
osg::ref_ptr n = osgDB::readNodeFile("cow.osg");
if( !n ) return -1;
bool bRun = true;
do{
std::wstring wsCommand;
std::wcout << L"Enter Command : ";
std::getline( std::wcin, wsCommand, L'\n' );
if( wsCommand == L"quit" ){
bRun = false;
}else if ( wsCommand == L"view" ){
viewerThread* vThread = new viewerThread( n.get()
);
garbage.push_back( vThread );
vThread->startThread();
}
}while( bRun );
for( unsigned int i = 0; i < garbage.size(); i++ ){
viewerThread* p = garbage.at( i );
p->cancelViewer();
p->cancel();
while ( p->isRunning() )
{
OpenThreads::Thread::microSleep(50);
}
delete p;
}
garbage.clear();
return 1;
}
Regards,
David Johansson
On Thu, Aug 14, 2008 at 10:14 AM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
Hi David,
I really don't know what is up with your usage, there really isn't
enough info about how you set up things to know where things are going
astray.
A window being black suggest to be that rendering itself hasn't
started yet, just that the window has been realized. The osgViewer
doesn't support multiple viewers sharing a single GraphicsContext
(this is what you should use osgViewer::CompositeViewer for so you can
have multiple views sharing a single context).
Robert.
On Wed, Aug 13, 2008 at 7:09 PM, David Johansson <[EMAIL PROTECTED]>
wrote:
Hi Everyone,
I have a problem with threading and osg::Viewer.
Basically i create and recreate a bunch of threads that runs a new
Viewer instance and the problem is that the viewers 'draw area' turns
up black if i ever close a Viewer.
Thread1 creates Window1 - viewing Node1 - OK.
Thread2 creates Window2 - viewing Node1 - Ok.
User closes Window1
Thread1 dies.
Thread3 creates Window3 - viewing Node1 -- Will turn up black
Thread4 creates Window4 - viewing Node1 -- All Ok..
Thread5 creates Window5 - viewing Node1 -- Also Ok
User closes window 2
Thread2 dies.
Thread6 creates Window6 - viewing Node1 -- Will turn up black
Thread7 creates Wind
Re: [osg-users] osgViewer's turns up black when run from different threads.
On Thu, Aug 14, 2008 at 2:56 PM, David Johansson <[EMAIL PROTECTED]> wrote: > output of : cat /proc/drivers/nvidia/version > > NVRM version: NVIDIA UNIX x86_64 Kernel Module 169.12 Thu Feb 14 > 17:51:09 PST 2008 > GCC version: gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) > > Also running on GeForce 7950 GX2 > (http://www.nvidia.com/page/geforce_7950.html) > It has 2 GPU's maybe there is some problem there? It may well be an driver issue with SLI. Try disabling SLI. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer's turns up black when run from different threads.
Hi Robert, This does nothing i'm afraid. nvidia-xconfig --sli=Off followed by a restart of X.. David On Thu, Aug 14, 2008 at 4:02 PM, Robert Osfield <[EMAIL PROTECTED]> wrote: > On Thu, Aug 14, 2008 at 2:56 PM, David Johansson <[EMAIL PROTECTED]> wrote: >> output of : cat /proc/drivers/nvidia/version >> >> NVRM version: NVIDIA UNIX x86_64 Kernel Module 169.12 Thu Feb 14 >> 17:51:09 PST 2008 >> GCC version: gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) >> >> Also running on GeForce 7950 GX2 >> (http://www.nvidia.com/page/geforce_7950.html) >> It has 2 GPU's maybe there is some problem there? > > It may well be an driver issue with SLI. Try disabling SLI. > > Robert. > ___ > 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] Issues with Intel 945GM chipset and VBO's
Hi all, I recently updated our product to use the --terrain flag in VirtualPlanetBuilder to increase the speed of our database creation and things are working wonderfully except for on the machines that have the Intel 945GM chipset which are crashing. I've narrowed the problem down to the fact that the 945GM doesn't seem to like using VBO, which is enabled in GeometryTechnique.cpp. If I revert back to not using the --terrain option, which does not use VBO, things work just fine. Also, if I set the environment variable OSG_DATABASE_PAGER_DRAWABLE=VertexArrays, things also work just fine. I would like to not have to revert back to not using the --terrain option since the performance increases on machines that support VBO are so substantial but I also don't want specific users to have to modify the environment variable. In theory, we can know whether or not VBO is supported by the graphics card by using the State::isVertexBufferObjectSupported(), but the 945GM must be incorrectly reporting that it does support VBO. Does anyone have any suggestions on what I should do in this situation? Thanks! Jason ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Issues with Intel 945GM chipset and VBO's
HI Jason, You could try disabling the vertex array extension for Intel via the the osg::setGLExtensionDisableString() >From include/osg/GL /** Set a list of extensions to disable for different OpenGL renderers. This allows * OSG applications to work around OpenGL drivers' bugs which are due to problematic extension support. * The format of the string is: * "GLRendererString : ExtensionName, ExtensionName; GLRenderString2 : ExtensionName;" * An example of is : "SUN_XVR1000:GL_EXT_texture_filter_anisotropic" * The default setting of GLExtensionDisableString is obtained from the OSG_GL_EXTENSION_DISABLE * environmental variable. */ extern OSG_EXPORT void setGLExtensionDisableString(const std::string& disableString); Longer term it might be worth us developing a software/hardware configuration file system, that can provide different profiles for different hardware/drivers. Robert. On Thu, Aug 14, 2008 at 3:42 PM, Jason Beverage <[EMAIL PROTECTED]> wrote: > Hi all, > > I recently updated our product to use the --terrain flag in > VirtualPlanetBuilder to increase the speed of our database creation and > things are working wonderfully except for on the machines that have the > Intel 945GM chipset which are crashing. > > I've narrowed the problem down to the fact that the 945GM doesn't seem to > like using VBO, which is enabled in GeometryTechnique.cpp. If I revert back > to not using the --terrain option, which does not use VBO, things work just > fine. Also, if I set the environment variable > OSG_DATABASE_PAGER_DRAWABLE=VertexArrays, things also work just fine. > > I would like to not have to revert back to not using the --terrain option > since the performance increases on machines that support VBO are so > substantial but I also don't want specific users to have to modify the > environment variable. > > In theory, we can know whether or not VBO is supported by the graphics card > by using the State::isVertexBufferObjectSupported(), but the 945GM must be > incorrectly reporting that it does support VBO. > > Does anyone have any suggestions on what I should do in this situation? > > Thanks! > > Jason > > ___ > 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] LineSegmentIntersector does not work with Billboards
It seems to work just fine in my application. Thanks for the support. Judd Robert Osfield wrote: Hi Judd, I have done some work on osgUtil::IntersectionVisitor to add proper support for Billboards. Could you try out the attached IntersectionVisitor header/source files and let me know how you get on. This builds against OSG-2.6/OSG-SVN, but might also compile against 2.4. In my own testing 'osgpick lz.osg' now works fine, whereas before this fix it failed to pick the billboarded trees. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Issues with Intel 945GM chipset and VBO's
Hi Robert, Thanks for much for your quick response, I'll take a look at this and see how things go. After your suggestion and doing a quick Google I saw this post from Rafa that looks to be close to the same issue I have. http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2007-September/002960.html Thanks! Jason On Thu, Aug 14, 2008 at 10:49 AM, Robert Osfield <[EMAIL PROTECTED]>wrote: > HI Jason, > > You could try disabling the vertex array extension for Intel via the > the osg::setGLExtensionDisableString() > > >From include/osg/GL > > /** Set a list of extensions to disable for different OpenGL > renderers. This allows > * OSG applications to work around OpenGL drivers' bugs which are due > to problematic extension support. > * The format of the string is: > * "GLRendererString : ExtensionName, ExtensionName; GLRenderString2 > : ExtensionName;" > * An example of is : "SUN_XVR1000:GL_EXT_texture_filter_anisotropic" > * The default setting of GLExtensionDisableString is obtained from > the OSG_GL_EXTENSION_DISABLE > * environmental variable. > */ > extern OSG_EXPORT void setGLExtensionDisableString(const std::string& > disableString); > > Longer term it might be worth us developing a software/hardware > configuration file system, that can provide different profiles for > different hardware/drivers. > > Robert. > > On Thu, Aug 14, 2008 at 3:42 PM, Jason Beverage <[EMAIL PROTECTED]> > wrote: > > Hi all, > > > > I recently updated our product to use the --terrain flag in > > VirtualPlanetBuilder to increase the speed of our database creation and > > things are working wonderfully except for on the machines that have the > > Intel 945GM chipset which are crashing. > > > > I've narrowed the problem down to the fact that the 945GM doesn't seem to > > like using VBO, which is enabled in GeometryTechnique.cpp. If I revert > back > > to not using the --terrain option, which does not use VBO, things work > just > > fine. Also, if I set the environment variable > > OSG_DATABASE_PAGER_DRAWABLE=VertexArrays, things also work just fine. > > > > I would like to not have to revert back to not using the --terrain option > > since the performance increases on machines that support VBO are so > > substantial but I also don't want specific users to have to modify the > > environment variable. > > > > In theory, we can know whether or not VBO is supported by the graphics > card > > by using the State::isVertexBufferObjectSupported(), but the 945GM must > be > > incorrectly reporting that it does support VBO. > > > > Does anyone have any suggestions on what I should do in this situation? > > > > Thanks! > > > > Jason > > > > ___ > > 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] pick on specific subgraph / nodepath
Hi Robert, could you please just confirm the this is the way the function is meant to work?? If so, any idea on how to have my modified osgpick example to work? Thanks a lot! Ricky -Original Message- From: [EMAIL PROTECTED] on behalf of Riccardo Corsi Sent: Thu 14/08/2008 10.39 To: [EMAIL PROTECTED]; OpenSceneGraph Users Cc: Subject:Re: [osg-users] pick on specific subgraph / nodepath I've checked the source code about this, and after using the nodepath to unproject the 2D coordinates and retrieve the 3d start and end points of the line-intersector, the visit is called like this: osgUtil::IntersectionVisitor iv(picker); iv.setTraversalMask(traversalMask); nodePath.back()->accept(iv); so I expected it to start visiting from the last node of the nodepath downwards into its subgraph. Is it the case? Ricky -Original Message- From: [EMAIL PROTECTED] on behalf of Gordon Tomlinson Sent: Thu 14/08/2008 2.38 To: 'OpenSceneGraph Users' Cc: Subject:Re: [osg-users] pick on specific subgraph / nodepath I think the problem might be the pHudRootNode->getParentalNodePaths()[0] What this will do is traverse only the node getParentalNodePaths()[0] and is direct SceneGraph descendants As far as I know it will not traverse paths only the first node which may or may not be a node your after Perhaps you want pHudRootNode->getParent() or just pHudRootNode __ Gordon Tomlinson [EMAIL PROTECTED] IM: [EMAIL PROTECTED] www.vis-sim.com www.gordontomlinson.com __ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Riccardo Corsi Sent: Wednesday, August 13, 2008 7:30 PM To: OpenSceneGraph Users Subject: Re: [osg-users] pick on specific subgraph / nodepath Hi Gordon, I know the nodemask is an often suggested solution, but what I don't like about it is that it forces me to touch also other nodes/subgraphs I'm not interested in, that I would ignore, while I must go and set a mask on them. Instead, when I know a priori the small subgraph I want to pick on (one representing a manipulator, for instance) I would consider more straightforward and less "polluting" to pick on a single nodepath, instead of excluding all of the others via nodemask. Does this make sense? Or there's a better use of nodemasks I'm not aware of?? Thank you, Ricky -Original Message- From: [EMAIL PROTECTED] on behalf of Tomlinson, Gordon Sent: Wed 13/08/2008 20.38 To: OpenSceneGraph Users Cc: Subject:Re: [osg-users] pick on specific subgraph / nodepath Err that should be 'use' not used (as you don't know were they may have been ;) ) SetNodeMask( 0x0 ) for those nodes you don't want to touch SetNodeMask( 0x) on the Nodes you want to touch as well as on the visitor/isector -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomlinson, Gordon Sent: Wednesday, August 13, 2008 2:24 PM To: OpenSceneGraph Users Subject: Re: [osg-users] pick on specific subgraph / nodepath Why not just used node masks ? This is the typical way to approach this problem Gordon __ Gordon Tomlinson Email : gtomlinson @ overwatch.textron.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Riccardo Corsi Sent: Wednesday, August 13, 2008 2:07 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] pick on specific subgraph / nodepath Hi All, I'm trying to do some picking only in a specific subgraph, so I was thinking to use the version of "computeIntersections" which include a nodepath option. Unfortunately it didn't work as aspected, and I don't know where I'm wrong. I modified the osgpick example (attached) to pick, for instance, only the rectangles in the HUD. What I do is: - store the root of the HUD in a pHudRootNode - pick with the funtion viewer->computeIntersections(ea.getX(), ea.getY(), pHudRootNode->getParentalNodePaths()[0], intersections) but I don't get any result. I've also tried to limit the nodepath to the view's SceneData, like this: pHudRootNode->getParentalNodePaths(viewer->getSceneData())[0] but it doesn't work either. Where am I wrong? Thank you! Ricky ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-
Re: [osg-users] osg sequence timing
Thanks for the responses.
I'm not sure what "stopping the frame loop refers to", since something like
while(!viewer->done())
{
if (viewer->getFrameStamp()->getFrameNumber() == 500)
{
rootNode->addChild(
osgDB::readNodeFile("some_animation.flt"));
}
viewer->frame();
}
would exhibit the same problem. I've loooked at the source in more detail,
so I can be more explicit now about exactly what's going on.
When the sequence is loaded, the sim time is around 8 seconds, but the
sequence's _start (which I am assuming represents the time at which the
current frame started) is 0. The _start time is increased every frame by:
(line 312) _start += _frameTime[_value]*osg::absolute(_speed);
So since _start is so far behind _now, the animation runs 1 frame per update
until the time catches up.
With this in mind, I'll rephrase my questions:
1. Shouldn't line 312 be _start = _now; ?
2. What is the purpose of _sync, and why would an OSG user choose to set it
one way or the other?
3. Since with _sync off the animation speed is dependent on framerate, and
in most dynamic scenes framerate is not constant, shouldn't the default
value be true?
Thanks,
Max Bandazian
I looked at the sequence source in more detail, and I can be more explicit
about exactly what is going on. When the sequence node is loaded, the
frametime is
On Tue, Aug 12, 2008 at 1:28 PM, Robert Osfield <[EMAIL PROTECTED]>wrote:
> Hi Max,
>
> Stopping the frame loop and restarting it without explictly adjusting
> the simulation time to account for your frameloop stop is something
> that I'd expect to cause problems - I also can't see how the OSG could
> automatically catch this particular usage model.
>
> Robert.
>
> On Thu, Aug 7, 2008 at 6:26 PM, Max Bandazian <[EMAIL PROTECTED]>
> wrote:
> > Hi,
> > I am experiencing some buggy behavior relating to loaded openflight files
> > containing sequences, and I would appreciate any suggestions. When such a
> > file is loaded after the viewer has been running for a bit, the animation
> > runs at the wrong speed. Here's some sample code that illustrates the
> > problem:
> >
> > osg::ref_ptr rootNode = new osg::Group;
> >
> > osg::ref_ptr viewer = new osgViewer::Viewer;
> > viewer->setUpViewOnSingleScreen(0);
> > viewer->setSceneData(rootNode.get());
> > viewer->setCameraManipulator(new osgGA::TrackballManipulator());
> >
> > viewer->realize();
> >
> > while(!viewer->done() && viewer->getFrameStamp()->getFrameNumber()
> <
> > 500)
> > {
> > viewer->frame();
> > }
> >
> > osg::ref_ptr modelNode =
> > osgDB::readNodeFile("some_animation.flt");
> > rootNode->addChild(modelNode.get());
> >
> > while(!viewer->done())
> > {
> > viewer->frame();
> > }
> >
> > When the animation gets loaded in the above code, it runs much faster
> than
> > it ought to for around 5 seconds, and then runs at the normal rate. It
> > appears to be "catching up" with the frame time. Sending a visitor down
> > every loaded flt file and setting sync to true on all sequences seems to
> fix
> > the problem, but it seems like this should not be necessary.
> >
> > Thanks,
> > Max Bandazian
> >
> > ___
> > 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] osgViewer's turns up black when run from differentthreads.
David Johansson wrote: Hi Robert, This does nothing i'm afraid. nvidia-xconfig --sli=Off followed by a restart of X.. Not sure if this helps or not, but you have to use the "multigpu" option with the 7950GX2, not the "sli" option. "multigpu" is for SLI with two GPU's on one card, while "sli" implies the two GPU's are on separate cards. For some reason, there's a difference (check /usr/share/doc/NVIDIA_GLX-1.0/README.txt for details). --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg sequence timing
Hi Max,
My guess is that your Viewer's SimulationTime is up and running by the
time the new model is loaded, rather than starting off at 0.0 which is
causing the problems.
The actual implementation details of osg::Sequence is something that
community members have working on over the years, rather than me
developing it so I'm not best placed to answer why this/why that will
all the implementation details.
Robert.
On Thu, Aug 14, 2008 at 4:27 PM, Max Bandazian <[EMAIL PROTECTED]> wrote:
> Thanks for the responses.
>
> I'm not sure what "stopping the frame loop refers to", since something like
>
> while(!viewer->done())
> {
>if (viewer->getFrameStamp()->getFrameNumber() == 500)
>{
> rootNode->addChild(
> osgDB::readNodeFile("some_animation.flt"));
>}
>
>viewer->frame();
> }
>
> would exhibit the same problem. I've loooked at the source in more detail,
> so I can be more explicit now about exactly what's going on.
>
> When the sequence is loaded, the sim time is around 8 seconds, but the
> sequence's _start (which I am assuming represents the time at which the
> current frame started) is 0. The _start time is increased every frame by:
> (line 312) _start += _frameTime[_value]*osg::absolute(_speed);
> So since _start is so far behind _now, the animation runs 1 frame per update
> until the time catches up.
>
> With this in mind, I'll rephrase my questions:
> 1. Shouldn't line 312 be _start = _now; ?
> 2. What is the purpose of _sync, and why would an OSG user choose to set it
> one way or the other?
> 3. Since with _sync off the animation speed is dependent on framerate, and
> in most dynamic scenes framerate is not constant, shouldn't the default
> value be true?
>
> Thanks,
> Max Bandazian
>
>
> I looked at the sequence source in more detail, and I can be more explicit
> about exactly what is going on. When the sequence node is loaded, the
> frametime is
>
> On Tue, Aug 12, 2008 at 1:28 PM, Robert Osfield <[EMAIL PROTECTED]>
> wrote:
>>
>> Hi Max,
>>
>> Stopping the frame loop and restarting it without explictly adjusting
>> the simulation time to account for your frameloop stop is something
>> that I'd expect to cause problems - I also can't see how the OSG could
>> automatically catch this particular usage model.
>>
>> Robert.
>>
>> On Thu, Aug 7, 2008 at 6:26 PM, Max Bandazian <[EMAIL PROTECTED]>
>> wrote:
>> > Hi,
>> > I am experiencing some buggy behavior relating to loaded openflight
>> > files
>> > containing sequences, and I would appreciate any suggestions. When such
>> > a
>> > file is loaded after the viewer has been running for a bit, the
>> > animation
>> > runs at the wrong speed. Here's some sample code that illustrates the
>> > problem:
>> >
>> > osg::ref_ptr rootNode = new osg::Group;
>> >
>> > osg::ref_ptr viewer = new osgViewer::Viewer;
>> > viewer->setUpViewOnSingleScreen(0);
>> > viewer->setSceneData(rootNode.get());
>> > viewer->setCameraManipulator(new osgGA::TrackballManipulator());
>> >
>> > viewer->realize();
>> >
>> > while(!viewer->done() && viewer->getFrameStamp()->getFrameNumber()
>> > <
>> > 500)
>> > {
>> > viewer->frame();
>> > }
>> >
>> > osg::ref_ptr modelNode =
>> > osgDB::readNodeFile("some_animation.flt");
>> > rootNode->addChild(modelNode.get());
>> >
>> > while(!viewer->done())
>> > {
>> > viewer->frame();
>> > }
>> >
>> > When the animation gets loaded in the above code, it runs much faster
>> > than
>> > it ought to for around 5 seconds, and then runs at the normal rate. It
>> > appears to be "catching up" with the frame time. Sending a visitor down
>> > every loaded flt file and setting sync to true on all sequences seems to
>> > fix
>> > the problem, but it seems like this should not be necessary.
>> >
>> > Thanks,
>> > Max Bandazian
>> >
>> > ___
>> > 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] pick on specific subgraph / nodepath
On Thu, Aug 14, 2008 at 4:25 PM, Riccardo Corsi <[EMAIL PROTECTED]> wrote: > Hi Robert, > > could you please just confirm the this is the way the function is meant to > work?? > If so, any idea on how to have my modified osgpick example to work? Can't confirm "this" as really don't know what "this" might be specifically referring to. I'm rather out of the loop on this thread having been away so diving in mid flow is not something I'm about to do. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LineSegmentIntersector does not work with Billboards
Robert
I have added a method called set (did not know what to call it) that
allows you to set the start and end points for the LinSegmentIntersector
using the CooridnateFrame and the x, y values like one of the
constructors does. It just makes it easier to reset the start and end
points without having to know which values to use depending on the
CoordinateFrame.
Judd
Robert Osfield wrote:
Hi Judd,
I have done some work on osgUtil::IntersectionVisitor to add proper
support for Billboards. Could you try out the attached
IntersectionVisitor header/source files and let me know how you get
on. This builds against OSG-2.6/OSG-SVN, but might also compile
against 2.4.
In my own testing 'osgpick lz.osg' now works fine, whereas before this
fix it failed to pick the billboarded trees.
Robert.
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include
#include
#include
#include
#include
using namespace osgUtil;
namespace LineSegmentIntersectorUtils
{
struct TriangleIntersection
{
TriangleIntersection(unsigned int index, const osg::Vec3& normal, float
r1, const osg::Vec3* v1, float r2, const osg::Vec3* v2, float r3, const
osg::Vec3* v3):
_index(index),
_normal(normal),
_r1(r1),
_v1(v1),
_r2(r2),
_v2(v2),
_r3(r3),
_v3(v3) {}
unsigned int_index;
const osg::Vec3 _normal;
float _r1;
const osg::Vec3*_v1;
float _r2;
const osg::Vec3*_v2;
float _r3;
const osg::Vec3*_v3;
};
typedef std::multimap TriangleIntersections;
struct TriangleIntersector
{
osg::Vec3 _s;
osg::Vec3 _d;
float _length;
int _index;
float _ratio;
bool_hit;
TriangleIntersections _intersections;
TriangleIntersector()
{
_length = 0.0f;
_index = 0;
_ratio = 0.0f;
_hit = false;
}
void set(const osg::Vec3d& start, osg::Vec3d& end, float ratio=FLT_MAX)
{
_hit=false;
_index = 0;
_ratio = ratio;
_s = start;
_d = end - start;
_length = _d.length();
_d /= _length;
}
inline void operator () (const osg::Vec3& v1,const osg::Vec3& v2,const
osg::Vec3& v3, bool treatVertexDataAsTemporary)
{
++_index;
if (v1==v2 || v2==v3 || v1==v3) return;
osg::Vec3 v12 = v2-v1;
osg::Vec3 n12 = v12^_d;
float ds12 = (_s-v1)*n12;
float d312 = (v3-v1)*n12;
if (d312>=0.0f)
{
if (ds12<0.0f) return;
if (ds12>d312) return;
}
else // d312 < 0
{
if (ds12>0.0f) return;
if (ds12=0.0f)
{
if (ds23<0.0f) return;
if (ds23>d123) return;
}
else // d123 < 0
{
if (ds23>0.0f) return;
if (ds23=0.0f)
{
if (ds31<0.0f) return;
if (ds31>d231) return;
}
else // d231 < 0
{
if (ds31>0.0f) return;
if (ds31_length) return;
osg::Vec3 normal = v12^v23;
normal.normalize();
float r = d/_length;
if (treatVertexDataAsTemporary)
{
_intersections.insert(std::pair(r,TriangleIntersection(_index-1,normal,r1,0,r2,0,r3,0)));
}
else
{
_intersections.insert(std::pair(r,TriangleIntersection(_index-1,normal,r1,&v1,r2,&v2,r3,&v3)));
}
_hit = true;
}
};
}
///
//
// LineSegmentIntersector
//
LineSegmentIntersector::LineSegmentIntersector(const osg::Vec3d& start, const
osg::Vec3d& end):
_parent(0),
_start(start),
_end(end)
{
}
LineSegmentIntersector::LineSegmentIntersector(CoordinateF
Re: [osg-users] osgViewer's turns up black when run from differentthreads.
Hi Jason, Setting multigpu did nothing either. You don't happen to have the same card and can test my code posted earlier? Regards, David Johansson On Thu, Aug 14, 2008 at 6:02 PM, Jason Daly <[EMAIL PROTECTED]> wrote: > David Johansson wrote: >> >> Hi Robert, >> >> This does nothing i'm afraid. >> >> nvidia-xconfig --sli=Off followed by a restart of X.. >> > > Not sure if this helps or not, but you have to use the "multigpu" option > with the 7950GX2, not the "sli" option. "multigpu" is for SLI with two > GPU's on one card, while "sli" implies the two GPU's are on separate cards. > For some reason, there's a difference (check > /usr/share/doc/NVIDIA_GLX-1.0/README.txt for details). > > --"J" > > ___ > 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] pick on specific subgraph / nodepath
Hi Robert, let me sum it up shortly then: I'm trying to do some picking only in a specific subgraph, using the version of "computeIntersections" which include a nodepath option. To test it, I modified the osgpick example (attached) to pick, for instance, only the rectangles in the HUD. What I do is: - store the root of the HUD in a pHudRootNode - pick with the funtion: viewer->computeIntersections(ea.getX(), ea.getY(), pHudRootNode->getParentalNodePaths()[0], intersections) but I don't get any result. Gordon kindly replied that maybe the traversal just traverses a node, and not the whole path. Instead, checking the source code, it seems that after using the nodepath to unproject the 2D coordinates, the visit is called like this: ... osgUtil::IntersectionVisitor iv(picker); nodePath.back()->accept(iv); so I expected it to start visiting from the last node of the nodepath downwards into its subgraph. Here back to the original question: could you please just confirm the this is the way the function is meant to work?? If so, any idea on how to have my modified osgpick example to work? Thanks a lot, Ricky -Original Message- From: [EMAIL PROTECTED] on behalf of Robert Osfield Sent: Thu 14/08/2008 18.11 To: OpenSceneGraph Users Cc: Subject:Re: [osg-users] pick on specific subgraph / nodepath On Thu, Aug 14, 2008 at 4:25 PM, Riccardo Corsi <[EMAIL PROTECTED]> wrote: > Hi Robert, > > could you please just confirm the this is the way the function is meant to > work?? > If so, any idea on how to have my modified osgpick example to work? Can't confirm "this" as really don't know what "this" might be specifically referring to. I'm rather out of the loop on this thread having been away so diving in mid flow is not something I'm about to do. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org osgpick.cpp Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LineSegmentIntersector does not work with Billboards
Hi Judd,
Could you post your ammendments to osg-submissions.
Cheers,
Robert.
On Thu, Aug 14, 2008 at 5:11 PM, Judd Tracy <[EMAIL PROTECTED]> wrote:
> Robert
>
> I have added a method called set (did not know what to call it) that allows
> you to set the start and end points for the LinSegmentIntersector using the
> CooridnateFrame and the x, y values like one of the constructors does. It
> just makes it easier to reset the start and end points without having to
> know which values to use depending on the CoordinateFrame.
>
> Judd
>
> Robert Osfield wrote:
>>
>> Hi Judd,
>>
>> I have done some work on osgUtil::IntersectionVisitor to add proper
>> support for Billboards. Could you try out the attached
>> IntersectionVisitor header/source files and let me know how you get
>> on. This builds against OSG-2.6/OSG-SVN, but might also compile
>> against 2.4.
>>
>> In my own testing 'osgpick lz.osg' now works fine, whereas before this
>> fix it failed to pick the billboarded trees.
>>
>> Robert.
>>
>
>
> /* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
> *
> * This library is open source and may be redistributed and/or modified
> under
> * the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
> * (at your option) any later version. The full license is in LICENSE file
> * included with this distribution, and on the openscenegraph.org website.
> *
> * This library is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * OpenSceneGraph Public License for more details.
> */
>
>
> #include
>
> #include
> #include
> #include
> #include
>
> using namespace osgUtil;
>
> namespace LineSegmentIntersectorUtils
> {
>
>struct TriangleIntersection
>{
>TriangleIntersection(unsigned int index, const osg::Vec3& normal,
> float r1, const osg::Vec3* v1, float r2, const osg::Vec3* v2, float r3,
> const osg::Vec3* v3):
>_index(index),
>_normal(normal),
>_r1(r1),
>_v1(v1),
>_r2(r2),
>_v2(v2),
>_r3(r3),
>_v3(v3) {}
>
>unsigned int_index;
>const osg::Vec3 _normal;
>float _r1;
>const osg::Vec3*_v1;
>float _r2;
>const osg::Vec3*_v2;
>float _r3;
>const osg::Vec3*_v3;
>};
>
>typedef std::multimap TriangleIntersections;
>
>struct TriangleIntersector
>{
>osg::Vec3 _s;
>osg::Vec3 _d;
>float _length;
>
>int _index;
>float _ratio;
>bool_hit;
>
>TriangleIntersections _intersections;
>
>TriangleIntersector()
>{
>_length = 0.0f;
>_index = 0;
>_ratio = 0.0f;
>_hit = false;
>}
>
>void set(const osg::Vec3d& start, osg::Vec3d& end, float
> ratio=FLT_MAX)
>{
>_hit=false;
>_index = 0;
>_ratio = ratio;
>
>_s = start;
>_d = end - start;
>_length = _d.length();
>_d /= _length;
>}
>
>inline void operator () (const osg::Vec3& v1,const osg::Vec3&
> v2,const osg::Vec3& v3, bool treatVertexDataAsTemporary)
>{
>++_index;
>
>if (v1==v2 || v2==v3 || v1==v3) return;
>
>osg::Vec3 v12 = v2-v1;
>osg::Vec3 n12 = v12^_d;
>float ds12 = (_s-v1)*n12;
>float d312 = (v3-v1)*n12;
>if (d312>=0.0f)
>{
>if (ds12<0.0f) return;
>if (ds12>d312) return;
>}
>else // d312 < 0
>{
>if (ds12>0.0f) return;
>if (ds12}
>
>osg::Vec3 v23 = v3-v2;
>osg::Vec3 n23 = v23^_d;
>float ds23 = (_s-v2)*n23;
>float d123 = (v1-v2)*n23;
>if (d123>=0.0f)
>{
>if (ds23<0.0f) return;
>if (ds23>d123) return;
>}
>else // d123 < 0
>{
>if (ds23>0.0f) return;
>if (ds23}
>
>osg::Vec3 v31 = v1-v3;
>osg::Vec3 n31 = v31^_d;
>float ds31 = (_s-v3)*n31;
>float d231 = (v2-v3)*n31;
>if (d231>=0.0f)
>{
>if (ds31<0.0f) return;
>if (ds31>d231) return;
>}
>else // d231 < 0
>{
>if (ds31>0.0f) return;
>if (ds31}
>
>
>float r3;
>if (ds12==0.0f) r3=0.0f;
>else if (d312!=0.0f) r3 = ds12/d312;
>else return; // the triangle and the line must be para
[osg-users] osgdem performance...
I would like to get some feedback from users that might be rendering OSG terrain built with osgdem on Windows XP. Based on previous discussions, I understand that the terrain rendering on Windows does not have as good of performance as on Linux, however, I'm seeing abysmal frame rates when I'm rendering terrain on Windows. The paging performance is horrible. Perhaps it's the way I'm constructing my terrain or the setup in my OSG app.I'm not sure. While I don't understand the algorithm that is being used for OSG terrain, I would expect it to perform as good or somewhat close to other Windows based earth viewers such as NASA's WorldWind which seems to run just fine on Windows with large databases. For the record, here's the osgdem command I'm using to build the terrain. osgdem -TERRAIN -PagedLOD -geocentric -t dted -d texture -l 10 -o terrain/wasatch_utm.ive Any input on the matter would be appreciated. -Shayne smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem performance...
We have found that the paged database's performance is quite sensitive the settings used in the database pager. If you look at the pager, you can set a number of environment variables to tweak things. We were able to more than double our framerate and work around frame hiccups just by adjusting values. Windows doesn't seem to handle threads as well as linux, too, so if you only have once core/cpu, you'll have very bad paging behavior on windows, but not linux. A multi-core box seems to do much better. On Thursday 14 August 2008 01:07:00 pm Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote: > I would like to get some feedback from users that might be rendering OSG > terrain built with osgdem on Windows XP. Based on previous discussions, I > understand that the terrain rendering on Windows does not have as good of > performance as on Linux, however, I'm seeing abysmal frame rates when I'm > rendering terrain on Windows. The paging performance is horrible. Perhaps > it's the way I'm constructing my terrain or the setup in my OSG app.I'm not > sure. > > > > While I don't understand the algorithm that is being used for OSG terrain, > I would expect it to perform as good or somewhat close to other Windows > based earth viewers such as NASA's WorldWind which seems to run just fine > on Windows with large databases. > > > > For the record, here's the osgdem command I'm using to build the terrain. > > > > osgdem -TERRAIN -PagedLOD -geocentric -t dted -d texture -l 10 -o > terrain/wasatch_utm.ive > > > > Any input on the matter would be appreciated. > > -Shayne -- David Guthrie [EMAIL PROTECTED] Alion Science and Technology BMH Operation - A CMMI Maturity Level 3 Organization 5365 Robin Hood Road, Suite 100 Norfolk, VA 23513-2416 (757) 857-5670, ext 269, Fax (757) 857-6781 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer's turns up black when run fromdifferentthreads.
David Johansson wrote: Hi Jason, Setting multigpu did nothing either. You don't happen to have the same card and can test my code posted earlier? I can probably do that. I'm not sure when I'll get the time, but I should be able to find some this week. It might take a little while because I'm still on OSG 2.2 at the moment. --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Issues with Intel 945GM chipset and VBO's
Have you tried setting it to using display lists instead of vertex arrays? If they don't suit, then you may be able to figure out what card you are using, or make some sort of configuration check in an installer then set the environment variable? On Thursday 14 August 2008 10:42:42 am Jason Beverage wrote: > Hi all, > > I recently updated our product to use the --terrain flag in > VirtualPlanetBuilder to increase the speed of our database creation and > things are working wonderfully except for on the machines that have the > Intel 945GM chipset which are crashing. > > I've narrowed the problem down to the fact that the 945GM doesn't seem to > like using VBO, which is enabled in GeometryTechnique.cpp. If I revert > back to not using the --terrain option, which does not use VBO, things work > just fine. Also, if I set the environment variable > OSG_DATABASE_PAGER_DRAWABLE=VertexArrays, things also work just fine. > > I would like to not have to revert back to not using the --terrain option > since the performance increases on machines that support VBO are so > substantial but I also don't want specific users to have to modify the > environment variable. > > In theory, we can know whether or not VBO is supported by the graphics card > by using the State::isVertexBufferObjectSupported(), but the 945GM must be > incorrectly reporting that it does support VBO. > > Does anyone have any suggestions on what I should do in this situation? > > Thanks! > > Jason -- David Guthrie [EMAIL PROTECTED] Alion Science and Technology BMH Operation - A CMMI Maturity Level 3 Organization 5365 Robin Hood Road, Suite 100 Norfolk, VA 23513-2416 (757) 857-5670, ext 269, Fax (757) 857-6781 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] pick on specific subgraph / nodepath
Hi Riccardo. So to sum it up shortly. Just occassionally I suffer from the "good samaritan fatigue", today is one of those days. I'm tired, have plenty of my own work to get on with, and given you've already been shown a workable solution running the extra mile to go testing out your user code is beyond what I'm willing to do. I'm not paid to do this support you know. Robert. On Thu, Aug 14, 2008 at 5:49 PM, Riccardo Corsi <[EMAIL PROTECTED]> wrote: > Hi Robert, > let me sum it up shortly then: > > I'm trying to do some picking only in a specific subgraph, using the version > of "computeIntersections" which include a nodepath option. > > To test it, I modified the osgpick example (attached) to pick, for instance, > only the rectangles in the HUD. > What I do is: > - store the root of the HUD in a pHudRootNode > - pick with the funtion: > viewer->computeIntersections(ea.getX(), > ea.getY(), > pHudRootNode->getParentalNodePaths()[0], > intersections) > but I don't get any result. > > Gordon kindly replied that maybe the traversal just traverses a node, and not > the whole path. > Instead, checking the source code, it seems that after using the nodepath to > unproject the 2D coordinates, the visit is called like this: > > ... > osgUtil::IntersectionVisitor iv(picker); > nodePath.back()->accept(iv); > > so I expected it to start visiting from the last node of the nodepath > downwards into its subgraph. > > Here back to the original question: > could you please just confirm the this is the way the function is meant to > work?? > If so, any idea on how to have my modified osgpick example to work? > > Thanks a lot, > Ricky > > > > > -Original Message- > From: [EMAIL PROTECTED] on behalf of Robert Osfield > Sent: Thu 14/08/2008 18.11 > To: OpenSceneGraph Users > Cc: > Subject:Re: [osg-users] pick on specific subgraph / nodepath > > On Thu, Aug 14, 2008 at 4:25 PM, Riccardo Corsi <[EMAIL PROTECTED]> wrote: >> Hi Robert, >> >> could you please just confirm the this is the way the function is meant to >> work?? >> If so, any idea on how to have my modified osgpick example to work? > > Can't confirm "this" as really don't know what "this" might be > specifically referring to. I'm rather out of the loop on this thread > having been away so diving in mid flow is not something I'm about to > do. > > Robert. > ___ > 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] osgdem performance...
HI Shayne, Most modern machines regarless of OS should performance pretty well on osgdem generated databases. However, you must compile the OSG under release mode. Could this be the problem? Robert. On Thu, Aug 14, 2008 at 6:07 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC <[EMAIL PROTECTED]> wrote: > I would like to get some feedback from users that might be rendering OSG > terrain built with osgdem on Windows XP. Based on previous discussions, I > understand that the terrain rendering on Windows does not have as good of > performance as on Linux, however, I'm seeing abysmal frame rates when I'm > rendering terrain on Windows. The paging performance is horrible. Perhaps > it's the way I'm constructing my terrain or the setup in my OSG app…I'm not > sure. > > > > While I don't understand the algorithm that is being used for OSG terrain, I > would expect it to perform as good or somewhat close to other Windows based > earth viewers such as NASA's WorldWind which seems to run just fine on > Windows with large databases. > > > > For the record, here's the osgdem command I'm using to build the terrain… > > > > osgdem –TERRAIN –PagedLOD –geocentric –t dted –d texture –l 10 –o > terrain/wasatch_utm.ive > > > > Any input on the matter would be appreciated… > > -Shayne > > ___ > 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] osgdem performance...
We had similar issues with terrain recently. On windows it was single digit framerates and the same database on Linux was 30 fps but %100 on 2 cores. Rebuilding our terrain without the -terrain flag solved the issue. Framerates on windows jumped up to 30 fps, Linux to 60 fps with %30 on 1 core. We tried this with several databases and the ones without -terrain always performed better. Ken From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC Sent: Thursday, August 14, 2008 1:07 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] osgdem performance... I would like to get some feedback from users that might be rendering OSG terrain built with osgdem on Windows XP. Based on previous discussions, I understand that the terrain rendering on Windows does not have as good of performance as on Linux, however, I'm seeing abysmal frame rates when I'm rendering terrain on Windows. The paging performance is horrible. Perhaps it's the way I'm constructing my terrain or the setup in my OSG app...I'm not sure. While I don't understand the algorithm that is being used for OSG terrain, I would expect it to perform as good or somewhat close to other Windows based earth viewers such as NASA's WorldWind which seems to run just fine on Windows with large databases. For the record, here's the osgdem command I'm using to build the terrain... osgdem -TERRAIN -PagedLOD -geocentric -t dted -d texture -l 10 -o terrain/wasatch_utm.ive Any input on the matter would be appreciated... -Shayne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer's turns up black when run fromdifferentthreads.
David Johansson wrote: Hi Jason, Setting multigpu did nothing either. You don't happen to have the same card and can test my code posted earlier? Hi David, I gave it a quick try with OSG 2.2, and I'm definitely seeing problems. After I open the second viewer, if I alt-tab back to the first, I sometimes get a brief lock-up with the mouse pointer (I've seen this when running multiple OpenGL contexts before, even with something as simple as glxgears). More to the point, occasionally, the first window is black, and other times, I seem to get a residual display (as if the frame-buffer isn't fully cleared). Fyi, I'm running RHEL 5.2 with a 7950GX2 (SLI/MultiGPU disabled) with the 169.12 driver. --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Issues with Intel 945GM chipset and VBO's
hi David I set the environment variable to displaylists but still got a crash. I believe this is due to the fact that I was zoomed all the way out on the paged database which was still using vbo. Gotta love integrated graphics cards huh... Jason On 8/14/08, David Guthrie <[EMAIL PROTECTED]> wrote: > Have you tried setting it to using display lists instead of vertex arrays? > If > they don't suit, then you may be able to figure out what card you are using, > or make some sort of configuration check in an installer then set the > environment variable? > > On Thursday 14 August 2008 10:42:42 am Jason Beverage wrote: >> Hi all, >> >> I recently updated our product to use the --terrain flag in >> VirtualPlanetBuilder to increase the speed of our database creation and >> things are working wonderfully except for on the machines that have the >> Intel 945GM chipset which are crashing. >> >> I've narrowed the problem down to the fact that the 945GM doesn't seem to >> like using VBO, which is enabled in GeometryTechnique.cpp. If I revert >> back to not using the --terrain option, which does not use VBO, things >> work >> just fine. Also, if I set the environment variable >> OSG_DATABASE_PAGER_DRAWABLE=VertexArrays, things also work just fine. >> >> I would like to not have to revert back to not using the --terrain option >> since the performance increases on machines that support VBO are so >> substantial but I also don't want specific users to have to modify the >> environment variable. >> >> In theory, we can know whether or not VBO is supported by the graphics >> card >> by using the State::isVertexBufferObjectSupported(), but the 945GM must be >> incorrectly reporting that it does support VBO. >> >> Does anyone have any suggestions on what I should do in this situation? >> >> Thanks! >> >> Jason > > > -- > David Guthrie > [EMAIL PROTECTED] > Alion Science and Technology > BMH Operation - A CMMI Maturity Level 3 Organization > 5365 Robin Hood Road, Suite 100 > Norfolk, VA 23513-2416 > (757) 857-5670, ext 269, Fax (757) 857-6781 > ___ > 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's turns up black when run fromdifferentthreads.
Hi Jason, Robert I have tested 2.6 where it still seems to be a problem. There is no hurry with this, but it would be really nice to make sure that the problem is with the graphics card.. I'll probably try to build on WindowsXP64 later this week and see what happens, don't have the environment setup so that might take a few days. Robert, do you see any problem with the code i supplied? It seems that the behavior in my end is consistent. Everything works fine as long as you don't open any new windows after any has been closed. The reason for my initial suspection of GraphicsContext was mainly of the method GraphicsContext::getOrCreateCompileContext() I figured that when creating window1 it would get ContextID=1. Window2 would get ContextID=2. When closing Window1 the context would be released/freed or something. Then, when creating window3 it would reuse ContextID=1 which is dirty and unusable. Creating Window4 would get ContextID=3 (since 1 & 2 is in use) and work fine. However, this is just a very far fetched guess ( i have no idea whats going on behind the scenes). And i cant debug the code, haven't figured out how to get the .cpp files in eclipse without it building them. Regards, David Johansson On Thu, Aug 14, 2008 at 8:07 PM, Jason Daly <[EMAIL PROTECTED]> wrote: > David Johansson wrote: >> >> Hi Jason, >> >> Setting multigpu did nothing either. >> >> You don't happen to have the same card and can test my code posted >> earlier? >> > > Hi David, > > I gave it a quick try with OSG 2.2, and I'm definitely seeing problems. > After I open the second viewer, if I alt-tab back to the first, I sometimes > get a brief lock-up with the mouse pointer (I've seen this when running > multiple OpenGL contexts before, even with something as simple as glxgears). > More to the point, occasionally, the first window is black, and other > times, I seem to get a residual display (as if the frame-buffer isn't fully > cleared). > > Fyi, I'm running RHEL 5.2 with a 7950GX2 (SLI/MultiGPU disabled) with the > 169.12 driver. > > --"J" > > ___ > 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] [Junk released by Allow List] Re: Issues with Intel 945GM chipset and VBO's
That's odd. If you set it to use Display lists, it should override the settings on the database pager so that it only uses display lists, and not VBO's. Do you thing they are broken for the 945 too? On Thursday 14 August 2008 02:53:44 pm Jason Beverage wrote: > hi David > > I set the environment variable to displaylists but still got a crash. > I believe this is due to the fact that I was zoomed all the way out on > the paged database which was still using vbo. > > Gotta love integrated graphics cards huh... > > Jason > > On 8/14/08, David Guthrie <[EMAIL PROTECTED]> wrote: > > Have you tried setting it to using display lists instead of vertex > > arrays? If > > they don't suit, then you may be able to figure out what card you are > > using, or make some sort of configuration check in an installer then set > > the environment variable? > > > > On Thursday 14 August 2008 10:42:42 am Jason Beverage wrote: > >> Hi all, > >> > >> I recently updated our product to use the --terrain flag in > >> VirtualPlanetBuilder to increase the speed of our database creation and > >> things are working wonderfully except for on the machines that have the > >> Intel 945GM chipset which are crashing. > >> > >> I've narrowed the problem down to the fact that the 945GM doesn't seem > >> to like using VBO, which is enabled in GeometryTechnique.cpp. If I > >> revert back to not using the --terrain option, which does not use VBO, > >> things work > >> just fine. Also, if I set the environment variable > >> OSG_DATABASE_PAGER_DRAWABLE=VertexArrays, things also work just fine. > >> > >> I would like to not have to revert back to not using the --terrain > >> option since the performance increases on machines that support VBO are > >> so substantial but I also don't want specific users to have to modify > >> the environment variable. > >> > >> In theory, we can know whether or not VBO is supported by the graphics > >> card > >> by using the State::isVertexBufferObjectSupported(), but the 945GM must > >> be incorrectly reporting that it does support VBO. > >> > >> Does anyone have any suggestions on what I should do in this situation? > >> > >> Thanks! > >> > >> Jason > > > > -- > > David Guthrie > > [EMAIL PROTECTED] > > Alion Science and Technology > > BMH Operation - A CMMI Maturity Level 3 Organization > > 5365 Robin Hood Road, Suite 100 > > Norfolk, VA 23513-2416 > > (757) 857-5670, ext 269, Fax (757) 857-6781 > > ___ > > 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 -- David Guthrie [EMAIL PROTECTED] Alion Science and Technology BMH Operation - A CMMI Maturity Level 3 Organization 5365 Robin Hood Road, Suite 100 Norfolk, VA 23513-2416 (757) 857-5670, ext 269, Fax (757) 857-6781 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Junk released by Allow List] Re: Issues with Intel 945GM chipset and VBO's
My thought is that the override only applies to nodes that are "paged in". The root node of the scene is still using vbos as far as I understand since of doesn't have to be paged in. I'll take a look at the code tommorow morning at work, I'm currently driving and checking email. Only when I stop for breaks of course;) Jason On 8/14/08, David Guthrie <[EMAIL PROTECTED]> wrote: > That's odd. If you set it to use Display lists, it should override the > settings on the database pager so that it only uses display lists, and not > VBO's. Do you thing they are broken for the 945 too? > > On Thursday 14 August 2008 02:53:44 pm Jason Beverage wrote: >> hi David >> >> I set the environment variable to displaylists but still got a crash. >> I believe this is due to the fact that I was zoomed all the way out on >> the paged database which was still using vbo. >> >> Gotta love integrated graphics cards huh... >> >> Jason >> >> On 8/14/08, David Guthrie <[EMAIL PROTECTED]> wrote: >> > Have you tried setting it to using display lists instead of vertex >> > arrays? If >> > they don't suit, then you may be able to figure out what card you are >> > using, or make some sort of configuration check in an installer then set >> > the environment variable? >> > >> > On Thursday 14 August 2008 10:42:42 am Jason Beverage wrote: >> >> Hi all, >> >> >> >> I recently updated our product to use the --terrain flag in >> >> VirtualPlanetBuilder to increase the speed of our database creation and >> >> things are working wonderfully except for on the machines that have the >> >> Intel 945GM chipset which are crashing. >> >> >> >> I've narrowed the problem down to the fact that the 945GM doesn't seem >> >> to like using VBO, which is enabled in GeometryTechnique.cpp. If I >> >> revert back to not using the --terrain option, which does not use VBO, >> >> things work >> >> just fine. Also, if I set the environment variable >> >> OSG_DATABASE_PAGER_DRAWABLE=VertexArrays, things also work just fine. >> >> >> >> I would like to not have to revert back to not using the --terrain >> >> option since the performance increases on machines that support VBO are >> >> so substantial but I also don't want specific users to have to modify >> >> the environment variable. >> >> >> >> In theory, we can know whether or not VBO is supported by the graphics >> >> card >> >> by using the State::isVertexBufferObjectSupported(), but the 945GM must >> >> be incorrectly reporting that it does support VBO. >> >> >> >> Does anyone have any suggestions on what I should do in this situation? >> >> >> >> Thanks! >> >> >> >> Jason >> > >> > -- >> > David Guthrie >> > [EMAIL PROTECTED] >> > Alion Science and Technology >> > BMH Operation - A CMMI Maturity Level 3 Organization >> > 5365 Robin Hood Road, Suite 100 >> > Norfolk, VA 23513-2416 >> > (757) 857-5670, ext 269, Fax (757) 857-6781 >> > ___ >> > 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 > > > -- > David Guthrie > [EMAIL PROTECTED] > Alion Science and Technology > BMH Operation - A CMMI Maturity Level 3 Organization > 5365 Robin Hood Road, Suite 100 > Norfolk, VA 23513-2416 > (757) 857-5670, ext 269, Fax (757) 857-6781 > ___ > 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] osgdem performance...
Hi Shayne We too have had some problems with the terrain, but at the moment it seams to work fine. I have rearly seen any problems with osgviewer but in my actual application i have had studders etc. What sort of hardware are you using, I have a 40 gig 12 level database that renders perfectly on xp. But it seams that the threading scheme chosen on osgviewer makes a big difference on the timings that can be visualized in osgviewer as well. Cull pr. camera draw pr. context seams to work the best, but I guess that depends on the actual setup. At the moment we are not adding altitude data to the terrain, this has made a significant difference previously. Switching from a dual core to a quad core seamed to make a difference as well, on the dual core we were able to load both cores to 100% this does not happen on the quad? Hope some of this helps. Brgs. Ralf Stokholm Arenalogic 2008/8/14 Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC < [EMAIL PROTECTED]> > I would like to get some feedback from users that might be rendering OSG > terrain built with osgdem on Windows XP. Based on previous discussions, I > understand that the terrain rendering on Windows does not have as good of > performance as on Linux, however, I'm seeing abysmal frame rates when I'm > rendering terrain on Windows. The paging performance is horrible. Perhaps > it's the way I'm constructing my terrain or the setup in my OSG app…I'm not > sure. > > > > While I don't understand the algorithm that is being used for OSG terrain, > I would expect it to perform as good or somewhat close to other Windows > based earth viewers such as NASA's WorldWind which seems to run just fine on > Windows with large databases. > > > > For the record, here's the osgdem command I'm using to build the terrain… > > > > osgdem –TERRAIN –PagedLOD –geocentric –t dted –d texture –l 10 –o > terrain/wasatch_utm.ive > > > > Any input on the matter would be appreciated… > > -Shayne > > ___ > 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] pick on specific subgraph / nodepath
Hi Robert, well, the good samaritan took pity on his neighbour actually =) Joking aside, let me just state that I wasn't looking for custom support nor code analysis at all. Before posting I searched intensively through the list archive and the osg examples, but I saw no traces of the mentioned problem. And I provided the modified example just to follow what you normally suggest in the list: to send some code to reproduce an "unexpected" behaviour of some osg code, which might also be of interest for the community. That's it! I really didn't mean to waste your time and I'm sorry for the misunderstanding. Thanks anyway, Ricky -Original Message- From: [EMAIL PROTECTED] on behalf of Robert Osfield Sent: Thu 14/08/2008 19.53 To: OpenSceneGraph Users Cc: Subject:Re: [osg-users] pick on specific subgraph / nodepath Hi Riccardo. So to sum it up shortly. Just occassionally I suffer from the "good samaritan fatigue", today is one of those days. I'm tired, have plenty of my own work to get on with, and given you've already been shown a workable solution running the extra mile to go testing out your user code is beyond what I'm willing to do. I'm not paid to do this support you know. Robert. On Thu, Aug 14, 2008 at 5:49 PM, Riccardo Corsi <[EMAIL PROTECTED]> wrote: > Hi Robert, > let me sum it up shortly then: > > I'm trying to do some picking only in a specific subgraph, using the version > of "computeIntersections" which include a nodepath option. > > To test it, I modified the osgpick example (attached) to pick, for instance, > only the rectangles in the HUD. > What I do is: > - store the root of the HUD in a pHudRootNode > - pick with the funtion: > viewer->computeIntersections(ea.getX(), > ea.getY(), > pHudRootNode->getParentalNodePaths()[0], > intersections) > but I don't get any result. > > Gordon kindly replied that maybe the traversal just traverses a node, and not > the whole path. > Instead, checking the source code, it seems that after using the nodepath to > unproject the 2D coordinates, the visit is called like this: > > ... > osgUtil::IntersectionVisitor iv(picker); > nodePath.back()->accept(iv); > > so I expected it to start visiting from the last node of the nodepath > downwards into its subgraph. > > Here back to the original question: > could you please just confirm the this is the way the function is meant to > work?? > If so, any idea on how to have my modified osgpick example to work? > > Thanks a lot, > Ricky > > > > > -Original Message- > From: [EMAIL PROTECTED] on behalf of Robert Osfield > Sent: Thu 14/08/2008 18.11 > To: OpenSceneGraph Users > Cc: > Subject:Re: [osg-users] pick on specific subgraph / nodepath > > On Thu, Aug 14, 2008 at 4:25 PM, Riccardo Corsi <[EMAIL PROTECTED]> wrote: >> Hi Robert, >> >> could you please just confirm the this is the way the function is meant to >> work?? >> If so, any idea on how to have my modified osgpick example to work? > > Can't confirm "this" as really don't know what "this" might be > specifically referring to. I'm rather out of the loop on this thread > having been away so diving in mid flow is not something I'm about to > do. > > Robert. > ___ > 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
