[vtkusers] Update issue in derived class of vtkOpenGLPolyDataMapper

[Rocco Gasteiger]

Hello everybody,

 

Only for your information. I have figured out what the problem has caused in
my derived mapper. I realized that VTK deletes display lists after a render
window is closed and creates them new if a new render window appears. The
deletion is performed in the ReleaseGraphicsResources-function and a reset
the last render window. Later it checks if render window has changed and
builds new display lists. However, I haven't called this function of the
basis class (vtkOpenGLPolyDataMapper) in my own mapper. So, now it works
fine.

 

Best regards, Rocco

 

Von: vtkusers-bounces at vtk.org [mailto:vtkusers-bounces at vtk.org] Im Auftrag
von Rocco Gasteiger
Gesendet: Mittwoch, 25. Mai 2011 23:09
An: vtkusers at vtk.org
Betreff: [vtkusers] Update issue in derived class of vtkOpenGLPolyDataMapper

 

Dear vtk-users,

 

I have derived a class "MyPolyDataMapper" from vtkOpenGLPolyDataMapper to
implement my own mapper behavior. However, I have noticed that after I
closed the vtkRenderWindow it can (!) happen that nothing is rendered. If I
simplified the method "RenderPiece(vtkRenderer * renderer, vtkActor *
actor)" to following function body:

 

void MyPolyDataMapper::RenderPiece( vtkRenderer * renderer, vtkActor * actor
)

{

   this->vtkOpenGLPolyDataMapper::RenderPiece( renderer, actor );

} 

 

Nevertheless, the behavior is the same. In that case, when I change, e.g.,
the poly data input. The rendering occurs. I think I didn't update the
mapper in an appropriate way. I have looked into the source code of
"vtkOpenGLPolyDataMapper" to get an clue of how to do that but I didn't
found something yet. So, can somebody give me an hint what the reason for
this behavior can be. Note, it doesn't appear every time I close and open
the vtkRenderWindow but sometimes.

 

Thanks in advance, Rocco

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20110529/f7d789c1/attachment.htm>