VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2021-01-23T00:30:52-05:00https://gitlab.kitware.com/vtk/vtk/-/issues/18086VTK9.0.1+pyqt5 on TX2 cannot initialize2021-01-23T00:30:52-05:00Daizheng-zVTK9.0.1+pyqt5 on TX2 cannot initializeI can run my code correctly on the pc(ubuntu18.04+i5+gtx1060), but it cannot be displayed when deployed on tx2. The error message is “ERR| vtkXOpenGLRenderWindow (0x198ce420): GLEW could not be initialized: Missing GL version”
vtk is in...I can run my code correctly on the pc(ubuntu18.04+i5+gtx1060), but it cannot be displayed when deployed on tx2. The error message is “ERR| vtkXOpenGLRenderWindow (0x198ce420): GLEW could not be initialized: Missing GL version”
vtk is installed by compilation (VTK_PYTHON_VERSION = 3, VTK_WRAP_PYTHON = ON)
the code is:
```
from PyQt5.QtWidgets import QApplication, QMainWindow
import sys
import vtk
from PyQt5 import QtCore, QtGui, QtWidgets
from vtk.qt.QVTKRenderWindowInteractor import QVTKRenderWindowInteractor
class myMainWindow(QtWidgets.QMainWindow):
def __init__(self, parent=None):
QtWidgets.QMainWindow.__init__(self, parent)
self.frame = QtWidgets.QFrame()
self.vl = QtWidgets.QVBoxLayout()
self.vtkWidget = QVTKRenderWindowInteractor(self.frame)
self.vl.addWidget(self.vtkWidget)
self.ren = vtk.vtkRenderer()
self.vtkWidget.GetRenderWindow().AddRenderer(self.ren)
self.iren = self.vtkWidget.GetRenderWindow().GetInteractor()
# Create source
source = vtk.vtkConeSource()
source.SetCenter(0, 0, 0)
source.SetRadius(0.1)
source1 = vtk.vtkSphereSource()
source1.SetCenter(0, 0, 0)
source1.SetRadius(0.3)
# Create a mapper
mapper = vtk.vtkPolyDataMapper()
mapper.SetInputConnection(source.GetOutputPort())
mapper1 = vtk.vtkPolyDataMapper()
mapper1.SetInputConnection(source1.GetOutputPort())
# Create an actor
actor = vtk.vtkActor()
actor.SetMapper(mapper)
actor1 = vtk.vtkActor()
actor1.SetMapper(mapper1)
self.ren.AddActor(actor)
self.ren.AddActor(actor1)
self.ren.ResetCamera()
self.frame.setLayout(self.vl)
self.setCentralWidget(self.frame)
self.show()
self.iren.Initialize()
if __name__ == "__main__":
app = QApplication(sys.argv)
window = myMainWindow()
sys.exit(app.exec_())
```
the full error message is :
```
$ python3 test.py
2021-01-20 20:20:47.692 ( 0.988s) [ A4946E00]vtkOpenGLRenderWindow.c:569 ERR| vtkXOpenGLRenderWindow (0x2588420): GLEW could not be initialized: Missing GL version
2021-01-20 20:20:47.692 ( 0.988s) [ A4946E00] vtkOpenGLState.cxx:63 WARN| Error in cache state for GL_DEPTH_WRITEMASK
2021-01-20 20:20:47.692 ( 0.988s) [ A4946E00] vtkOpenGLState.cxx:72 WARN| Error in cache state for GL_COLOR_WRITEMASK
2021-01-20 20:20:47.692 ( 0.988s) [ A4946E00] vtkOpenGLState.cxx:79 WARN| Error in cache state for GL_BLEND
2021-01-20 20:20:47.692 ( 0.988s) [ A4946E00] vtkOpenGLState.cxx:86 WARN| Error in cache state for GL_DEPTH_TEST
2021-01-20 20:20:47.692 ( 0.988s) [ A4946E00] vtkOpenGLState.cxx:109 WARN| Error in cache state for GL_SCISSOR_TEST
2021-01-20 20:20:47.692 ( 0.988s) [ A4946E00] vtkOpenGLState.cxx:132 WARN| Error in cache state for GL_VIEWPORT
2021-01-20 20:20:47.692 ( 0.988s) [ A4946E00] vtkOpenGLState.cxx:140 WARN| Error in cache state for GL_SCISSOR_BOX
2021-01-20 20:20:47.692 ( 0.988s) [ A4946E00] vtkOpenGLState.cxx:147 WARN| Error in cache state for GL_CULL_FACE_MODE
2021-01-20 20:20:47.692 ( 0.988s) [ A4946E00] vtkOpenGLState.cxx:154 WARN| Error in cache state for GL_ACTIVE_TEXTURE
2021-01-20 20:20:47.692 ( 0.988s) [ A4946E00] vtkOpenGLState.cxx:161 WARN| Error in cache state for GL_DEPTH_FUNC
2021-01-20 20:20:47.692 ( 0.988s) [ A4946E00] vtkOpenGLState.cxx:168 WARN| Error in cache state for GL_BLEND_SRC_RGB
2021-01-20 20:20:47.692 ( 0.988s) [ A4946E00] vtkOpenGLState.cxx:175 WARN| Error in cache state for GL_BLEND_SRC_ALPHA
2021-01-20 20:20:47.692 ( 0.988s) [ A4946E00] vtkOpenGLState.cxx:182 WARN| Error in cache state for GL_BLEND_DST_RGB
2021-01-20 20:20:47.692 ( 0.988s) [ A4946E00] vtkOpenGLState.cxx:189 WARN| Error in cache state for GL_BLEND_DST_ALPHA
2021-01-20 20:20:47.692 ( 0.988s) [ A4946E00] vtkOpenGLState.cxx:196 WARN| Error in cache state for GL_DRAW_FRAMEBUFFER_BINDING
2021-01-20 20:20:47.692 ( 0.989s) [ A4946E00] vtkOpenGLState.cxx:203 WARN| Error in cache state for GL_READ_FRAMEBUFFER_BINDING
2021-01-20 20:20:47.692 ( 0.989s) [ A4946E00] vtkOpenGLState.cxx:222 WARN| Error in cache state for GL_DRAW_BUFFER got -148227696 expected1026
2021-01-20 20:20:47.692 ( 0.989s) [ A4946E00] vtkOpenGLState.cxx:240 WARN| Error in cache state for GL_READ_BUFFER
2021-01-20 20:20:47.692 ( 0.989s) [ A4946E00] vtkOpenGLState.cxx:257 WARN| Error in cache state for GL_COLOR_CLEAR_VALUE
2021-01-20 20:20:47.695 ( 0.991s) [ A4946E00] vtkOpenGLState.cxx:265 WARN| at stack loc
0x7f9e4753e0 : ??? [(???) ???:-1]
0x7f9e46ff54 : vtksys::SystemInformation::GetProgramStack[abi:cxx11](int, int) [(libvtksys-9.0.so.1) ???:-1]
0x7f9759e178 : vtkOpenGLState::CheckState() [(libvtkRenderingOpenGL2-9.0.so.1) ???:-1]
0x7f975a1ebc : vtkOpenGLState::vtkglGetIntegerv(unsigned int, int*) [(libvtkRenderingOpenGL2-9.0.so.1) ???:-1]
0x7f97579ddc : vtkOpenGLRenderWindow::CreateOffScreenFramebuffer(int, int) [(libvtkRenderingOpenGL2-9.0.so.1) ???:-1]
0x7f9757750c : vtkOpenGLRenderWindow::Start() [(libvtkRenderingOpenGL2-9.0.so.1) ???:-1]
0x7f976581c0 : vtkXOpenGLRenderWindow::Start() [(libvtkRenderingOpenGL2-9.0.so.1) ???:-1]
0x7f9bcf1554 : vtkRenderWindow::Render() [(libvtkRenderingCore-9.0.so.1) ???:-1]
0x7f9757ab7c : vtkOpenGLRenderWindow::Render() [(libvtkRenderingOpenGL2-9.0.so.1) ???:-1]
0x7f9765ab28 : vtkXOpenGLRenderWindow::Render() [(libvtkRenderingOpenGL2-9.0.so.1) ???:-1]
0x7f9bcfacfc : vtkRenderWindowInteractor::Render() [(libvtkRenderingCore-9.0.so.1) ???:-1]
0x7f9bcfdbc8 : vtkRenderWindowInteractor::Initialize() [(libvtkRenderingCore-9.0.so.1) ???:-1]
0x7f9c035a70 : ??? [(???) ???:-1]
0x5bbd4c : _PyCFunction_FastCallDict [(python3) ???:-1]
0x52ba70 : ??? [(???) ???:-1]
0x5306c0 : _PyEval_EvalFrameDefault [(python3) ???:-1]
0x52b108 : ??? [(???) ???:-1]
0x52b42c : _PyFunction_FastCallDict [(python3) ???:-1]
0x607a20 : _PyObject_FastCallDict [(python3) ???:-1]
0x5f4d34 : ??? [(???) ???:-1]
0x608da8 : PyObject_Call [(python3) ???:-1]
0x597e30 : ??? [(???) ???:-1]
0x5a740c : ??? [(???) ???:-1]
0x607948 : _PyObject_FastCallDict [(python3) ???:-1]
0x52b850 : ??? [(???) ???:-1]
0x5306c0 : _PyEval_EvalFrameDefault [(python3) ???:-1]
0x52b108 : ??? [(???) ???:-1]
0x631598 : PyRun_FileExFlags [(python3) ???:-1]
0x636c2c : PyRun_SimpleFileExFlags [(python3) ???:-1]
0x621428 : Py_Main [(python3) ???:-1]
0x420d3c : main [(python3) ???:-1]
0x7fa46156e0 : __libc_start_main [(libc.so.6) ???:-1]
0x420e94 : ??? [(???) ???:-1]
Segmentation fault (core dumped)
```https://gitlab.kitware.com/vtk/vtk/-/issues/18084vtkOpenGLCellToVTKCellMap CellCellMap Invalid2021-01-18T08:31:07-05:00Stephen HogarthvtkOpenGLCellToVTKCellMap CellCellMap InvalidIn Rendering/OpenGL2/vtkOpenGLCellToVTKCellMap.cpp, if the MapBuildState is updated and the CellCellMap cleared, mappers will not hardware probe accurately. This may be as a result of some other part of the application calling `BuildPrim...In Rendering/OpenGL2/vtkOpenGLCellToVTKCellMap.cpp, if the MapBuildState is updated and the CellCellMap cleared, mappers will not hardware probe accurately. This may be as a result of some other part of the application calling `BuildPrimitiveOffsetsIfNeeded` before calling `Update`, without the source data being updated in between the two calls. Then the CellCellMap will not be built during the update call and remain empty despite `CellMapSizes` indicating it should have content.
I have seen this for some time as a very transient bug, but am now seeing it happen very routinely in my application. I assume that it is also the cause for the changes in !7137, as those changes would be some of the defensive programming needed to error handle this situation. It can be avoided if the if statement in `Update` on line 287 changes from `if (this->MapBuildState != this->TempState)` to `if (this->MapBuildState != this->TempState || this->CellCellMap.empty())`, though that doesn't seem to be the proper fix for this bug. Would you have a better idea for how this could be fixed?https://gitlab.kitware.com/vtk/vtk/-/issues/18079Some VTK Dependency not checked at configuration time2021-01-11T09:00:49-05:00Mathieu Westphal (Kitware)Some VTK Dependency not checked at configuration timeThe following package were needed by VTK but not checked at configuration time
* linux-headers for `linux/fs.h`
* libexecinfo-dev for `execinfo.h`
FYI @ben.boeckelThe following package were needed by VTK but not checked at configuration time
* linux-headers for `linux/fs.h`
* libexecinfo-dev for `execinfo.h`
FYI @ben.boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18073vtkAngleRepresentation3D does not compute angle if x-coords of points are the...2021-01-06T05:09:58-05:00Philipp WeissenbachervtkAngleRepresentation3D does not compute angle if x-coords of points are the sameToday I recognized a strange behaviour of the `vtkAngleWidget`. (version 9.0 commit 1762d09ccdddcba85586b67475a2abd89918f590)
When initializing the widget programmatically with three points (all laying on the YZ-plane) the widget does no...Today I recognized a strange behaviour of the `vtkAngleWidget`. (version 9.0 commit 1762d09ccdddcba85586b67475a2abd89918f590)
When initializing the widget programmatically with three points (all laying on the YZ-plane) the widget does not compute the angle.
The problematic section of code is in `vtkAngleRepresentation3D` line 293.
// Compute the angle (only if necessary since we don't want
// fluctuations in angle value as the camera moves, etc.)
if (p1[0] - c[0] == 0.0 || p2[0] - c[0] == 0.0)
{
return;
}
Here, the `BuildRepresentation()` method returns if the x-coordinates of the points are the same (why is it that way?). Is that a bug, or an intended behaviour?
In my use case (CT Viewer) I cannot measure 3D angle if the picked world coordinates originate from the sagittal plane (x-coordinates of all three points are the same). For an example image of the imcomplete angle measurement of the `vtkAngleWidget` see attached image file.
![IncompleteAngleMeasurement](/uploads/4c4dc135393b52971c46f205cde37470/IncompleteAngleMeasurement.png)https://gitlab.kitware.com/vtk/vtk/-/issues/18070vtkFLUENTReader - Cell Array Selection doesn't work2021-01-03T15:06:18-05:00Arthur P.vtkFLUENTReader - Cell Array Selection doesn't workWhen reading Fluent files (.cas) in Paraview, the Cell Array Selection menu (see picture) offers the possibility to add/remove the variables needed before reading the file (when "apply" is pressed).
If I check the variable that I need, P...When reading Fluent files (.cas) in Paraview, the Cell Array Selection menu (see picture) offers the possibility to add/remove the variables needed before reading the file (when "apply" is pressed).
If I check the variable that I need, Paraview will not open the desired variable but all the variables.
The Cell Array selection menu is useless.
The function "this->CellDataArraySelection->AddArray" in the "RequestInformation" function of "IO/Geometry/vtkFLUENTReader.cxx" seems to load the name for Paraview but this is not used afterwards.
![Capture_d_écran_2021-01-03_à_20.20.08](/uploads/8b709a6e6ee68d5ebe7a92457bcf3818/Capture_d_écran_2021-01-03_à_20.20.08.png)https://gitlab.kitware.com/vtk/vtk/-/issues/18069STLWriter error checking needs investigation2021-12-20T17:52:54-05:00Ben BoeckelSTLWriter error checking needs investigationThe `vtkSTLWriter` class tries to detect "out of space" errors, but does so poorly. It checks only `fflush` for an error (any error) and assumes it means `ENOSPC` (rather than checking for `EIO` or other plausible errors). The thing is t...The `vtkSTLWriter` class tries to detect "out of space" errors, but does so poorly. It checks only `fflush` for an error (any error) and assumes it means `ENOSPC` (rather than checking for `EIO` or other plausible errors). The thing is that `fwrite`/`fprintf` could *also* have triggered the `ENOSPC` leaving nothing in the buffer to flush and therefore no error.
I've disabled the testing of the "out of space" error for now because the code just isn't handling the detection well enough for our CI.https://gitlab.kitware.com/vtk/vtk/-/issues/18068SEG-Y 3D Reader is Broken2021-11-03T13:42:53-04:00Bane SullivanSEG-Y 3D Reader is BrokenThe SEG-Y (geophysical seismic format) reader is broken. To reproduce, run the [`TestSegY3DReader` test](https://gitlab.kitware.com/vtk/vtk/-/blob/master/IO/SegY/Testing/Cxx/TestSegY3DReader.cxx)
The output image resolution is so small ...The SEG-Y (geophysical seismic format) reader is broken. To reproduce, run the [`TestSegY3DReader` test](https://gitlab.kitware.com/vtk/vtk/-/blob/master/IO/SegY/Testing/Cxx/TestSegY3DReader.cxx)
The output image resolution is so small that the image comparison test does not detect the fact that it is producing a bad output.
| Expected ([the image on DKC](https://data.kitware.com/api/v1/file/hashsum/sha512/50ac5d767f0cd4c0a2ebf98d64a8cf990ba7aad98c68b6c9fbb6c641c3043c2c2baf2e9a5f20b247ce722054fb9cbff40181f98b794a29339f854786e686cca2/download)) | Actual Ouput |
|---|---|
|![TestSegY3DReader](/uploads/37424f426ebcaef2423f58b4e258d0fb/TestSegY3DReader.png) | ![segy](/uploads/11ad1e56da092af1b03b7e45fba765ee/segy.png) |
The testing data is available [here](https://data.kitware.com/api/v1/file/hashsum/sha512/63a2285ef9dc633ec3696bcdd9af43137d6c519a7a653d45faec549b3f81fbd8ef79120aed6f7b86b62ed0d50e727ea8599aca57d2e3ed8e15a90c4b91c5c1b5/download)
This also affects ParaView. Note that I think using the Force 2D option yields okay results
cc @danlipsahttps://gitlab.kitware.com/vtk/vtk/-/issues/18067Quadratic Quad Cell as Face2020-12-17T03:27:23-05:00MetinQuadratic Quad Cell as FaceThis is an issue related to vtkUnstructuredGridGeometryFilter.
The faces of a 3D quadratic cells are represented by 2D quadratic elements.
### Problem
The inserted/generated faces are not the best representations of a 3D quadratic cel...This is an issue related to vtkUnstructuredGridGeometryFilter.
The faces of a 3D quadratic cells are represented by 2D quadratic elements.
### Problem
The inserted/generated faces are not the best representations of a 3D quadratic cell. See the picture below.
Obviously, the face orientation is wrong but that's not all is it?
The test case is here:
[paraview_testcase_quad.tar](/uploads/4bd48fa47d041c8dd5a5bc43c4e40fae/paraview_testcase_quad.tar)
![testcase_quad](/uploads/2d8372f8ba6ca2420cf4e43cdaa0a756/testcase_quad.png)
### Face Issue
![image](/uploads/31ef255ecc100cd4a86ae71183aef8d4/image.png)
Maybe the cell type VTK_QUADRATIC_QUAD is not the best choice?https://gitlab.kitware.com/vtk/vtk/-/issues/18065const qualifier InsertNextLinkedPoint2020-12-17T12:27:48-05:00Ronaldconst qualifier InsertNextLinkedPointThe point in https://gitlab.kitware.com/vtk/vtk/-/blob/master/Common/DataModel/vtkPolyData.h#L472 should be `const`.The point in https://gitlab.kitware.com/vtk/vtk/-/blob/master/Common/DataModel/vtkPolyData.h#L472 should be `const`.https://gitlab.kitware.com/vtk/vtk/-/issues/18064vtkOpenGLPolyDataMapper Edge Artifacts2023-01-29T19:00:25-05:00Stephen HogarthvtkOpenGLPolyDataMapper Edge ArtifactsWhile upgrading to VTK 9.0, we've found a number of situations where there is now significant artifacting on grid edges which was not present in VTK 8.2. We have tested with both the 9.0 release + "New surface with edges" patched in (!68...While upgrading to VTK 9.0, we've found a number of situations where there is now significant artifacting on grid edges which was not present in VTK 8.2. We have tested with both the 9.0 release + "New surface with edges" patched in (!6880), as well as the master branch, and both show this issue.
On light backgrounds, the triangulation is showing, particularly for line widths in the 1.0->3.0 range. None of the diagonal lines should be showing in this picture:
![2020-12-10-Gridlines-Narrow-Full](/uploads/38e44fc5cc81a1d8f73a4e98b35f28e2/2020-12-10-Gridlines-Narrow-Full.png)
When we add extra conditions to the visibility mask in the mapper to selectively turn off certain edges (modifying vtkOpenGLIndexBufferObject, Line 90), the lines which should be masked out also bleed through with light backgrounds:
![2020-12-15-Dark_BG-Narrow](/uploads/e78ec38a9365c49d55527ec4886e3003/2020-12-15-Dark_BG-Narrow.png)
When the line widths are increased to the 4.0->6.0 range, the bleeds are much less noticeable, but the thin vertical artifacts on the right side of this image are introduced. There are also triangular artifacts along the top and bottom edges of the light blue square.
![2020-12-15-Dark_BG-Wide](/uploads/947f755156df8c39066115d08f71522a/2020-12-15-Dark_BG-Wide.png)
When rendering surfaces with edges, the edges are now much thicker than they were in 8.2, or currently are in wireframe only mode. This can crowd out the faces. It is also disorienting for users when they can easily switch between wireframe only and surface+edges modes. It appears that the extra width to the edges, while always thicker than in wireframe, may be partially dependent on either the absolute size of the grid, or size of grid cells. This makes it hard to get a more consistent look with different grids, which was possible with VTK 8.2.
Note: While possibly unrelated, the 9.0 upgrade has required noticeable changes to coincident topology offsets similar to #17936.https://gitlab.kitware.com/vtk/vtk/-/issues/18059crash writing vtp with degenerate cells (new in vtk9)2021-05-07T03:52:35-04:00Steve Piepercrash writing vtp with degenerate cells (new in vtk9)Code that uses vtkXMLPolyDataWriter that previously worked with vtk8 [started crashing](https://github.com/bostongfx/TRAKO/issues/8) with vtk9. We created a workaround to that in [this PR](https://github.com/bostongfx/TRAKO/pull/10).
I...Code that uses vtkXMLPolyDataWriter that previously worked with vtk8 [started crashing](https://github.com/bostongfx/TRAKO/issues/8) with vtk9. We created a workaround to that in [this PR](https://github.com/bostongfx/TRAKO/pull/10).
In discussions with @jcfr, we decided to post the issue here and flag it as a regression in VTK, since code that used to work (with a warning) now leads to a crash.
The issue is that [this line in vtk 9.0.1](https://gitlab.kitware.com/vtk/vtk/-/blob/v9.0.1/Common/DataModel/vtkPolyData.cxx#L921) throws and error, which is caught [and `this->Cells` is set to `nullptr`](https://gitlab.kitware.com/vtk/vtk/-/blob/v9.0.1/Common/DataModel/vtkPolyData.cxx#L958-962).
In vtk 8.1.2, the [corresponding code](https://gitlab.kitware.com/vtk/vtk/-/blob/v8.1.2/Common/DataModel/vtkPolyData.cxx#L981) generates a warning but processing continues and [`this->Cells` is valid](https://gitlab.kitware.com/vtk/vtk/-/blob/v8.1.2/Common/DataModel/vtkPolyData.cxx#L1050-1052).
Because `this->Cells` is null in vtk 9.0.1, `vtkXMLUnstructuredDataWriter` crashes with a stack trace like this:
```
1 std::vector<vtkPolyData_detail::TaggedCellId>::operator[] stl_vector.h 1043 0x7f3e1ff04516
2 vtkPolyData_detail::CellMap::GetTag vtkPolyDataInternals.h 239 0x7f3e1ff04325
3 vtkPolyData::GetCellType vtkPolyData.h 730 0x7f3e2012759a
4 vtkDataSet::GetCellTypes vtkDataSet.cxx 326 0x7f3e1ff39865
5 vtkXMLUnstructuredDataWriter::ProcessRequest vtkXMLUnstructuredDataWriter.cxx 166 0x7f3e1b31418e
6 vtkExecutive::CallAlgorithm vtkExecutive.cxx 746 0x7f3e1fe25449
7 vtkDemandDrivenPipeline::ExecuteData vtkDemandDrivenPipeline.cxx 462 0x7f3e1fe1cf92
...
```
IMO the correct behavior would be to restore the previous option of just printing a warning and continuing. It's not optimal to have degenerate cells in a `vtkPolyData`, but it should not lead to a crash, especially since it worked before.https://gitlab.kitware.com/vtk/vtk/-/issues/18057Inconsistent .mtl file interpretation of opacity/transparency during Import a...2023-09-27T04:24:11-04:00Mattes SchumannInconsistent .mtl file interpretation of opacity/transparency during Import and Export## Files to be discussed:
- https://gitlab.kitware.com/vtk/vtk/-/blob/master/IO/Import/vtkOBJImporterInternals.cxx
- https://gitlab.kitware.com/vtk/vtk/-/blob/master/IO/Export/vtkOBJExporter.cxx
## Problem
The interpretation of the ``...## Files to be discussed:
- https://gitlab.kitware.com/vtk/vtk/-/blob/master/IO/Import/vtkOBJImporterInternals.cxx
- https://gitlab.kitware.com/vtk/vtk/-/blob/master/IO/Export/vtkOBJExporter.cxx
## Problem
The interpretation of the ```d``` OR ```Tr``` attribute in a .mtl file for a .obj 3D-Object is not consistent along the Import and Export.
- the vtkOBJImporterInternal only interprets the "d" value
- see line https://gitlab.kitware.com/vtk/vtk/-/blob/master/IO/Import/vtkOBJImporterInternals.cxx#L330
- and https://gitlab.kitware.com/vtk/vtk/-/blob/master/IO/Import/vtkOBJImporterInternals.cxx#L493
- but sets the internal ```mtl->trans``` value directly without invertring
- the vtkOBJExporter writes the internal ``opacity``` as "Tr" value in the .mtl file
- see line https://gitlab.kitware.com/vtk/vtk/-/blob/master/IO/Export/vtkOBJExporter.cxx#L212
## Funny Result of this inconsistency
Not really noticing with full opaque models
- Importing a full Opaque object with .mtl attribute "d 1"
- Export results in a .mtl file with attribute "Tr 1"
- Importing again
- Unable to find "d" value -> opacity is set to default = 1
Funny problem begins
- Importing a semitransparent object with .mtl attribute "d 0.2"
- Export results in a .mtl file with attribute "Tr 0.2"
- Importing again
- Unable to find "d" value -> opacity is set to default = 1
- Transparency is lost
## Clarification
- Am I missing something?
- Is this the way to go?
## Suggestion
Implement the standard definition of .mtl attribute, for example https://people.sc.fsu.edu/~jburkardt/data/mtl/mtl.html
I know that vtk is internally using opacity for the object representation. A double definition for the same expression should be not necessary.
- Extend the import:
- if "d"
- Set Opacity with the d value
- if "Tr"
- Set Opacity with 1 - Tr as value
- Fix the export:
- Write the export with "Tr" as ```1 - Internal Opacity```https://gitlab.kitware.com/vtk/vtk/-/issues/18053Build failure with VTK_ALWAYS_OPTIMIZE_ARRAY_ITERATORS2020-11-18T11:58:02-05:00Andrew MacleanBuild failure with VTK_ALWAYS_OPTIMIZE_ARRAY_ITERATORSIf VTK_ALWAYS_OPTIMIZE_ARRAY_ITERATORS is ON then I get:
``` text
Common/Core/vtkDataArrayMeta.h:158: syntax error
```
No other information. The line in question is:
``` text
: value(0)
```
Using CMake 13.18.3 Visual Studio 14.28.293...If VTK_ALWAYS_OPTIMIZE_ARRAY_ITERATORS is ON then I get:
``` text
Common/Core/vtkDataArrayMeta.h:158: syntax error
```
No other information. The line in question is:
``` text
: value(0)
```
Using CMake 13.18.3 Visual Studio 14.28.29333, SDK 10.0.19041.0.https://gitlab.kitware.com/vtk/vtk/-/issues/18052vtkSTLReader crashes when merging is off2020-11-12T04:54:04-05:00Stefan DinkelackervtkSTLReader crashes when merging is offFor context, I quote the VTK documentation of vtkSTLReader:
> .stl files are quite inefficient since they duplicate vertex definitions. By setting the Merging boolean you can control whether the point data is merged after reading. Mergi...For context, I quote the VTK documentation of vtkSTLReader:
> .stl files are quite inefficient since they duplicate vertex definitions. By setting the Merging boolean you can control whether the point data is merged after reading. Merging is performed by default, however, merging requires a large amount of temporary storage since a 3D hash table must be constructed.
However, when switching off merging, vtkSTLReader crashes when it is updated. This bug is at least present in VTK 9 and affects all STL files, no matter how simple they are.
Read access violation is thrown in vtkAbstractArray here:
```inline vtkIdType GetNumberOfValues() const { return (this->MaxId + 1); }```
Call stack:
```> vtkCommonCore-9.0d.dll!vtkAbstractArray::GetNumberOfValues() Line 180 C++
vtkCommonDataModel-9.0d.dll!vtkCellArray::GetNumberOfCells() Line 317 C++
vtkCommonDataModel-9.0d.dll!vtkPolyData::GetNumberOfPolys() Line 206 C++
vtkFiltersCore-9.0d.dll!vtkPolyDataNormals::RequestData(vtkInformation * __formal, vtkInformationVector * * inputVector, vtkInformationVector * outputVector) Line 100 C++
vtkCommonExecutionModel-9.0d.dll!vtkPolyDataAlgorithm::ProcessRequest(vtkInformation * request, vtkInformationVector * * inputVector, vtkInformationVector * outputVector) Line 87 C++
vtkCommonExecutionModel-9.0d.dll!vtkExecutive::CallAlgorithm(vtkInformation * request, int direction, vtkInformationVector * * inInfo, vtkInformationVector * outInfo) Line 746 C++
vtkCommonExecutionModel-9.0d.dll!vtkDemandDrivenPipeline::ExecuteData(vtkInformation * request, vtkInformationVector * * inInfo, vtkInformationVector * outInfo) Line 462 C++
vtkCommonExecutionModel-9.0d.dll!vtkCompositeDataPipeline::ExecuteData(vtkInformation * request, vtkInformationVector * * inInfoVec, vtkInformationVector * outInfoVec) Line 161 C++
vtkCommonExecutionModel-9.0d.dll!vtkDemandDrivenPipeline::ProcessRequest(vtkInformation * request, vtkInformationVector * * inInfoVec, vtkInformationVector * outInfoVec) Line 261 C++
vtkCommonExecutionModel-9.0d.dll!vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation * request, vtkInformationVector * * inInfoVec, vtkInformationVector * outInfoVec) Line 343 C++
vtkCommonExecutionModel-9.0d.dll!vtkCompositeDataPipeline::ForwardUpstream(vtkInformation * request) Line 726 C++
vtkCommonExecutionModel-9.0d.dll!vtkDemandDrivenPipeline::ProcessRequest(vtkInformation * request, vtkInformationVector * * inInfoVec, vtkInformationVector * outInfoVec) Line 247 C++
vtkCommonExecutionModel-9.0d.dll!vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation * request, vtkInformationVector * * inInfoVec, vtkInformationVector * outInfoVec) Line 343 C++
vtkCommonExecutionModel-9.0d.dll!vtkDemandDrivenPipeline::UpdateData(int outputPort) Line 421 C++
vtkCommonExecutionModel-9.0d.dll!vtkStreamingDemandDrivenPipeline::Update(int port, vtkInformationVector * requests) Line 417 C++
vtkCommonExecutionModel-9.0d.dll!vtkStreamingDemandDrivenPipeline::Update(int port) Line 381 C++
vtkCommonExecutionModel-9.0d.dll!vtkAlgorithm::Update(int port) Line 1422 C++
vtkCommonExecutionModel-9.0d.dll!vtkAlgorithm::Update() Line 1416 C++
```https://gitlab.kitware.com/vtk/vtk/-/issues/18036incorrect visualization crossing objects (python, windows, vtk9.0.1)2020-12-06T14:15:06-05:00Mikeincorrect visualization crossing objects (python, windows, vtk9.0.1)Good day!
I built exe for the windows using cx_Freeze, python3.8, pyQt5, vtk9.0.1 and see that visualization is not correct. It works correctly for the previous (it might be vtk8.1) version. Cut by plane part of the object should be in f...Good day!
I built exe for the windows using cx_Freeze, python3.8, pyQt5, vtk9.0.1 and see that visualization is not correct. It works correctly for the previous (it might be vtk8.1) version. Cut by plane part of the object should be in front:
![image](/uploads/6c59072230efecdce34a0f6ef8a1e1df/image.png)
![image](/uploads/0f15aeffa97e219c9322ac23d3d1c7e1/image.png)
**The correct version:**
![image](/uploads/434cf9bfa001acfd9868dd55ba650e56/image.png)https://gitlab.kitware.com/vtk/vtk/-/issues/18035vtkNetCDFCFReader orientation issue2020-10-23T14:20:41-04:00Bane SullivanvtkNetCDFCFReader orientation issueHere is an example NetCDF file that is improperly loaded by VTK (and ParaView by extension): [from_scratch.nc](/uploads/b92e1b20256c6f98b822d585221a3b76/from_scratch.nc)
the NetCDF file is using the CF convention and the axes are labele...Here is an example NetCDF file that is improperly loaded by VTK (and ParaView by extension): [from_scratch.nc](/uploads/b92e1b20256c6f98b822d585221a3b76/from_scratch.nc)
the NetCDF file is using the CF convention and the axes are labeled x and z. It appears that the reader is generating an output vtkImageData object without the proper transform. I understand support for oriented images is new (reference [this discourse topic](https://discourse.vtk.org/t/proposal-to-add-orientation-to-vtkimagedata-feedback-wanted/120)), and I see that `vtkNetCDFCFReader` is listed in the ["VTK Orientation Support: Classes To Update" spreadsheet](https://docs.google.com/spreadsheets/d/1cpTFnMqTymmBsWeveU2b1QjjU1d8V27f0HpBZJ-QbGE/edit#gid=1151021196) without a status.
`ncdump -h from_scratch.nc` shows:
```
netcdf from_scratch {
dimensions:
time = 100 ;
y = 12 ;
x = 500 ;
variables:
double salinity(time, y, x) ;
salinity:_FillValue = NaN ;
salinity:coordinates = "yc xc" ;
int64 time(time) ;
time:units = "days since 2014-09-06 00:00:00" ;
time:calendar = "proleptic_gregorian" ;
double xc(y, x) ;
xc:_FillValue = NaN ;
xc:axis = "X" ;
xc:long_name = "x-coordinate in Cartesian system" ;
xc:units = "m" ;
double yc(y, x) ;
yc:_FillValue = NaN ;
yc:axis = "Z" ;
yc:long_name = "sigma" ;
yc:positive = "down" ;
yc:units = "m" ;
// global attributes:
:convention = "CF-1.4" ;
}
```
Note the `axis` properties properly listed how the data should be oriented. VTK is seemingly ignoring this orientation.
Code to demonstrate (executed with VTK 9.0.1 python bindings):
```py
import vtk
r = vtk.vtkNetCDFCFReader()
r.SetFileName("from_scratch.nc")
r.Update()
print(r.GetOutput().GetBounds())
```
output: `(0.0, 499.0, 0.0, 11.0, 0.0, 0.0)` (on the XY plane)
-------
Originally [posted in the Pangeo Support Forum](https://groups.google.com/g/xarray/c/0_6983KBwHw/m/lBDMe8gFAgAJ)https://gitlab.kitware.com/vtk/vtk/-/issues/18032Add VTK_USE_COCOA and VTK_USE_X to VTK config file2020-11-09T14:13:44-05:00Jean-Christophe Fillion-RobinAdd VTK_USE_COCOA and VTK_USE_X to VTK config fileWhen building LookingGlassVTKModule externally (thanks to [PR Kitware/LookingGlassVTKModule#9](https://github.com/Kitware/LookingGlassVTKModule/pull/9), it fails to include `vtkCocoaLookingGlassRenderWindow.mm` and `vtkCocoaLookingGlassR...When building LookingGlassVTKModule externally (thanks to [PR Kitware/LookingGlassVTKModule#9](https://github.com/Kitware/LookingGlassVTKModule/pull/9), it fails to include `vtkCocoaLookingGlassRenderWindow.mm` and `vtkCocoaLookingGlassRenderWindow.h` (see [here](https://github.com/Kitware/LookingGlassVTKModule/blob/f3b4c8928c002533337479733af4ec10282c7aa9/CMakeLists.txt#L13-L16) and issue [KitwareMedical/SlicerLookingGlass#2](https://github.com/KitwareMedical/SlicerLookingGlass/issues/2))
Moving forward, I would like to expose option like `VTK_USE_COCOA` and `VTK_USE_X` into a config file.
What is the CMake equivalent of `vtkRenderingOpenGLConfigure.h` ?Jean-Christophe Fillion-RobinJean-Christophe Fillion-Robinhttps://gitlab.kitware.com/vtk/vtk/-/issues/18031vtkOBBTree.IntersectWithLine not finding intersection cell when it should2020-10-15T23:08:12-04:00Bane SullivanvtkOBBTree.IntersectWithLine not finding intersection cell when it shouldRelated to #17440 and #10860
Originated in https://github.com/pyvista/pyvista/issues/918
------
Here is an example mesh: [mesh.stl](/uploads/491526f226431ebf3f27ebd8f32621af/mesh.stl)
Using a known vector through the mesh, the `vtkOB...Related to #17440 and #10860
Originated in https://github.com/pyvista/pyvista/issues/918
------
Here is an example mesh: [mesh.stl](/uploads/491526f226431ebf3f27ebd8f32621af/mesh.stl)
Using a known vector through the mesh, the `vtkOBBTree.IntersectWithLine` does not find an intersection cell.
```py
import vtk
... # load mesh from file
obbTree = vtk.vtkOBBTree()
obbTree.SetDataSet(mesh)
obbTree.BuildLocator()
start = [0,0,0]
stop = [54857, -1.78419e+06, -21443.4]
points = vtk.vtkPoints()
cell_ids = vtk.vtkIdList()
obbTree.IntersectWithLine(start, stop, points, cell_ids)
ncells = cell_ids.GetNumberOfIds()
```
```py
>>> ncells
0
```
when the vector clearly goes through the mesh as shown by loading it in paraview and adding a line source with those same values:
![Screen_Shot_2020-10-15_at_9.07.21_PM](/uploads/c70673a6b5924e9060dd9935af0ca578/Screen_Shot_2020-10-15_at_9.07.21_PM.png)https://gitlab.kitware.com/vtk/vtk/-/issues/18030RedistributeDataSet filter freezes for CONVERGECFD Reader2020-10-15T08:35:09-04:00Cory Quammencory.quammen@kitware.comRedistributeDataSet filter freezes for CONVERGECFD ReaderI have a CONVERGECFD data set, I am loading it in ParaView Version 5.8.1 mpi version. When I am using RedistributeDataSet filter, it froze after progressing to 25%.
Original discussion here: https://discourse.paraview.org/t/redistribute...I have a CONVERGECFD data set, I am loading it in ParaView Version 5.8.1 mpi version. When I am using RedistributeDataSet filter, it froze after progressing to 25%.
Original discussion here: https://discourse.paraview.org/t/redistributedataset-filter-froze-for-convergecfd-reader/5290https://gitlab.kitware.com/vtk/vtk/-/issues/18028OpenVR detection at build time2020-10-14T10:05:50-04:00Bruno PaganiOpenVR detection at build timeHi,
The CMake file for detecting OpenVR is a bit outdated. OpenVR now provides a pkg-config file when packaged by distros, so that should be tried through `pkg_check_modules(OPENVR openvr IMPORTED_TARGET GLOBAL)` (and then link to `PkgC...Hi,
The CMake file for detecting OpenVR is a bit outdated. OpenVR now provides a pkg-config file when packaged by distros, so that should be tried through `pkg_check_modules(OPENVR openvr IMPORTED_TARGET GLOBAL)` (and then link to `PkgConfig::OPENVR`) before resorting to path detection.
Regards.