[vtk-developers] VTK 5.0 Release status

Sander Niemeijer niemeijer at science-and-technology.nl
Fri Aug 12 07:15:47 EDT 2005


Is it then maybe possible to at least fix the vtkOpenGLPolyDataMapper2D 
and add the verts->lines->polys->strips order requirement to the 
documentation?

Best regards,
Sander

On vrijdag, aug 12, 2005, at 12:23 Europe/Amsterdam, Will Schroeder 
wrote:

> John is correct. This is a bad design than I take full credit for :-) 
> Although I agree that this needs fixing at some point, it really 
> requires a rewrite of vtkPolyData and I am not willing to deal with 
> such an effort at this point (it could take months to get all the side 
> effects out). BTW- There are compelling reasons for the rewrite 
> besides the aforementioned bug, including performance/memory concerns.
> Will
>
>
> At 05:57 AM 8/12/2005, John Biddiscombe wrote:
>
>>> - There is still an unsolved bug from me in the BugTracker system 
>>> about  'vtkPolyData + vtkCellData + multiple cell types'
>>> <http://vtk.org/Bug/bug.php?op=show&bugid=564>. Fixing this will most
>>> probably cause some form of backward incompatibility. I am afraid 
>>> that  if it won't be tackled in VTK 5, it will have to wait again 
>>> for VTK  6.0, which means the bug will probably  remain open for 
>>> several more  years. ;-)
>>
>> But everyone knows that you must add cells in 
>> verts->lines->Polys->Strips order for cell ids to match. You're 
>> adding them randomly. It's a feature that has always existed and 
>> whilst lots of possible fixes have been proposed, you are using the 
>> classes wrongly so it isn't a proper bug. More of an annoyance
>>
>> no?
>>
>> JB
>>
>>
>
>




More information about the vtk-developers mailing list