(i use qt 4.4.1 and osg 2.6, and adapted vierwerqt example sources)
The QOSGWidget works for me on linux.
On windows I got the pixelformat error but,
I got the QOSGWidget to work, and the --CompositeViewer version, by adding
the traits->setInheritedWindowPixelFormat = true; line.
I don't see any problems running a second time or multiple times.
I don't have any windows decorations by default, but these can also be set
on.
(it helps to set
viewerWindow->setGeometry(50,50,640,480); instead of
viewerWindow->setGeometry(0,0,640,480);)
to prevent the decorations from being outside the screen.
)
I did have problems when making the window heigth 0, but this was solved by
making the resize always a minumum of one pixel.
But i do get some errors in the console:
QWidget::repaint: Recursive repaint detected
and after closing:
Windows Error #6: [Screen #0]
GraphicsWindowWin32::makeCurrentImplementation() - Unable to set current
OpenGL rendering context. Reason: De ingang is ongeldig.
Windows Error #1400: [Screen #0]
GraphicsWindowWin32::unregisterWindowProcedure() - Unable to unregister
window procedure. Reason: Ongeldige vensteringang.
I am still not sure what solution to use, as the ViewerQT version does its
job, never had window problems with the AdapterWidget, but the performance
of the QOSGWidget seems better.
I also use a qtimer that triggers the update, but I want to start a new
(singleshot) timer only after the frame is drawn, to make sure every frame
is drawn before the timer issues a new frame. Large models seemed to have a
problem with the original code. would there be a better solution for the
update?
Rene Molenaar
2008/5/7 Mathieu Champlon <[EMAIL PROTECTED]>
> Hi Robert,
>
> I quickly hacked the --QOSGWidget mode in order to work around the "invalid
> pixel format" error (forcing traits->setInheritedWindowPixelFormat = true;)
> and the result is the same : trashed scene on the second run.
> I tried adding the piece of code you suggested but it does not change
> anything.
>
> By the way the crash you were experiencing running with --QOSGWidget is
> actually due to osg::ArgumentParser modifying argv, thus on the second run
> argc remains unchanged but all arguments have actually been eaten up from
> argv.
> I am now using this code to run the application twice :
> int main( int argc, char **argv )
> {
> char** tmp = (char**)malloc( argc * sizeof( char*) );
> memcpy( tmp, argv, argc * sizeof( char* ) );
> run( argc, argv );
> run( argc, tmp );
> }
>
> MAT.
>
>
> Robert Osfield wrote:
>
>> Hi Mathieu,
>>
>> The error with -QOSGWidget looks to be a bug in this code, but its a
>> totally different path that the default path which uses
>> GraphicsWindowEmbedded to adapt the Viewer. QOSGWidget is the most
>> flexible path for integration and long term I'd like this to be the
>> default route under Qt. My own time is rather stretched out so I
>> can't address all these things at once.
>>
>> The issues you are seeing with the default path is very unlikely to be
>> related to transparency, most likely is issues with display lists or
>> texture objects being reused inappropriately. In theory the viewer
>> should be release OpenGL objects when the context is destroyed, but
>> with GraphicsWindowEmbedded not all the standard functionality for
>> managing OpenGL objects is available, so perhaps this step is not
>> being executed appropriately.
>>
>> One thing you could try is a
>>
>> viewer->getSceneData()->releaseGLObjects();
>> osg::GLObjects::discardAllDeletedGLObjects(0);
>>
>> In between the viewer allocations.
>>
>> Robert.
>>
>>
>
>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
