-
- Downloads
Consider vtkCompositePolyDataMpper in GetMTime for batched polydata mapper
- closes vtk/vtk#19395 - without it, the batched polydata mappers would not update the buffers even when the composite data display attributes may have been modified due to a scalar visibility setting change. - the desktop mapper worked because it's `GetNeedToRebuildBufferObjects` indirectly compared the number of polydata in the current batch and previously rendered batch. This happened in `vtkStateStorage::operator !=()`. When the last block's scalar visibility was toggled from off to on, it recognized that the batch size has changed and uploaded the new batch of polydata. - the wasm mapper did not because it's `IsUptoDate` did not know about batch size and returned true even when the composite data display attributes were modified. - the fix could record the number of polydata in a batch and compare the number of polydata in `IsDataObjectUptoDate` with the last render. However, a better fix is to consider the MTime of the parent `vtkCompositePolyDataMapper` (that also considers the MTime of `vtkCompositeDataDisplayAttributes`) as the MTime concept was meant to fulfill this kind of state tracking need.
Showing
- Rendering/OpenGL2/vtkOpenGLBatchedPolyDataMapper.cxx 11 additions, 0 deletionsRendering/OpenGL2/vtkOpenGLBatchedPolyDataMapper.cxx
- Rendering/OpenGL2/vtkOpenGLBatchedPolyDataMapper.h 5 additions, 0 deletionsRendering/OpenGL2/vtkOpenGLBatchedPolyDataMapper.h
- Rendering/OpenGL2/vtkOpenGLLowMemoryBatchedPolyDataMapper.cxx 11 additions, 0 deletions...ering/OpenGL2/vtkOpenGLLowMemoryBatchedPolyDataMapper.cxx
- Rendering/OpenGL2/vtkOpenGLLowMemoryBatchedPolyDataMapper.h 5 additions, 0 deletionsRendering/OpenGL2/vtkOpenGLLowMemoryBatchedPolyDataMapper.h
Please register or sign in to comment