The SceneView::init() does a traversal that compiles display lists and texture objects, it therefore must only be called from a thread with a valid graphics context.
Robert.
On 8/21/06, Gian Lorenzetto <[EMAIL PROTECTED]> wrote:
Hi Ryan,
Thanks for the info. Adding sceneview->init() his indeed has fixed the
problem.
From my trips through the debugger I know the problem lies in the
display list construction during the cull traversal, which is triggered
by the call to camera->accept(...).
By calling init() on sceneview BEFORE adding any objects to the scene
the camera->accept(...) is called early (in the init() method), with no
display list creation as there is no geometry!
I am using an NVidia card. Will try this out on an ATI later today and
confirm if the driver is indeed playing a part in all this.
Thanks for the help - thought I was going mad for a while! Good to know
there was a work-around for this.
Cheers,
Gian
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto: osg-users-
> [EMAIL PROTECTED]] On Behalf Of Kawicki, Ryan H
> Sent: Tuesday, 22 August 2006 12:44 AM
> To: osg users
> Subject: RE: [osg-users] Producer and Win32
>
> We had the same problem and this is what we did to correct the
problem.
> Actually, some of the machines that we ran on would produce the black
> screen while others would crash when trying to call glGenTextures. We
> tracked to problem down the Init function and display lists. If any
> drawable was using a display list, the problem would happen.
>
> What we did to correct the problem was this.
>
> Call the default and then call the init on the scene view and then
> attach any nodes to the scene.
> m_SceneView->setDefaults();
> m_SceneView->init();
>
> As for the reason this is happening. I am not quite sure. I can tell
> you that it only happened for us on our Nvidia based cards. Non of
the
> ATI cards we had was experiencing this same problem.
>
>
> Ryan Kawicki
> Software Engineer
> The Boeing Company
> Training Systems and Services
> (314) 777 - 6863
>
> -----Original Message-----
> From: J.P. Delport [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 21, 2006 2:02 AM
> To: osg users
> Subject: Re: [osg-users] Producer and Win32
>
> Hi Gian,
>
> I'm afraid I'm at a loss as what could be your problem and cannot
> reproduce it as I'm not using OSG 1.1.1 on win32 at the moment.
>
> I think it might be useful to create the simplest example of the
problem
> using GLUT. It might then be possible for more people to test it and
we
> might also learn if the problem is with wx or with Sceneview init.
>
> rgds
> jp
>
> Gian Lorenzetto wrote:
> > Hi,
> >
> > I've tried modifying the pixelbuffer, but still no joy.
> >
> > I've since taken the cube opengl sample from the wxWidgets 2.6.3
> distribution and converted it to load a model and use SceneView for
> rendering. Compiled against 1.0rc4 this works fine, with both models
> using display lists and models not using display lists.
> >
> > Compiled against 1.1.1rc1 models using display lists result in a
black
> screen.
> >
> > This is what my init looks like:
> >
> > SetCurrent();
> >
> > loadedModel = osgDB::readNodeFile("cow.osg");
> >
> > sceneView = new osgUtil::SceneView;
> >
> > sceneView->setDefaults();
> >
> > sceneView->setSceneData(loadedModel);
> >
> >
> > The render loop looks like:
> >
> > wxPaintDC dc(this);
> >
> > #ifndef __WXMOTIF__
> >
> > if (!GetContext()) return;
> >
> > #endif
> >
> > SetCurrent();
> >
> > // Init OpenGL once, but after SetCurrent
> >
> > if (!m_init)
> >
> > {
> >
> > InitGL();
> >
> > m_init = true;
> >
> > start_tick = osg::Timer::instance()->tick();
> >
> > }
> >
> > // set up the frame stamp for current frame to record the current
time
>
> > and frame number so that animtion code can advance correctly
> >
> > osg::ref_ptr<osg::FrameStamp> frameStamp = new osg::FrameStamp;
> >
> >
frameStamp->setReferenceTime(osg::Timer::instance()->delta_s(start_tic
> > frameStamp->k,osg::Timer::instance()->tick()));
> >
> > frameStamp->setFrameNumber(frameNum++);
> >
> > // pass frame stamp to the SceneView so that the update, cull and
draw
>
> > traversals all use the same FrameStamp
> >
> > sceneView->setFrameStamp(frameStamp.get());
> >
> > sceneView->setViewport(0, 0, width, height);
> >
> > const osg::BoundingSphere& bs = loadedModel->getBound();
> >
> > osg::Matrix viewMatrix;
> >
> >
viewMatrix.makeLookAt(bs.center()-osg::Vec3(0.0,2.0f*bs.radius(),0.0),
> > bs.center(),osg::Vec3(0.0f,0.0f,1.0f));
> >
> > sceneView->setViewMatrix(viewMatrix);
> >
> > // do the update traversal the scene graph - such as updating
> > animations
> >
> > sceneView->update();
> >
> > // do the cull traversal, collect all objects in the view frustum
into
>
> > a sorted set of rendering bins
> >
> > sceneView->cull();
> >
> > // draw the rendering bins.
> >
> > sceneView->draw();
> >
> > SwapBuffers();
> >
> > There's no other OSG code really.
> >
> > BTW Apologies for the formatting, but I'm using a web based email
> client and I can't seem to change the weird line spacing on the pasted
> code.
> >
> > Cheers,
> > Gian
> >
> > ________________________________
> >
> > From: [EMAIL PROTECTED] on behalf of J.P. Delport
> > Sent: Sat 19/08/2006 12:05 AM
> > To: osg users
> > Subject: Re: [osg-users] Producer and Win32
> >
> >
> >
> > Hi,
> >
> > I create my class derived from wxGLCanvas like so:
> >
> > // Canvas
> > int attribList[] = {WX_GL_RGBA, WX_GL_DOUBLEBUFFER,
> > WX_GL_DEPTH_SIZE, 32,
> > WX_GL_MIN_RED, 8,
> > WX_GL_MIN_GREEN, 8,
> > WX_GL_MIN_BLUE, 8,
> > WX_GL_MIN_ALPHA, 8,
> > WX_GL_AUX_BUFFERS, 1,
> > 0};
> >
> > m_CViewGLCanvas = new CViewGLCanvas(this,
> > -1,
> > wxPoint(0, 0),
> > wxSize(512, 512),
> > wxNO_BORDER,
> > wxT("CViewGLCanvas"),
> > attribList);
> >
> > jp
> >
> >
> > Gian Lorenzetto wrote:
> >> Tried rearranging a few things but to no avail ... one thing I did
> notice is that the default visual for wxGLCanvas is 16bit - do you
> change the pixel format at all?
> >>
> >> I'm also down to a pretty trivial example case, with only a single
> window, so it's got to be something with my class derived from
> wxGLCanvas or my build env ...
> >>
> >>
> >> -----Original Message-----
> >> From: [EMAIL PROTECTED] on behalf of J.P.
Delport
> >> Sent: Fri 8/18/2006 11:20 PM
> >> To: osg users
> >> Subject: Re: [osg-users] Producer and Win32
> >>
> >> Hi,
> >>
> >> according to grep, that is indeed the only place I call it. I am
only
>
> >> using a single context, so I'm not sure if the usage would change
for
>
> >> multiple contexts.
> >>
> >> rgds
> >> jp
> >>
> >> Gian Lorenzetto wrote:
> >>> Thanks for that. So is that the only time you call SetCurrent()?
I'm
> calling it in my render method (called from OnIdle), as well as before
> my initialisation code (which is actually not required now ...), but
not
> in the OnPaint handler.
> >>>
> >>> To be honest I never really worried too much about it as it has
> always worked, but perhaps I'm misusing SetCurrent in some way.
> >>>
> >>> -----Original Message-----
> >>> From: [EMAIL PROTECTED] on behalf of J.P.
Delport
> >>> Sent: Fri 8/18/2006 11:00 PM
> >>> To: osg users
> >>> Subject: Re: [osg-users] Producer and Win32
> >>>
> >>> Hi,
> >>>
> >>> my update/cull/draw is all inside onIdle.
> >>>
> >>> In onPaint there is only the following:
> >>>
> >>> --8<---
> >>> onPaint(wxPaintEvent& e)
> >>> {
> >>> wxPaintDC dc(this);
> >>>
> >>> #ifndef __WXMOTIF__
> >>> if (!GetContext()) return;
> >>> #endif
> >>>
> >>> SetCurrent();
> >>>
> >>> }
> >>> --8<---
> >>>
> >>> rgds
> >>> jp
> >>>
> >>> Gian Lorenzetto wrote:
> >>>> Hey,
> >>>>
> >>>> Hmm ... do you actually perform the update/call/draw inside the
> handler or request a paint event and then perform the draw there? I
ask
> because I don't really use the OnPaint handler for much, other than to
> create a wxPaintDC.
> >>>>
> >>>> I also had to make some updates due to osgGA changing and perhaps
> I've created some strange timing issue with the rendering ...
> >>>>
> >>
> >>
---------------------------------------------------------------------
> >> ---
> >>
> >> _______________________________________________
> >> osg-users mailing list
> >> [email protected]
> >> http://openscenegraph.net/mailman/listinfo/osg-users
> >> http://www.openscenegraph.org/
> >
> > --
> > This message is subject to the CSIR's copyright, terms and
conditions
> > and e-mail legal notice. Views expressed herein do not necessarily
> > represent the views of the CSIR.
> >
> > CSIR E-mail Legal Notice
> > http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html
> >
> > CSIR Copyright, Terms and Conditions
> > http://mail.csir.co.za/CSIR_Copyright.html
> >
> > For electronic copies of the CSIR Copyright, Terms and Conditions
and
> > the CSIR Legal Notice send a blank message with REQUEST LEGAL in the
> > subject line to [EMAIL PROTECTED].
> >
> >
> > This message has been scanned for viruses and dangerous content by
> > MailScanner, and is believed to be clean. MailScanner thanks
Transtec
> Computers for their support.
> >
> > _______________________________________________
> > osg-users mailing list
> > [email protected]
> > http://openscenegraph.net/mailman/listinfo/osg-users
> > http://www.openscenegraph.org/
> >
> >
> >
> >
> >
----------------------------------------------------------------------
> > --
> >
> > _______________________________________________
> > osg-users mailing list
> > [email protected]
> > http://openscenegraph.net/mailman/listinfo/osg-users
> > http://www.openscenegraph.org/
>
> --
> This message is subject to the CSIR's copyright, terms and conditions
> and e-mail legal notice. Views expressed herein do not necessarily
> represent the views of the CSIR.
>
> CSIR E-mail Legal Notice
> http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html
>
> CSIR Copyright, Terms and Conditions
> http://mail.csir.co.za/CSIR_Copyright.html
>
> For electronic copies of the CSIR Copyright, Terms and Conditions and
> the CSIR Legal Notice send a blank message with REQUEST LEGAL in the
> subject line to [EMAIL PROTECTED].
>
>
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean. MailScanner thanks Transtec
> Computers for their support.
>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
