[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