VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2023-12-05T05:12:29-05:00https://gitlab.kitware.com/vtk/vtk/-/issues/18809vtkGLTFImporter related segfaults2023-12-05T05:12:29-05:00Mathieu Westphal (Kitware)vtkGLTFImporter related segfaults**Describe the bug**
Multiple specific GLTF files causes segfaults of F3D.
- [ ] [badArray.gltf.zip](https://github.com/f3d-app/f3d/files/10611258/badArray.gltf.zip)
<details>
<summary>Segfaults</summary>
```
f3d: /home/glow/dev/vtk...**Describe the bug**
Multiple specific GLTF files causes segfaults of F3D.
- [ ] [badArray.gltf.zip](https://github.com/f3d-app/f3d/files/10611258/badArray.gltf.zip)
<details>
<summary>Segfaults</summary>
```
f3d: /home/glow/dev/vtk/vtk1/src/ThirdParty/nlohmannjson/vtknlohmannjson/include/vtknlohmann/json.hpp:3928: const vtknlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer, BinaryType>::value_type& vtknlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer, BinaryType>::operator[](T*) const [with T = const char; ObjectType = std::map; ArrayType = std::vector; StringType = std::__cxx11::basic_string<char>; BooleanType = bool; NumberIntegerType = long int; NumberUnsignedType = long unsigned int; NumberFloatType = double; AllocatorType = std::allocator; JSONSerializer = vtknlohmann::adl_serializer; BinaryType = std::vector<unsigned char>; const_reference = const vtknlohmann::basic_json<>&]: Assertion `m_value.object->find(key) != m_value.object->end()' failed.
Program received signal SIGABRT, Aborted.
0x00007ffff78c164c in ?? () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff78c164c in ?? () from /usr/lib/libc.so.6
#1 0x00007ffff7871938 in raise () from /usr/lib/libc.so.6
#2 0x00007ffff785b53d in abort () from /usr/lib/libc.so.6
#3 0x00007ffff785b45c in ?? () from /usr/lib/libc.so.6
#4 0x00007ffff786a486 in __assert_fail () from /usr/lib/libc.so.6
#5 0x00007ffff54d6ff2 in vtknlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, vtknlohmann::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> > >::operator[]<char const>
(this=0x5555560453b0, key=0x7ffff551f9cd "attributes")
at /home/glow/dev/vtk/vtk1/src/ThirdParty/nlohmannjson/vtknlohmannjson/include/vtknlohmann/json.hpp:3928
#6 0x00007ffff54cd00b in vtkGLTFDocumentLoaderInternals::LoadPrimitive (this=0x7fffffffdf80, root=..., primitive=...)
at /home/glow/dev/vtk/vtk1/src/IO/Geometry/vtkGLTFDocumentLoaderInternals.cxx:1065
#7 0x00007ffff54ca516 in vtkGLTFDocumentLoaderInternals::LoadMesh (this=0x7fffffffdf80, root=..., mesh=...)
at /home/glow/dev/vtk/vtk1/src/IO/Geometry/vtkGLTFDocumentLoaderInternals.cxx:783
#8 0x00007ffff54d1f79 in vtkGLTFDocumentLoaderInternals::LoadModelMetaDataFromFile (this=0x7fffffffdf80,
fileName="/home/glow/aur/assimp/src/assimp-5.2.1/test/models/glTF2/wrongTypes/badArray.gltf", extensionsUsedByLoader=std::vector of length 0, capacity 0)
at /home/glow/dev/vtk/vtk1/src/IO/Geometry/vtkGLTFDocumentLoaderInternals.cxx:1403
#9 0x00007ffff533efae in vtkGLTFDocumentLoader::LoadModelMetaDataFromFile (this=0x5555560427e0,
fileName="/home/glow/aur/assimp/src/assimp-5.2.1/test/models/glTF2/wrongTypes/badArray.gltf")
at /home/glow/dev/vtk/vtk1/src/IO/Geometry/vtkGLTFDocumentLoader.cxx:177
#10 0x00007ffff55e455a in vtkGLTFImporter::ImportBegin (this=0x55555570cf10) at /home/glow/dev/vtk/vtk1/src/IO/Import/vtkGLTFImporter.cxx:397
#11 0x00007ffff55faa9f in vtkImporter::Read (this=0x55555570cf10) at /home/glow/dev/vtk/vtk1/src/IO/Import/vtkImporter.cxx:85
#12 0x00007ffff7ea2a22 in vtkImporter::Update (this=0x55555570cf10) at /home/glow/dev/vtk/vtk1/src/IO/Import/vtkImporter.h:92
#13 0x00007ffff7ea2543 in f3d::detail::loader_impl::loadFile (this=0x555555706050, load=f3d::loader::LoadFileEnum::LOAD_CURRENT)
at /home/glow/dev/f3d/f3d/src/library/src/loader_impl.cxx:379
#14 0x0000555555617d8d in F3DStarter::LoadFile (this=0x7fffffffe700, load=f3d::loader::LoadFileEnum::LOAD_CURRENT)
at /home/glow/dev/f3d/f3d/src/application/F3DStarter.cxx:357
#15 0x0000555555617038 in F3DStarter::Start (this=0x7fffffffe700, argc=3, argv=0x7fffffffe848) at /home/glow/dev/f3d/f3d/src/application/F3DStarter.cxx:202
#16 0x000055555561b4e9 in main (argc=3, argv=0x7fffffffe848) at /home/glow/dev/f3d/f3d/src/application/main.cxx:13
```
</details>
- [ ] [IndexOutOfRange.gltf.zip](https://github.com/f3d-app/f3d/files/10611322/IndexOutOfRange.gltf.zip)
<details>
<summary>Segfaults on quit/switch file</summary>
```
==516322== Invalid write of size 1
==516322== at 0xA6C53D9: vtkPolyData::ComputeCellsBounds() (vtkPolyData.cxx:519)
==516322== by 0xA6C54D3: vtkPolyData::GetCellsBounds(double*) (vtkPolyData.cxx:532)
==516322== by 0x648C4DF: vtkOpenGLPolyDataMapper::ComputeBounds() (vtkOpenGLPolyDataMapper.cxx:3596)
==516322== by 0x7AD15D1: vtkPolyDataMapper::GetBounds() (vtkPolyDataMapper.cxx:124)
==516322== by 0x7981432: vtkActor::GetBounds() (vtkActor.cxx:378)
==516322== by 0x7B2470E: vtkRenderer::ComputeVisiblePropBounds(double*) (vtkRenderer.cxx:987)
==516322== by 0x49B0D48: vtkF3DRenderer::SetupRenderPasses() (vtkF3DRenderer.cxx:232)
==516322== by 0x49B3E40: vtkF3DRenderer::ShowFilename(bool) (vtkF3DRenderer.cxx:837)
==516322== by 0x497D175: f3d::detail::window_impl::UpdateDynamicOptions() (window_impl.cxx:269)
==516322== by 0x496566E: f3d::detail::loader_impl::loadFile(f3d::loader::LoadFileEnum) (loader_impl.cxx:399)
==516322== by 0x1CBD8C: F3DStarter::LoadFile(f3d::loader::LoadFileEnum) (F3DStarter.cxx:357)
==516322== by 0x1CB037: F3DStarter::Start(int, char**) (F3DStarter.cxx:202)
==516322== Address 0x13e997ff is 159 bytes inside an unallocated block of size 318,704 in arena "client"
==516322==
Scene bounding box: -0.5,0.5,-0.5,0.5,-0.5,0.5
==516322== Invalid read of size 4
==516322== at 0x6453450: void (anonymous namespace)::AppendTrianglesWorker::operator()<float>(vtkAOSDataArrayTemplate<float>*) (vtkOpenGLIndexBufferObject.cxx:78)
==516322== by 0x64532D1: bool vtkArrayDispatch::impl::Dispatch<vtkTypeList::TypeList<vtkAOSDataArrayTemplate<float>, vtkTypeList::NullType> >::Execute<(anonymous namespace)::AppendTrianglesWorker&>(vtkDataArray*, (anonymous namespace)::AppendTrianglesWorker&) (vtkArrayDispatch.txx:64)
==516322== by 0x6452DDF: bool vtkArrayDispatch::impl::Dispatch<vtkTypeList::TypeList<vtkAOSDataArrayTemplate<double>, vtkTypeList::TypeList<vtkAOSDataArrayTemplate<float>, vtkTypeList::NullType> > >::Execute<(anonymous namespace)::AppendTrianglesWorker&>(vtkDataArray*, (anonymous namespace)::AppendTrianglesWorker&) (vtkArrayDispatch.txx:69)
==516322== by 0x6452A43: bool vtkArrayDispatch::DispatchByValueType<vtkTypeList::TypeList<double, vtkTypeList::TypeList<float, vtkTypeList::NullType> > >::Execute<(anonymous namespace)::AppendTrianglesWorker&>(vtkDataArray*, (anonymous namespace)::AppendTrianglesWorker&) (vtkArrayDispatch.txx:486)
==516322== by 0x645117F: vtkOpenGLIndexBufferObject::AppendTriangleIndexBuffer(std::vector<unsigned int, std::allocator<unsigned int> >&, vtkCellArray*, vtkPoints*, long long, std::vector<unsigned char, std::allocator<unsigned char> >*, vtkDataArray*) (vtkOpenGLIndexBufferObject.cxx:183)
==516322== by 0x645124E: vtkOpenGLIndexBufferObject::CreateTriangleIndexBuffer(vtkCellArray*, vtkPoints*, std::vector<unsigned char, std::allocator<unsigned char> >*, vtkDataArray*) (vtkOpenGLIndexBufferObject.cxx:202)
==516322== by 0x648EEFD: vtkOpenGLPolyDataMapper::BuildIBO(vtkRenderer*, vtkActor*, vtkPolyData*) (vtkOpenGLPolyDataMapper.cxx:4036)
==516322== by 0x648E049: vtkOpenGLPolyDataMapper::BuildBufferObjects(vtkRenderer*, vtkActor*) (vtkOpenGLPolyDataMapper.cxx:3931)
==516322== by 0x648C579: vtkOpenGLPolyDataMapper::UpdateBufferObjects(vtkRenderer*, vtkActor*) (vtkOpenGLPolyDataMapper.cxx:3605)
==516322== by 0x648B2FF: vtkOpenGLPolyDataMapper::RenderPieceStart(vtkRenderer*, vtkActor*) (vtkOpenGLPolyDataMapper.cxx:3331)
==516322== by 0x648C011: vtkOpenGLPolyDataMapper::RenderPiece(vtkRenderer*, vtkActor*) (vtkOpenGLPolyDataMapper.cxx:3547)
==516322== by 0x7AD12CC: vtkPolyDataMapper::Render(vtkRenderer*, vtkActor*) (vtkPolyDataMapper.cxx:66)
==516322== Invalid read of size 4
==516322== at 0x645351C: void (anonymous namespace)::AppendTrianglesWorker::operator()<float>(vtkAOSDataArrayTemplate<float>*) (vtkOpenGLIndexBufferObject.cxx:80)
==516322== by 0x64532D1: bool vtkArrayDispatch::impl::Dispatch<vtkTypeList::TypeList<vtkAOSDataArrayTemplate<float>, vtkTypeList::NullType> >::Execute<(anonymous namespace)::AppendTrianglesWorker&>(vtkDataArray*, (anonymous namespace)::AppendTrianglesWorker&) (vtkArrayDispatch.txx:64)
==516322== by 0x6452DDF: bool vtkArrayDispatch::impl::Dispatch<vtkTypeList::TypeList<vtkAOSDataArrayTemplate<double>, vtkTypeList::TypeList<vtkAOSDataArrayTemplate<float>, vtkTypeList::NullType> > >::Execute<(anonymous namespace)::AppendTrianglesWorker&>(vtkDataArray*, (anonymous namespace)::AppendTrianglesWorker&) (vtkArrayDispatch.txx:69)
==516322== by 0x6452A43: bool vtkArrayDispatch::DispatchByValueType<vtkTypeList::TypeList<double, vtkTypeList::TypeList<float, vtkTypeList::NullType> > >::Execute<(anonymous namespace)::AppendTrianglesWorker&>(vtkDataArray*, (anonymous namespace)::AppendTrianglesWorker&) (vtkArrayDispatch.txx:486)
==516322== by 0x645117F: vtkOpenGLIndexBufferObject::AppendTriangleIndexBuffer(std::vector<unsigned int, std::allocator<unsigned int> >&, vtkCellArray*, vtkPoints*, long long, std::vector<unsigned char, std::allocator<unsigned char> >*, vtkDataArray*) (vtkOpenGLIndexBufferObject.cxx:183)
==516322== by 0x645124E: vtkOpenGLIndexBufferObject::CreateTriangleIndexBuffer(vtkCellArray*, vtkPoints*, std::vector<unsigned char, std::allocator<unsigned char> >*, vtkDataArray*) (vtkOpenGLIndexBufferObject.cxx:202)
==516322== by 0x648EEFD: vtkOpenGLPolyDataMapper::BuildIBO(vtkRenderer*, vtkActor*, vtkPolyData*) (vtkOpenGLPolyDataMapper.cxx:4036)
==516322== by 0x648E049: vtkOpenGLPolyDataMapper::BuildBufferObjects(vtkRenderer*, vtkActor*) (vtkOpenGLPolyDataMapper.cxx:3931)
==516322== by 0x648C579: vtkOpenGLPolyDataMapper::UpdateBufferObjects(vtkRenderer*, vtkActor*) (vtkOpenGLPolyDataMapper.cxx:3605)
==516322== by 0x648B2FF: vtkOpenGLPolyDataMapper::RenderPieceStart(vtkRenderer*, vtkActor*) (vtkOpenGLPolyDataMapper.cxx:3331)
==516322== by 0x648C011: vtkOpenGLPolyDataMapper::RenderPiece(vtkRenderer*, vtkActor*) (vtkOpenGLPolyDataMapper.cxx:3547)
==516322== by 0x7AD12CC: vtkPolyDataMapper::Render(vtkRenderer*, vtkActor*) (vtkPolyDataMapper.cxx:66)
```
</details>
- [ ] [ShadowmappableMesh.glb.zip](https://github.com/f3d-app/f3d/files/11995211/ShadowmappableMesh.glb.zip)
<details>
<summary>Segfaults</summary>
```
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Program received signal SIGABRT, Aborted.
0x00007ffff789f26c in ?? () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff789f26c in ?? () from /usr/lib/libc.so.6
#1 0x00007ffff784fa08 in raise () from /usr/lib/libc.so.6
#2 0x00007ffff7838538 in abort () from /usr/lib/libc.so.6
#3 0x00007ffff7a9ca6f in __gnu_cxx::__verbose_terminate_handler () at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/vterminate.cc:95
#4 0x00007ffff7ab011c in __cxxabiv1::__terminate (handler=<optimized out>) at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:48
#5 0x00007ffff7ab0189 in std::terminate () at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:58
#6 0x00007ffff7ab03ed in __cxxabiv1::__cxa_throw (obj=<optimized out>, tinfo=0x7ffff7c6ab28 <typeinfo for std::bad_alloc>, dest=0x7ffff7aae680 <std::bad_alloc::~bad_alloc()>)
at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/eh_throw.cc:98
#7 0x00007ffff7a9c4f3 in operator new (sz=3348087199840816) at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/new_op.cc:54
#8 0x00007ffff589a0e6 in std::__new_allocator<double>::allocate (this=0x7fffffffd5d8, __n=418510899980102) at /usr/include/c++/13.1.1/bits/new_allocator.h:147
#9 0x00007ffff58975fb in std::allocator_traits<std::allocator<double> >::allocate (__n=418510899980102, __a=...) at /usr/include/c++/13.1.1/bits/alloc_traits.h:482
#10 std::_Vector_base<double, std::allocator<double> >::_M_allocate (this=0x7fffffffd5d8, __n=418510899980102) at /usr/include/c++/13.1.1/bits/stl_vector.h:378
#11 0x00007ffff58b84bd in std::_Vector_base<double, std::allocator<double> >::_M_create_storage (this=0x7fffffffd5d8, __n=418510899980102) at /usr/include/c++/13.1.1/bits/stl_vector.h:395
#12 0x00007ffff58b3919 in std::_Vector_base<double, std::allocator<double> >::_Vector_base (this=0x7fffffffd5d8, __n=418510899980102, __a=...) at /usr/include/c++/13.1.1/bits/stl_vector.h:332
#13 0x00007ffff58afa5b in std::vector<double, std::allocator<double> >::vector (this=0x7fffffffd5d8, __x=std::vector of length 418510899980102, capacity -614433100367020602 = {...})
at /usr/include/c++/13.1.1/bits/stl_vector.h:600
#14 0x00007ffff58ae910 in vtkGLTFDocumentLoader::Accessor::Accessor (this=0x7fffffffd5c0) at /home/glow/dev/vtk/vtk1/src/IO/Geometry/vtkGLTFDocumentLoader.h:134
#15 0x00007ffff58a37c3 in vtkGLTFDocumentLoader::ExtractPrimitiveAccessorData (this=0x555555fbf6d0, primitive=...) at /home/glow/dev/vtk/vtk1/src/IO/Geometry/vtkGLTFDocumentLoader.cxx:583
#16 0x00007ffff58a7511 in vtkGLTFDocumentLoader::LoadModelData (this=0x555555fbf6d0, glbBuffer=std::vector of length 379432, capacity 379432 = {...})
at /home/glow/dev/vtk/vtk1/src/IO/Geometry/vtkGLTFDocumentLoader.cxx:933
#17 0x00007ffff5c8299b in vtkGLTFImporter::ImportBegin (this=0x555555674a20) at /home/glow/dev/vtk/vtk1/src/IO/Import/vtkGLTFImporter.cxx:402
#18 0x00007ffff5c9896d in vtkImporter::Read (this=0x555555674a20) at /home/glow/dev/vtk/vtk1/src/IO/Import/vtkImporter.cxx:85
#19 0x00007ffff7f25217 in f3d::detail::loader_impl::loadScene(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
from /home/glow/dev/f3d/f3d/build/lib/libf3d.so.2
#20 0x00005555555c518f in F3DStarter::LoadFile(int, bool) ()
#21 0x00005555555c8900 in F3DStarter::Start(int, char**) ()
#22 0x0000555555570595 in main ()
```
</details>https://gitlab.kitware.com/vtk/vtk/-/issues/18808Valid PLY cannot be read2023-02-08T10:45:28-05:00Mathieu Westphal (Kitware)Valid PLY cannot be readA specific PLY file cannot be read
Steps to reproduce with ParaView:
- run ParaView,
- Open [Box.ply](/uploads/2ff8d1d65244e82792a5a9ab8031a892/Box.ply), Apply
```
( 7.566s) [paraview ] vtkPLYReader.cxx:195 WARN| vtkPL...A specific PLY file cannot be read
Steps to reproduce with ParaView:
- run ParaView,
- Open [Box.ply](/uploads/2ff8d1d65244e82792a5a9ab8031a892/Box.ply), Apply
```
( 7.566s) [paraview ] vtkPLYReader.cxx:195 WARN| vtkPLYReader (0x19934c30): Could not open PLY file
( 7.602s) [paraview ] vtkExecutive.cxx:741 ERR| vtkPVCompositeDataPipeline (0x1997fe20): Algorithm vtkFileSeriesReader (0x195d4980) returned failure for request: vtkInformation (0x195f8740)
Debug: Off
Modified Time: 463696
Reference Count: 1
Registered Events: (none)
Request: REQUEST_DATA
FROM_OUTPUT_PORT: 0
ALGORITHM_AFTER_FORWARD: 1
FORWARD_DIRECTION: 0
```
File is valid and can be opened with other tools.https://gitlab.kitware.com/vtk/vtk/-/issues/18802Data Assembly doxygen: wrong vtk version indicated2023-01-31T07:15:06-05:00Lucas GivordData Assembly doxygen: wrong vtk version indicatedThe doxygen page for `Data Assembly` indicate the wrong vtk version `vtk 10.0` instead of `vtk 9.1`?
https://vtk.org/doc/nightly/html/md__builds_gitlab_kitware_sciviz_ci_Documentation_Doxygen_DataAssembly.html
FYI @nicolas.vuailleThe doxygen page for `Data Assembly` indicate the wrong vtk version `vtk 10.0` instead of `vtk 9.1`?
https://vtk.org/doc/nightly/html/md__builds_gitlab_kitware_sciviz_ci_Documentation_Doxygen_DataAssembly.html
FYI @nicolas.vuaillehttps://gitlab.kitware.com/vtk/vtk/-/issues/18800VTK (Python) rendering artifacts2023-01-31T10:18:08-05:00Carlos SoutoVTK (Python) rendering artifacts# Minimal working example
Consider the following minimal working example:
```
RENDER_SELECTION = True
# mesh:
#
# (6) - (7) - (8)
# | 2 | 3 |
# (3) - (4) - (5)
# | 0 | 1 |
# (0) - (1) - (2)
#
pointCoordinates = (
(0.0, 0...# Minimal working example
Consider the following minimal working example:
```
RENDER_SELECTION = True
# mesh:
#
# (6) - (7) - (8)
# | 2 | 3 |
# (3) - (4) - (5)
# | 0 | 1 |
# (0) - (1) - (2)
#
pointCoordinates = (
(0.0, 0.0, 0.0),
(1.0, 0.0, 0.0),
(2.0, 0.0, 0.0),
(0.0, 1.0, 0.0),
(1.0, 1.0, 0.0),
(2.0, 1.0, 0.0),
(0.0, 2.0, 0.0),
(1.0, 2.0, 0.0),
(2.0, 2.0, 0.0)
)
cellConnectivity = (
(0, 1, 4, 3),
(1, 2, 5, 4),
(3, 4, 7, 6),
(4, 5, 8, 7)
)
selectedCells = (0, 3)
import vtkmodules.vtkRenderingOpenGL2 # type: ignore
import vtkmodules.vtkInteractionStyle # type: ignore
from vtkmodules.vtkCommonCore import vtkPoints, vtkIdTypeArray
from vtkmodules.vtkCommonDataModel import vtkUnstructuredGrid, vtkSelectionNode, vtkSelection, VTK_QUAD
from vtkmodules.vtkFiltersExtraction import vtkExtractSelection
from vtkmodules.vtkInteractionStyle import vtkInteractorStyleTrackballCamera
from vtkmodules.vtkRenderingCore import (
vtkDataSetMapper, vtkActor, vtkRenderer, vtkRenderWindow, vtkRenderWindowInteractor
)
# renderer
renderer = vtkRenderer()
# interactor & interactor style
interactorStyle = vtkInteractorStyleTrackballCamera()
interactor = vtkRenderWindowInteractor()
interactor.SetInteractorStyle(interactorStyle)
# render window
renderWindow = vtkRenderWindow()
renderWindow.AddRenderer(renderer)
renderWindow.SetInteractor(interactor)
# instantiate the data set object
dataSet = vtkUnstructuredGrid()
# set point coordinates
points = vtkPoints()
points.SetNumberOfPoints(len(pointCoordinates))
for i, coordinates in enumerate(pointCoordinates):
points.SetPoint(i, coordinates)
dataSet.SetPoints(points) # type: ignore
# set cell connectivity
dataSet.AllocateExact(len(cellConnectivity), 4)
for nodeIndices in cellConnectivity:
dataSet.InsertNextCell(VTK_QUAD, 4, nodeIndices) # type: ignore
dataSet.Squeeze()
# mapper
mapper = vtkDataSetMapper()
mapper.SetInputData(dataSet) # type: ignore
mapper.Update() # type: ignore
# actor
actor = vtkActor()
actor.SetMapper(mapper)
actor.GetProperty().EdgeVisibilityOn()
actor.GetProperty().SetColor(1.0, 1.0, 0.8)
renderer.AddActor(actor)
# add selection
if RENDER_SELECTION:
# indices
indices = vtkIdTypeArray()
indices.SetNumberOfValues(len(selectedCells))
for i, index in enumerate(selectedCells):
indices.SetValue(i, index)
# selection node
selectionNode = vtkSelectionNode()
selectionNode.SetFieldType(vtkSelectionNode.CELL)
selectionNode.SetContentType(vtkSelectionNode.INDICES)
selectionNode.SetSelectionList(indices) # type: ignore
# selection
selection = vtkSelection()
selection.AddNode(selectionNode)
# extraction filter
extractionFilter = vtkExtractSelection()
extractionFilter.SetInputData(0, dataSet) # type: ignore
extractionFilter.SetInputData(1, selection) # type: ignore
extractionFilter.Update() # type: ignore
# mapper
selectionMapper = vtkDataSetMapper()
selectionMapper.SetInputData(extractionFilter.GetOutput()) # type: ignore
selectionMapper.Update() # type: ignore
# actor
selectionActor = vtkActor()
selectionActor.SetMapper(selectionMapper)
selectionActor.GetProperty().SetColor(1.0, 0.0, 0.0)
# add to scene
renderer.AddActor(selectionActor)
# start the event loop
interactor.Initialize()
interactor.Start()
```
# The first issue
If I run this example in Python 3.11.1 with VTK 9.2.5 with `RENDER_SELECTION = False`, I get the following output:
![image](/uploads/4885b1c799c162b52e7e1bcc0d520789/image.png)
It is hard to see but I get these unwanted triangulation lines, I highlighted them in red for clarity:
![image](/uploads/de1733d2a648a00a45ccd04aa9f93c81/image.png)
# The second issue
If I run with `RENDER_SELECTION = True`, I get the following output:
![image](/uploads/a06a4551095ba5a64b0a26479ddc598c/image.png)
I expected the two red quads to be correctly painted red on selection.
**I can add that both these issues were not present in VTK via ActiViz (version 5.8.0).**https://gitlab.kitware.com/vtk/vtk/-/issues/18793Follow-up from "Add orphaned Python tests to CMakeLists.txt"2023-01-24T03:41:58-05:00Mathieu Westphal (Kitware)Follow-up from "Add orphaned Python tests to CMakeLists.txt"The following discussion from !9871 should be addressed:
- [ ] @dgobbi started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9871#note_1304186): (+1 comment)
> Contributed test needs extensive fixes.The following discussion from !9871 should be addressed:
- [ ] @dgobbi started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9871#note_1304186): (+1 comment)
> Contributed test needs extensive fixes.Mathieu Westphal (Kitware)Mathieu Westphal (Kitware)https://gitlab.kitware.com/vtk/vtk/-/issues/18792GLEW + Qt6: Build error if qtbase has been configured with FEATURE_opengles2 ...2023-01-24T03:47:58-05:00Alexander NeumannGLEW + Qt6: Build error if qtbase has been configured with FEATURE_opengles2 enabledSo I am trying to move VTK 9.2.0 from Qt5 to Qt6 in vcpkg and see the following build error in Linux CI:
```
[7179/9612] /usr/bin/c++ -DGLEW_STATIC -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_KEYWORDS -DQT_OPENGLWIDGETS_LIB -DQT_OPENGL_LIB -DQT_W...So I am trying to move VTK 9.2.0 from Qt5 to Qt6 in vcpkg and see the following build error in Linux CI:
```
[7179/9612] /usr/bin/c++ -DGLEW_STATIC -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_KEYWORDS -DQT_OPENGLWIDGETS_LIB -DQT_OPENGL_LIB -DQT_WIDGETS_LIB -Dkiss_fft_scalar=double -DvtkRenderingCore_AUTOINIT_INCLUDE=\"/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/CMakeFiles/vtkModuleAutoInit_be7301261a49b13d6a9b1d9e110eacd8.h\" -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/GUISupport/Qt/GUISupportQt_autogen/include -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/GUISupport/Qt -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/GUISupport/Qt -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Common/Core -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Common/Core -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Rendering/Core -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Rendering/Core -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Common/DataModel -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Common/DataModel -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Common/Math -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Common/Math -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/ThirdParty/kissfft/vtkkissfft -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/ThirdParty/kissfft/vtkkissfft -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Common/Transforms -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Common/Transforms -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Common/ExecutionModel -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Common/ExecutionModel -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Filters/Core -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Filters/Core -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Common/Misc -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Common/Misc -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Rendering/OpenGL2 -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Rendering/OpenGL2 -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Filters/General -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Filters/General -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/IO/Image -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/IO/Image -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Imaging/Core -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Imaging/Core -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Rendering/HyperTreeGrid -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Rendering/HyperTreeGrid -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Rendering/UI -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Rendering/UI -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Interaction/Widgets -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Interaction/Widgets -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Filters/Sources -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Filters/Sources -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Rendering/Context2D -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Rendering/Context2D -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Common/System -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Common/System -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Filters/Extraction -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Filters/Extraction -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Interaction/Style -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Interaction/Style -isystem /mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Utilities/KWIML -isystem /mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Utilities/KWIML -isystem /mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Utilities/KWSys -isystem /mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Utilities/KWSys -isystem /mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/ThirdParty/kissfft -isystem /mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/ThirdParty/kissfft -isystem /mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/ThirdParty/glew -isystem /mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/ThirdParty/glew -isystem /mnt/vcpkg-ci/installed/x64-linux/include -isystem /mnt/vcpkg-ci/installed/x64-linux/include/Qt6/QtOpenGL -isystem /mnt/vcpkg-ci/installed/x64-linux/include/Qt6 -isystem /mnt/vcpkg-ci/installed/x64-linux/include/Qt6/QtCore -isystem /mnt/vcpkg-ci/installed/x64-linux/share/Qt6/mkspecs/linux-g++ -isystem /mnt/vcpkg-ci/installed/x64-linux/include/Qt6/QtGui -isystem /mnt/vcpkg-ci/installed/x64-linux/include/Qt6/QtWidgets -isystem /mnt/vcpkg-ci/installed/x64-linux/include/Qt6/QtOpenGLWidgets -fPIC -g -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -ffunction-sections -fdata-sections -std=c++17 -MD -MT GUISupport/Qt/CMakeFiles/GUISupportQt.dir/vtkQWidgetTexture.cxx.o -MF GUISupport/Qt/CMakeFiles/GUISupportQt.dir/vtkQWidgetTexture.cxx.o.d -o GUISupport/Qt/CMakeFiles/GUISupportQt.dir/vtkQWidgetTexture.cxx.o -c /mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/GUISupport/Qt/vtkQWidgetTexture.cxx
FAILED: GUISupport/Qt/CMakeFiles/GUISupportQt.dir/vtkQWidgetTexture.cxx.o
/usr/bin/c++ -DGLEW_STATIC -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_KEYWORDS -DQT_OPENGLWIDGETS_LIB -DQT_OPENGL_LIB -DQT_WIDGETS_LIB -Dkiss_fft_scalar=double -DvtkRenderingCore_AUTOINIT_INCLUDE=\"/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/CMakeFiles/vtkModuleAutoInit_be7301261a49b13d6a9b1d9e110eacd8.h\" -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/GUISupport/Qt/GUISupportQt_autogen/include -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/GUISupport/Qt -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/GUISupport/Qt -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Common/Core -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Common/Core -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Rendering/Core -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Rendering/Core -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Common/DataModel -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Common/DataModel -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Common/Math -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Common/Math -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/ThirdParty/kissfft/vtkkissfft -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/ThirdParty/kissfft/vtkkissfft -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Common/Transforms -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Common/Transforms -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Common/ExecutionModel -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Common/ExecutionModel -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Filters/Core -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Filters/Core -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Common/Misc -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Common/Misc -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Rendering/OpenGL2 -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Rendering/OpenGL2 -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Filters/General -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Filters/General -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/IO/Image -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/IO/Image -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Imaging/Core -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Imaging/Core -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Rendering/HyperTreeGrid -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Rendering/HyperTreeGrid -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Rendering/UI -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Rendering/UI -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Interaction/Widgets -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Interaction/Widgets -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Filters/Sources -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Filters/Sources -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Rendering/Context2D -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Rendering/Context2D -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Common/System -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Common/System -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Filters/Extraction -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Filters/Extraction -I/mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Interaction/Style -I/mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Interaction/Style -isystem /mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Utilities/KWIML -isystem /mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Utilities/KWIML -isystem /mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Utilities/KWSys -isystem /mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/Utilities/KWSys -isystem /mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/ThirdParty/kissfft -isystem /mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/ThirdParty/kissfft -isystem /mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/ThirdParty/glew -isystem /mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/ThirdParty/glew -isystem /mnt/vcpkg-ci/installed/x64-linux/include -isystem /mnt/vcpkg-ci/installed/x64-linux/include/Qt6/QtOpenGL -isystem /mnt/vcpkg-ci/installed/x64-linux/include/Qt6 -isystem /mnt/vcpkg-ci/installed/x64-linux/include/Qt6/QtCore -isystem /mnt/vcpkg-ci/installed/x64-linux/share/Qt6/mkspecs/linux-g++ -isystem /mnt/vcpkg-ci/installed/x64-linux/include/Qt6/QtGui -isystem /mnt/vcpkg-ci/installed/x64-linux/include/Qt6/QtWidgets -isystem /mnt/vcpkg-ci/installed/x64-linux/include/Qt6/QtOpenGLWidgets -fPIC -g -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -ffunction-sections -fdata-sections -std=c++17 -MD -MT GUISupport/Qt/CMakeFiles/GUISupportQt.dir/vtkQWidgetTexture.cxx.o -MF GUISupport/Qt/CMakeFiles/GUISupportQt.dir/vtkQWidgetTexture.cxx.o.d -o GUISupport/Qt/CMakeFiles/GUISupportQt.dir/vtkQWidgetTexture.cxx.o -c /mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/GUISupport/Qt/vtkQWidgetTexture.cxx
In file included from /mnt/vcpkg-ci/installed/x64-linux/include/Qt6/QtOpenGL/qopenglpaintdevice.h:13,
from /mnt/vcpkg-ci/installed/x64-linux/include/Qt6/QtOpenGL/QOpenGLPaintDevice:1,
from /mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/GUISupport/Qt/vtkQWidgetTexture.cxx:25:
/mnt/vcpkg-ci/installed/x64-linux/include/Qt6/QtGui/qopenglcontext.h:21:2: warning: #warning qopenglfunctions.h is not compatible with GLEW, GLEW defines will be undefined [-Wcpp]
21 | #warning qopenglfunctions.h is not compatible with GLEW, GLEW defines will be undefined
| ^~~~~~~
/mnt/vcpkg-ci/installed/x64-linux/include/Qt6/QtGui/qopenglcontext.h:22:2: warning: #warning To use GLEW with Qt, do not include <qopengl.h> or <QOpenGLFunctions> after glew.h [-Wcpp]
22 | #warning To use GLEW with Qt, do not include <qopengl.h> or <QOpenGLFunctions> after glew.h
| ^~~~~~~
In file included from /mnt/vcpkg-ci/installed/x64-linux/include/Qt6/QtGui/qopengl.h:75,
from /mnt/vcpkg-ci/installed/x64-linux/include/Qt6/QtOpenGL/qopenglpaintdevice.h:12,
from /mnt/vcpkg-ci/installed/x64-linux/include/Qt6/QtOpenGL/QOpenGLPaintDevice:1,
from /mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/GUISupport/Qt/vtkQWidgetTexture.cxx:25:
/mnt/vcpkg-ci/installed/x64-linux/include/GLES2/gl2.h:507:60: error: ‘void __glewActiveTexture(GLenum)’ redeclared as different kind of entity
507 | GL_APICALL void GL_APIENTRY glActiveTexture (GLenum texture);
| ^
In file included from /mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/ThirdParty/glew/vtk_glew.h:42,
from /mnt/vcpkg-ci/buildtrees/vtk/x64-linux-dbg/Rendering/OpenGL2/vtkOpenGLError.h:19,
from /mnt/vcpkg-ci/buildtrees/vtk/src/67209150f8-fa9af939fa.clean/GUISupport/Qt/vtkQWidgetTexture.cxx:21:
/mnt/vcpkg-ci/installed/x64-linux/include/GL/glew.h:22286:40: note: previous declaration ‘void (* __glewActiveTexture)(GLenum)’
22286 | GLEW_FUN_EXPORT PFNGLACTIVETEXTUREPROC __glewActiveTexture;
| ^~~~~~~~~~~~~~~~~~~
```
(PR https://github.com/microsoft/vcpkg/pull/29078)
Another issues seems to be missing defines of `GL_BACK_LEFT` https://gitlab.kitware.com/vtk/vtk/-/blob/master/GUISupport/Qt/QVTKOpenGLWindow.cxx#L267 since nobody seems to pull in the required GL/gl.h header.
To see the error qtbase needs to be build with `-DFEATURE_opengles2=ON -DINPUT_opengl='es2' -DFEATURE_opengl_desktop=OFF`https://gitlab.kitware.com/vtk/vtk/-/issues/18790Slow rendering of .obj files with a material specified for each face, 10k faces2023-01-20T03:50:08-05:00outblasted .Slow rendering of .obj files with a material specified for each face, 10k facesHello,
While visualizing an .obj file using f3d - a 3d viewer app using vtk, I ran into slow rendering speeds for an mesh from an .obj file that had a material specified for each individual face. I've reported this to f3d maintainers, a...Hello,
While visualizing an .obj file using f3d - a 3d viewer app using vtk, I ran into slow rendering speeds for an mesh from an .obj file that had a material specified for each individual face. I've reported this to f3d maintainers, and the issue was traced down to vtk object importer.
Rendering an .obj file with ~10k faces and ~10k `usemtl` statements (1 for each face) gives 7-8 fps, while rendering the same .obj file with all `usemtl` statements removed results in 500-600fps. While there are ~10k usemtl statements, there are only 4 unique materials.
The .obj file in [test.obj](/uploads/d2a9465535bb0a0611b1f5b6b1f5dc17/test.obj)
I acknowledge that specifying `usemtl` for each face is excessive, and the .obj file could be optimized to workaround this problem.
vtk version: VTK version: 9.1.0 (build 0)
Some additional information:
I traced f3d with `apitrace`, and for an .obj with `usemtl` statements apitrace showed ~200,000 render calls per frame; without `usemtl`: ~150 render calls per frame.
Reference to an issue in f3d app with steps to reproduce: https://github.com/f3d-app/f3d/issues/570
Thank you.https://gitlab.kitware.com/vtk/vtk/-/issues/18789vtkGLTFExporter backside culling is incorrect2023-01-19T11:41:59-05:00Mathieu Westphal (Kitware)vtkGLTFExporter backside culling is incorrectWhen exporting a scene in glTF using ParaView (hence using the vtkGLTFExporter), the backside culling is enabled.
This happens if the property `doubleSided` is not set, which it should.
Steps to reproduced:
- run ParaView
- open [scen...When exporting a scene in glTF using ParaView (hence using the vtkGLTFExporter), the backside culling is enabled.
This happens if the property `doubleSided` is not set, which it should.
Steps to reproduced:
- run ParaView
- open [scene_0_0.vtp](/uploads/f9551c53a53670f2698df0be0135c998/scene_0_0.vtp), color with TEXCOORD
- File -> SaveScene -> scene.gltf
- resulting [scene.gltf](/uploads/d66af6f2318bfc8c751a7812895ba2b0/scene_pd.gltf) is not as expected
- Visualized with another tool (F3D):
![image](/uploads/8693b1ad504d66022ed7a0da4e0874e7/image.png)
- Expected visualization:
![image](/uploads/b99ad307d71610a18ade2e7aa53df818/image.png)https://gitlab.kitware.com/vtk/vtk/-/issues/18788Close the feature gap for OpenGL mappers between Desktop and WebAssembly envi...2023-10-16T15:21:24-04:00Jaswant Panchumarti (Kitware)Close the feature gap for OpenGL mappers between Desktop and WebAssembly environmentA VTK C++ application can be compiled with empscripten into a WASM binary. These instructions [Examples/Emscripten/Cxx/README.md](https://gitlab.kitware.com/vtk/vtk/-/blob/master/Examples/Emscripten/Cxx/README.md), though a little outdat...A VTK C++ application can be compiled with empscripten into a WASM binary. These instructions [Examples/Emscripten/Cxx/README.md](https://gitlab.kitware.com/vtk/vtk/-/blob/master/Examples/Emscripten/Cxx/README.md), though a little outdated, are known to work after tweaking the cmake configure flags.
Related discourse discussion
- [building-vtk-9-with-emscripten-gles-for-rendering](https://discourse.vtk.org/t/building-vtk-9-with-emscripten-gles-for-rendering/3038/9)
- [vtkScalarBarActor-in-webassembly](https://discourse.vtk.org/t/vtkscalarbaractor-in-webassembly/5078)
- [texture-buffers-dont-work-in-webgl](https://discourse.vtk.org/t/using-c-code-in-vtk-js/7271/7)
With a WASM-ified VTK, OpenGL rendering is very limited because of the constrained WebGL2 (OpenGL ES3.0) feature set. WebGL2 maps to GLES3.0. When this issue referes to GLES3.0, it addresses WebGL2 as well.
As most of the OpenGL VTK mappers were written with desktop OpenGL 3.2+ or OpenGL ES3.2 in mind, their shader programs simply refuse to compile in the browser. A simple C++ example that renders polydata with cell colors and a scalar bar will show lots of errors in the browser's developer console. It would be great to have the performance and feature set of VTK accessible on the web platform through WebAssembly. Here are the identified issues with using VTK C++ through WASM.
- [x] Color by cell data doesn't work.
- [x] Hardware selector cannot pick cells.
- [x] Cannot render a polydata with the "surface with edges" representation.
- [x] Line width adjustments have no effect. (triangles and strips represented as surface with edges)
- [x] Point size adjustments have no effect.
- [x] The vertex visibility setting has no effect (vtk/vtk#18703)
- [x] `vtkTextureObject::CreateTextureBuffer` doesn't work. Resolved in vtk/vtk!9866
- [x] 2D mappers do not render any geometry.
- [x] Line width adjustments have no effect (VTK_WIREFRAME and lines rendered as VTK_SURFACE) (https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10589)
- [x] Glyph mapper 3D
- [ ] Dual depth peeling
A good number of features rely on texture buffers and `gl_PrimitiveID`. Unfortunately, GLES3.0 does not support any of those. A workaround is to have alternate overrides of the classes in Rendering/Core.
Example: A `vtkOpenGLES30PolyDataMapper` subclasses `vtkOpenGLPolyDataMapper`, implements `ReplaceShader<Feature>()` and other important methods such that they are compliant with GLES3.0 spec. When VTK is built with `VTK_OPENGL_USE_GLES=ON`, the classes with GLES30 prefix are configured to override Rendering/Core classes instead. This approach can be done for `vtkOpenGLGlyph3DMapper`, `vtkOpenGLPolyDataMapper2D` and others. A benefit of this approach is that code duplication can be minimized, there is a clear distinction between the `GLES30`, `GL` mapper code and finally, the `GLES30` classes are still capable of implementing completely different rendering algorithms.
Once resolved, VTK will be more pleasant to use in WebAssembly - especially for rendering.Jaswant Panchumarti (Kitware)Jaswant Panchumarti (Kitware)https://gitlab.kitware.com/vtk/vtk/-/issues/18785vtkExtractEdges is improperly using INFO logs for DEBUG information2023-01-18T09:51:05-05:00Bane SullivanvtkExtractEdges is improperly using INFO logs for DEBUG informationSee
https://gitlab.kitware.com/vtk/vtk/-/blob/0d0edde06671166556ff47ecdd2270d5140b577b/Filters/Core/vtkExtractEdges.cxx#L338
https://gitlab.kitware.com/vtk/vtk/-/blob/0d0edde06671166556ff47ecdd2270d5140b577b/Filters/Core/vtkExtractEdg...See
https://gitlab.kitware.com/vtk/vtk/-/blob/0d0edde06671166556ff47ecdd2270d5140b577b/Filters/Core/vtkExtractEdges.cxx#L338
https://gitlab.kitware.com/vtk/vtk/-/blob/0d0edde06671166556ff47ecdd2270d5140b577b/Filters/Core/vtkExtractEdges.cxx#L399
https://gitlab.kitware.com/vtk/vtk/-/blob/0d0edde06671166556ff47ecdd2270d5140b577b/Filters/Core/vtkExtractEdges.cxx#L438
https://gitlab.kitware.com/vtk/vtk/-/blob/0d0edde06671166556ff47ecdd2270d5140b577b/Filters/Core/vtkExtractEdges.cxx#L554
These messages are displayed anytime the filter executes and often show up as warnings in many Python environments. These should be changed to TRACE level as that is more in line with the information they are conveying.
In Python, I have ignored these by `vtk.vtkLogger.SetStderrVerbosity(vtk.vtkLogger.VERBOSITY_OFF)`, but that then disables all logging for other scenarios where it is actually relevant.
cc @cory.quammen (as you had opinions on this offline)https://gitlab.kitware.com/vtk/vtk/-/issues/18783vtkImageCanvasSource2D::FillTriangle function can't Fill like (3, 3, 3, 50, 5...2023-01-18T10:30:44-05:00GODDOGvtkImageCanvasSource2D::FillTriangle function can't Fill like (3, 3, 3, 50, 50, 3)Code segment:
```cpp
vtkSmartPointer<vtkImageCanvasSource2D> canvas =
vtkSmartPointer<vtkImageCanvasSource2D>::New();
canvas->SetScalarTypeToUnsignedChar();
canvas->SetNumberOfScalarComponents(1);
canvas->SetExtent(0, 100, 0, 100, ...Code segment:
```cpp
vtkSmartPointer<vtkImageCanvasSource2D> canvas =
vtkSmartPointer<vtkImageCanvasSource2D>::New();
canvas->SetScalarTypeToUnsignedChar();
canvas->SetNumberOfScalarComponents(1);
canvas->SetExtent(0, 100, 0, 100, 0, 0);
canvas->SetDrawColor(255, 0, 0, 0);
canvas->FillTriangle(3, 3, 3, 50, 50, 3);
canvas->Update();
```
Screenshot for application:
![image](/uploads/3f9a9113ad6d363384ca804484e8042c/image.png)
my src version is 9.2.2.
I read the implementation of vtkImageCanvasSource2DFillTriangle. you sort process seems can't achieve the goal in comment:
```cpp
// Make life easier and order points so that ay < by < cy
if (c1 < a1)
{ // swap c and a
temp = a0;
a0 = c0;
c0 = temp;
temp = a1;
a1 = c1;
c1 = temp;
}
```
last code is in \VTK\VTK-9.2.2-src\Imaging\Sources\vtkImageCanvasSource2D.cxx's 482~491.
I don't know how to fix this. i just found this bug.https://gitlab.kitware.com/vtk/vtk/-/issues/18780vtkMetaImageWriter does not emit errors to observers2023-01-17T09:36:23-05:00Adrian SchillervtkMetaImageWriter does not emit errors to observersGiven a simple observer:
```c++
class VTKErrorObserver : public vtkCommand {
public:
VTKErrorObserver() : m_error(false), m_error_message("") {}
static VTKErrorObserver* New() {
return new VTKErrorObse...Given a simple observer:
```c++
class VTKErrorObserver : public vtkCommand {
public:
VTKErrorObserver() : m_error(false), m_error_message("") {}
static VTKErrorObserver* New() {
return new VTKErrorObserver;
}
bool GetError() const {
return this->m_error;
}
void Clear() {
this->m_error = false;
this->m_error_message = "";
}
virtual void Execute(vtkObject* vtkNotUsed(caller), unsigned long event, void* calldata) {
switch (event) {
case vtkCommand::ErrorEvent:
m_error_message = static_cast<char*>(calldata);
this->m_error = true;
break;
}
}
std::string GetErrorMessage() {
return m_error_message;
}
private:
bool m_error;
std::string m_error_message;
};
```
When attached to a `vtkMetaImageWriter` instance which encounters an error, the error is not emitted to the observer. By contrast, it works for `vtkImageWriter`. See the following example:
```c++
void file_system::MhdWriter::write(const std::string& file_location, vtkSmartPointer<vtkImageData> image_data) {
if (image_data == nullptr) {
throw InvalidParameter("image_data cannot be null");
}
vtkSmartPointer<VTKErrorObserver> observer = vtkSmartPointer<VTKErrorObserver>::New();
vtkNew<vtkMetaImageWriter> writer;
writer->AddObserver(vtkCommand::ErrorEvent, observer);
writer->SetCompression(true);
writer->SetInputData(image_data);
writer->SetFileName("/root/banana"); // <-- Causes permission denied error
writer->Write();
if (observer->GetError()) {
throw FileSystemException("vtkMetaImageWriter: An error occurred while attempting to write the image data to the file system: " + observer->GetErrorMessage(););
}
vtkSmartPointer<vtk_utils::VTKErrorObserver> image_observer = vtkSmartPointer<vtk_utils::VTKErrorObserver>::New();
vtkNew<vtkImageWriter> image_writer;
image_writer->AddObserver(vtkCommand::ErrorEvent, image_observer);
image_writer->SetInputData(image_data);
image_writer->SetFileName("/root/banana"); // <-- Causes permission denied error
image_writer->Write();
if (image_observer->GetError()) {
throw FileSystemException("vtkImageWriter: An error occurred while attempting to write the image data to the file system: " + image_observer->GetErrorMessage(););
}
}
```
When run, the `vtkMetaImageWriter` example does not throw an exception, whereas the `vtkImageWriter` does:
``` text
"vtkImageWriter: An error occurred while attempting to write the image data to the file system: ERROR: In [...]/Image/vtkImageWriter.cxx, line 318 vtkImageWriter (0x556e28f16140): RecursiveWrite: Could not open file /root/banana")
```
When checking for error codes, the after vtkMetaImageWriter section, the most recent error code returns a permission issue error:
```c++
vtkNew<vtkMetaImageWriter> writer;
writer->AddObserver(vtkCommand::ErrorEvent, observer);
writer->SetCompression(true);
writer->SetInputData(image_data);
writer->SetFileName("/root/banana"); // <-- Causes permission denied error
auto before = vtkErrorCode::GetLastSystemError();
writer->Write();
auto after = vtkErrorCode::GetLastSystemError();
LOG(WARNING) << "Before: " << before << ", " << "Message: " << vtkErrorCode::GetStringFromErrorCode(before);
LOG(WARNING) << "After: " << after << ", " << "Message: " << vtkErrorCode::GetStringFromErrorCode(after);
```
When run, it produces:
``` text
[WARN] [1673615384.266451088] [frontend]: Before: 2, Message: No such file or directory
[WARN] [1673615384.266485229] [frontend]: After: 13, Message: Permission denied
```
Suggesting an error occurs when `Write()` is called, but it is not emitted.https://gitlab.kitware.com/vtk/vtk/-/issues/18778vtk-exam ples/Cxx/StructuredGrid/BlankPoint get the wrong result.2023-01-19T02:41:20-05:00KKLT Jvtk-exam ples/Cxx/StructuredGrid/BlankPoint get the wrong result.I build vtk-exam ples/Cxx/StructuredGrid/BlankPoint with the following environment:
```
OS: win10
VTK: 9.2.2 static
BuildType:Relase
```
But I am getting the wrong result.`BlankPoint`is not effect.
![企业微信截图_20230113172032](/uploads/bfa9...I build vtk-exam ples/Cxx/StructuredGrid/BlankPoint with the following environment:
```
OS: win10
VTK: 9.2.2 static
BuildType:Relase
```
But I am getting the wrong result.`BlankPoint`is not effect.
![企业微信截图_20230113172032](/uploads/bfa975a99818901d0954f837f4ede9b4/企业微信截图_20230113172032.png)https://gitlab.kitware.com/vtk/vtk/-/issues/18776vtkAlgorithmOutput.GetProducer segfaults in Python when returned from differe...2023-01-11T18:03:25-05:00Bane SullivanvtkAlgorithmOutput.GetProducer segfaults in Python when returned from different scopeWhen using the output port, `vtkAlgorithmOutput`, of a an algorithm that was fetched from a different scope, segfaults occur. For example:
This works fine:
```py
import vtk
source = vtk.vtkRTAnalyticSource()
alg = vtk.vtkDataSetSurfac...When using the output port, `vtkAlgorithmOutput`, of a an algorithm that was fetched from a different scope, segfaults occur. For example:
This works fine:
```py
import vtk
source = vtk.vtkRTAnalyticSource()
alg = vtk.vtkDataSetSurfaceFilter()
alg.SetInputConnection(source.GetOutputPort())
output = alg.GetOutputPort()
output.GetProducer()
```
But if I put the filtering logic in a function and return the `vtkAlgorithmOutput`, then a segfault occurs when calling `GetProducer()` on the object:
```py
import vtk
def filter(inp):
alg = vtk.vtkDataSetSurfaceFilter()
alg.SetInputConnection(inp.GetOutputPort())
return alg.GetOutputPort()
source = vtk.vtkRTAnalyticSource()
output = filter(source)
output.GetProducer() # <- segfaults
```https://gitlab.kitware.com/vtk/vtk/-/issues/18775Test changes required for ABI namespacing2023-01-13T06:38:11-05:00David ThompsonTest changes required for ABI namespacingIf we ever add a CI build that test ABI namespacing, `Common/Core/Testing/Cxx/TestInherits` will need to be updated. Preferably, VTK should provide a `VTK_ABI_NAMESPACE_NAME` macro during compilation so it can be stringified and included...If we ever add a CI build that test ABI namespacing, `Common/Core/Testing/Cxx/TestInherits` will need to be updated. Preferably, VTK should provide a `VTK_ABI_NAMESPACE_NAME` macro during compilation so it can be stringified and included in the test.
See [this discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9499#note_1297741) on !9499 for details.Ryan Krattigerryan.krattiger@kitware.comRyan Krattigerryan.krattiger@kitware.comhttps://gitlab.kitware.com/vtk/vtk/-/issues/18772Python package for Linux ARM64 is missing2023-10-09T19:37:47-04:00dazzag24Python package for Linux ARM64 is missingHi,
I notice that while there is now support for MacosX on ARM64 (e.g M1 chipset) that there is no support for Linux on ARM64.
https://pypi.org/project/vtk/#files
Could this be added?
ThanksHi,
I notice that while there is now support for MacosX on ARM64 (e.g M1 chipset) that there is no support for Linux on ARM64.
https://pypi.org/project/vtk/#files
Could this be added?
Thankshttps://gitlab.kitware.com/vtk/vtk/-/issues/18770OpenXR: Positioning a prop that has a user transform makes the prop drift away2024-03-01T17:41:50-05:00Lucas GandelOpenXR: Positioning a prop that has a user transform makes the prop drift away**Steps to reproduce:**
In [TestOpenXRRemotingInitialization.cxx](https://gitlab.kitware.com/vtk/vtk/-/blob/master/Rendering/OpenXRRemoting/Testing/Cxx/TestOpenXRRemotingInitialization.cxx), apply a user transform to the actor using the...**Steps to reproduce:**
In [TestOpenXRRemotingInitialization.cxx](https://gitlab.kitware.com/vtk/vtk/-/blob/master/Rendering/OpenXRRemoting/Testing/Cxx/TestOpenXRRemotingInitialization.cxx), apply a user transform to the actor using the following:
```
vtkNew<vtkTransform> t;
t->Translate(0, 0, 1);
srcActor->SetUserTransform(t);
```
**Expected behavior:**
The actor can be grabbed by the controller and stays at the tip of the controller ray when moving it around
**Observed behavior:**
The actor flies away as soon as it is grabbed.
Using `srcActor->SetPosition(0, 0, 1);` gives the expected behavior.
This was experienced with OpenXR remoting, but is probably true for OpenVR and OpenXR too.https://gitlab.kitware.com/vtk/vtk/-/issues/18760vtkHDFReader "Unknown data set type: ��O"2024-02-14T09:43:20-05:00Junghyeon ParkvtkHDFReader "Unknown data set type: ��O"When opening VTKHDF in ParaView 5.11.0, I encounter an error.
```
ERROR: In vtkHDFReaderImplementation.cxx, line 292
vtkHDFReader (0x1edd63e0): Unknown data set type: ��O
```
The file I created and tried to open is
[example.hdf](/upload...When opening VTKHDF in ParaView 5.11.0, I encounter an error.
```
ERROR: In vtkHDFReaderImplementation.cxx, line 292
vtkHDFReader (0x1edd63e0): Unknown data set type: ��O
```
The file I created and tried to open is
[example.hdf](/uploads/8e504853973a935316fc3092b56231c6/example.hdf).
Note that it has correct "Type" attribute (h5dump appended at the end of the comment).
After research, I'm convinced that `H5Aread` demands `char**` not `char*` for the `buf` parameter when reading string.
A simple modification indeed resolved the issue for me.
https://gitlab.kitware.com/j824h/vtk/-/commit/d6b7e4a238ee2257f14b573dc63b43eaf64121ad
Can anyone (maybe @francois.mazen ?) look into this?
```
HDF5 "example.hdf" {
GROUP "/" {
GROUP "VTKHDF" {
ATTRIBUTE "Type" {
DATATYPE H5T_STRING {
STRSIZE H5T_VARIABLE;
STRPAD H5T_STR_NULLTERM;
CSET H5T_CSET_ASCII;
CTYPE H5T_C_S1;
}
DATASPACE SCALAR
DATA {
(0): "UnstructuredGrid"
}
}
ATTRIBUTE "Version" {
DATATYPE H5T_STD_I64LE
DATASPACE SIMPLE { ( 2 ) / ( 2 ) }
DATA {
(0): 1, 0
}
}
DATASET "Connectivity" {
DATATYPE H5T_STD_I64LE
DATASPACE SIMPLE { ( 1 ) / ( 1 ) }
DATA {
(0): 0
}
}
DATASET "NumberOfCells" {
DATATYPE H5T_STD_I64LE
DATASPACE SIMPLE { ( 1 ) / ( 1 ) }
DATA {
(0): 1
}
}
DATASET "NumberOfConnectivityIds" {
DATATYPE H5T_STD_I64LE
DATASPACE SIMPLE { ( 1 ) / ( 1 ) }
DATA {
(0): 1
}
}
DATASET "NumberOfPoints" {
DATATYPE H5T_STD_I64LE
DATASPACE SIMPLE { ( 1 ) / ( 1 ) }
DATA {
(0): 1
}
}
DATASET "Offsets" {
DATATYPE H5T_STD_I64LE
DATASPACE SIMPLE { ( 2 ) / ( 2 ) }
DATA {
(0): 0, 1
}
}
DATASET "Points" {
DATATYPE H5T_IEEE_F64LE
DATASPACE SIMPLE { ( 1, 3 ) / ( 1, 3 ) }
DATA {
(0,0): 1, 2, 3
}
}
DATASET "Types" {
DATATYPE H5T_STD_U8LE
DATASPACE SIMPLE { ( 1 ) / ( 1 ) }
DATA {
(0): 1
}
}
}
}
}
```https://gitlab.kitware.com/vtk/vtk/-/issues/18751Revisit current wheel sdk archive to be distributed as a wheel named `vtk-sdk`2022-12-16T18:21:36-05:00Jean-Christophe Fillion-RobinRevisit current wheel sdk archive to be distributed as a wheel named `vtk-sdk`Following the 2nd scikit-build community meeting[^1], we discussed naming convention for wheel distributing _SDK_ and associated `<package>-config.cmake` file.
As a first step toward reducing the complexity for retrieving the VTK wheel ...Following the 2nd scikit-build community meeting[^1], we discussed naming convention for wheel distributing _SDK_ and associated `<package>-config.cmake` file.
As a first step toward reducing the complexity for retrieving the VTK wheel sdk that is being duplicated [^2][^3], the plan is to revisit the wheel SDK archive [^4] and distribute them as valid wheels.
To ensure that project depending on the `vtk-sdk` wheel can effectively be built by finding VTK, an entry point specific to `sckit-build-core` back-end will be declared. This will ensure that the `CMAKE_PREFIX_PATH` (or `VTK_DIR`) variable is set.
Distribution of the SDK wheels will either be done through PyPI or through PyPI server maintainer by Kitware.
[^1]: https://github.com/scikit-build/scikit-build/discussions/825
[^2]: https://github.com/Kitware/LookingGlassVTKModule/blob/78cc2cec9b6d9d50307c99183a4dbcd02ebe27b1/setup.py#L14-L78
[^3]: https://github.com/Slicer/vtkAddon/blob/38c95af858639ea6bcfcfd81f1dcc7f6e880a0fe/setup.py#L14-L78
[^4]: https://vtk.org/files/wheel-sdks/Jean-Christophe Fillion-RobinJean-Christophe Fillion-Robinhttps://gitlab.kitware.com/vtk/vtk/-/issues/18750vtk wheel: vendored proj does not work because the database is not included2022-12-16T19:22:02-05:00Ben Boeckelvtk wheel: vendored proj does not work because the database is not includedSo VTK's wheels contain `libproj` but not in a way that works because its `proj.db` is not in the wheel itself. Alas, Python packaging intersecting VTK's build system is a nightmare and I was able to get it into the wheel by abusing Pyth...So VTK's wheels contain `libproj` but not in a way that works because its `proj.db` is not in the wheel itself. Alas, Python packaging intersecting VTK's build system is a nightmare and I was able to get it into the wheel by abusing Python's duck typing and just path-traversing in `package_data`, but not in a way that `pip install` liked on install (why does `bdist_wheel` not error on the creation side? who knows):
```
ERROR: For req: vtk==9.2.20221216.dev0. Unknown scheme key used in /home/boeckb/misc/builds/vtk/build-whl/dist/vtk-9.2.20221216.dev0-cp311-cp311-linux_x86_64.whl: share (for file 'vtk-9.2.20221216.data/share/vtk/proj/proj.db'). .data directory contents should be in subdirectories named with a valid scheme key (data, headers, platlib, purelib, scripts)
```
So the wheel build needs to update how the database is placed into the build tree in `ThirdParty/libproj/vtklibproj/data/CMakeLists.txt` and get it into the wheel with whatever `setuptools` wants in `CMake/setup.py.in`.
Cc: @jcfr @banesullivan @dgobbi @danlipsa