robertosfield wrote:
>
> The stack trace for OSG-3.2 suggests that removed View's Camera is still
> assigned to the Geometry context, and you change to setGraphicsContext(0)
> address this.
>
OK, I guess that ;)
robertosfield wrote:
>
> The CompositeViewer::removeView(..) should probably do
danoo wrote:
> Hi gambr
> I had similar issues when adding/removing views from composite viewer.
> Finally my crashes were solved by stopping and restarting Threading !
>
Thanks Daniel,
reading what Robert wrote and since adding a view to the viewer I set the
graphics context to the camera, fo
Hi Gianni,
The stack trace for OSG-3.2 suggests that removed View's Camera is still
assigned to the Geometry context, and you change to setGraphicsContext(0)
address this. The CompositeViewer::removeView(..) should probably do the
reset of the Camera so they are no longer assigned to GraphicsCont
Hi gambr
I had similar issues when adding/removing views from composite viewer. Finally
my crashes were solved by stopping and restarting Threading !
The code then looks like this:
Code:
// adding
m_Viewer.stopThreading();
m_Viewer.addView( a new view pointer );
m_View
Hi All,
in case this solution may be useful for others, I fixed the crash just setting
the graphics context of the removing view to 0:
view->getCamera()->setGraphicsContext(0);
I also tried to stop camera threads but I got a null OperationThread so that
would not help much.
Waiting for Robert'
Hi Robert,
one more question.
since in a particular case of my application a ref_ptr<> keeps alive the view
removed with compositeviewer->removeView(view), I get a crash in that case.
I'm building against osg-3.1.4 but I also tries with 3.2.0. And the crash
happens in both cases even if in diff
Hi Gianni,
On 4 December 2013 15:49, Gianni Ambrosio wrote:
> My last posted example was built against OSG-3.2.0. If your "x" includes
> "0", then I guess the problem is still there.
> Hope that example could help to reproduce the issue.
Oh well, it was a long shot.
Right now I need to focus
Hi Robert,
robertosfield wrote:
>
> If you aren't already using it it might be worth looking at OSG-3.2.x to see
> if that helps.
>
My last posted example was built against OSG-3.2.0. If your "x" includes "0",
then I guess the problem is still there.
Hope that example could help to reproduce
Hi Gianni,
I don't have answers for the specifics of your usage case, but I vaguely
recall discussing on osg-users the issue of adding and removing views but
retaining a ref_ptr<> to the removed views. I certainly applied fixes to
avoid problems but don't recall enough of the details if it matche
OK, it seems that there is something odd in osg code.
As found in another topic views that uses the same graphic context don't need
to be added to the compisite viewer at all but a simple instantiation make them
appear on the composite viewer: that seems counterintuitive.
Moreover the compositev
Here is the code:
Code:
class ViewerWidget : public osgQt::GLWidget, public osgViewer::CompositeViewer
{
Q_OBJECT
public:
ViewerWidget(QWidget* iParent = 0, const QGLWidget* iShareWidget = 0,
Qt::WindowFlags iFlags = 0)
: osgQt::GLWidget(iParent, iShareWidget, iFlags)
, timer(0)
Hi All,
OSG are fantastic but sometimes is frustrating to struggle with them.
I have a crash in my application when I remove a view from a CompositeViewer.
The crash happens when I move the mouse over the CompsiteViewer after removing
a view.
Basically at a certain point I call:
viewer->removeV
12 matches
Mail list logo
