VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2016-08-12T06:36:22-04:00https://gitlab.kitware.com/vtk/vtk/-/issues/3421SNL: Mappers cannot share lookup tables and change opacity.2016-08-12T06:36:22-04:00Kitware RobotSNL: Mappers cannot share lookup tables and change opacity.**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3421). Further discussion may take place here.**
---
We ran into a very bizarre bug recently. We have an application that has severa...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3421). Further discussion may take place here.**
---
We ran into a very bizarre bug recently. We have an application that has several actors, and we want to be able to toggle the opacity if each one individually. We found that sometimes the opacity was usually not being restored to completely opaque correctly.
After much hunting, we discovered that it is because all the actors are sharing the same lookup table. What happens is that the mapper takes the opacity from the actor's property and then passes that to the alpha ivar of the lookup table. It also compares the property's opacity against the lookup table's alpha ivar to see if the colors need to be remapped.
Oops. If there are multiple actors, the lookup tables alpha ivar is not necessarily the same from the last time the render occurred. So if actor1 is opaque and actor2 just had its opacity changed from 0.5 to 1.0, then actor1 will set the lookup table's ivar to 1.0 and actor2 will assume that its opacity was always 1.0 and fail to update the colors.
The attached code demonstrates the bug.https://gitlab.kitware.com/vtk/vtk/-/issues/3400XML Pieces Starting After 2GB Are Lost On 64 Bit OS2016-08-12T06:36:15-04:00Kitware RobotXML Pieces Starting After 2GB Are Lost On 64 Bit OS**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3400). Further discussion may take place here.**
---
This is because vtkXMLDataReader.cxx reads some offsets as int where they should...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3400). Further discussion may take place here.**
---
This is because vtkXMLDataReader.cxx reads some offsets as int where they should be unsigned long int or OffsetType.
I've atached a patch that allowed me to read my file.https://gitlab.kitware.com/vtk/vtk/-/issues/3398vtkExtractGrid memory access violation for 2d cells2016-08-12T06:36:14-04:00Kitware RobotvtkExtractGrid memory access violation for 2d cells**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3398). Further discussion may take place here.**
---
in vtkExtractGrid.cxx / line 368
The index adjustment code increments VOI wi...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3398). Further discussion may take place here.**
---
in vtkExtractGrid.cxx / line 368
The index adjustment code increments VOI without checking if adjusted VOI is within source bounds.
This will access source cell array out of allocated range in case like this:
simple illustration case:
source grid 3x3x3 -> cell grid 2x2x2
vtkExtractGrid->SetVOI(0,2,0,2,2,2)
--> adjusted VOI will be 0,2,0,2,2,3https://gitlab.kitware.com/vtk/vtk/-/issues/3371Using X with GL and APPLE2016-08-12T06:36:06-04:00Kitware RobotUsing X with GL and APPLE**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3371). Further discussion may take place here.**
---
Building on APPLE with VTK_USE_X requires that the user manually set OPENGL_gl_L...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3371). Further discussion may take place here.**
---
Building on APPLE with VTK_USE_X requires that the user manually set OPENGL_gl_LIBRARY, OPENGL_glu_LIBRARY, and OPENGL_INCLUDE_DIR.
This tidbit of inforrmation is burried in the comment at the top of ${CMAKE_ROOT}/Modules/FindOpenGL.cmake. The build goes OK for quite awhile until the Rendering directory starts building, and then the compiler can not find "GL/gl.h" and it breaks.
The following patch makes CMAKE issue an error if these variables are not set. This let's the end user know upfront what the problem is and how to fix it.
===================================================================
RCS file: /cvsroot/VTK/VTK/CMakeLists.txt,v
retrieving revision 1.385
diff -r1.385 CMakeLists.txt
1031,1033c1031,1044
< IF(VTK_USE_RENDERING)
< INCLUDE(${CMAKE_ROOT}/Modules/FindOpenGL.cmake)
< ENDIF(VTK_USE_RENDERING)
---
> IF(VTK_USE_X AND APPLE)
> IF( NOT OPENGL_gl_LIBRARY OR NOT OPENGL_glu_LIBRARY OR NOT OPENGL_INCLUDE_DIR )
> MESSAGE(SEND_ERROR "USE OF X on APPLE requires manual setting of OPENGL_gl_LIBRARY, OPENGL_glu_LIBRARY, and OPENGL_INCLUDE_DIR."
> "You may want to try:"
> "-DOPENGL_gl_LIBRARY:STRING=/usr/X11R6/lib/libGL.a"
> "-DOPENGL_glu_LIBRARY:STRING=/usr/X11R6/lib/libGLU.a"
> "-DOPENGL_INCLUDE_DIR:STRING=/usr/X11R6/include"
> )
> ENDIF( NOT OPENGL_gl_LIBRARY OR NOT OPENGL_glu_LIBRARY OR NOT OPENGL_INCLUDE_DIR )
> ELSE(VTK_USE_X AND APPLE)
> IF(VTK_USE_RENDERING)
> INCLUDE(${CMAKE_ROOT}/Modules/FindOpenGL.cmake)
> ENDIF(VTK_USE_RENDERING)
> ENDIF(VTK_USE_X AND APPLE)https://gitlab.kitware.com/vtk/vtk/-/issues/3363XML + raw image IO streaming2016-08-12T06:36:04-04:00Kitware RobotXML + raw image IO streaming**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3363). Further discussion may take place here.**
---
When a vtkImageReader2 reading raw data is connected to a vtkXMLImageDataWriter ...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3363). Further discussion may take place here.**
---
When a vtkImageReader2 reading raw data is connected to a vtkXMLImageDataWriter writing in certain numbers of streamed pieces, the file produced can not be read with a vtkXMLImageDataReader. The attached code demonstrates the bug. I've observed the behavior on x86 linux with a mpiCC wrapped icpc 8.0 and a x86_64 with g++ 4.1.1. Both with recent VTK from CVS. Under certain conditions the program segfaults during the streamed XML IO, but under conditions it produces errors similar to the following with the extent and piece varying.
[kevin@gargon huge_streamed_test]$ ./huge_streamed_test 500 500 500 10
Now we have a big raw image.
Now we have a big VTI image.
ERROR: In /home/kevin/kitware/VTK/IO/vtkXMLStructuredDataReader.cxx, line 314
vtkXMLImageDataReader (0x51c740): Error reading extent 166 166 199 499 249 249 from piece 2
ERROR: In /home/kevin/kitware/VTK/IO/vtkXMLDataReader.cxx, line 481
vtkXMLImageDataReader (0x51c740): Cannot read point data array "ImageFile" from PointData in piece 2. The data array in the element may be too short.
Now we have a 2nd big VTI image.
I've run the program with many different image sizes and numbers of pieces with different results:
x y z pieces
10 10 10 1 // works
100 100 100 1 // works
100 100 100 2 // works
100 100 100 4 // works
100 100 100 8 // works
100 100 100 9 // works
100 100 100 10 // produces errors reading extents
100 100 100 100 // produces a backtrace
200 200 200 1 // works
200 200 200 8 // works
200 200 200 10 // produces errors reading extents
200 200 200 100 // segfaultshttps://gitlab.kitware.com/vtk/vtk/-/issues/3356CanReadFile in vtkPNGReader has wrong access2016-08-12T06:36:01-04:00Kitware RobotCanReadFile in vtkPNGReader has wrong access**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3356). Further discussion may take place here.**
---
Access to the function should be public, not protected, to match the other image...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3356). Further discussion may take place here.**
---
Access to the function should be public, not protected, to match the other image reading classeshttps://gitlab.kitware.com/vtk/vtk/-/issues/3345Allow parallel to be built without rendering2016-08-12T06:35:58-04:00Kitware RobotAllow parallel to be built without rendering**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3345). Further discussion may take place here.**
---
The only classes in vtkParallel that require rendering are:
vtkCompositeRenderM...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3345). Further discussion may take place here.**
---
The only classes in vtkParallel that require rendering are:
vtkCompositeRenderManager
vtkParallelRenderManager
and the function that takes a vtkPolyDataMapper in vtkPipelineSize if these were handled with ifdefs and subclassing vtkParallel could be built independently.https://gitlab.kitware.com/vtk/vtk/-/issues/3331Replace MPProcessors() to gain improved 64bit compatibility2016-08-12T06:35:53-04:00Kitware RobotReplace MPProcessors() to gain improved 64bit compatibility**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3331). Further discussion may take place here.**
---
On Mac OS X only some APIs are available to 64 bit applications, see:
&lt;http:...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3331). Further discussion may take place here.**
---
On Mac OS X only some APIs are available to 64 bit applications, see:
<http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/indications/chapter_2_section_2.html>
Specifically, only the APIs in System.framework and Accelerate.framework are available. So no Carbon, Cocoa, OpenGL, etc.
vtkMultiThreader.cxx is including Carbon to call the function MPProcessors().
This API could be replaced by a different one for 64 bit compatibility.
One option is sysctl() with 'hw.ncpu'-- I think. I'm not 100% sure of the purpose of vtkMultiThreader::GetGlobalDefaultNumberOfThreads().https://gitlab.kitware.com/vtk/vtk/-/issues/3330vtkBorderRepresentation - virtuals not called2016-08-12T06:35:53-04:00Kitware RobotvtkBorderRepresentation - virtuals not called**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3330). Further discussion may take place here.**
---
The virtual overrides
virtual void vtkBorderRepresentation::StartWidg...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3330). Further discussion may take place here.**
---
The virtual overrides
virtual void vtkBorderRepresentation::StartWidgetInteraction(double eventPos[2]);
virtual void vtkBorderRepresentation::WidgetInteraction(double eventPos[2]);
are not called in preference to the superclass versions
virtual void vtkWidgetRepresentation::StartWidgetInteraction(double* vtkNotUsed(eventPos[2])) {}
virtual void vtkWidgetRepresentation::WidgetInteraction(double* vtkNotUsed(eventPos[2])) {}
because the argument specifications are slightly different
( double* )
( double* const )
Consequently, the border representation does no respond to mouse events.
Changing the derived class versions to
virtual void vtkBorderRepresentation::StartWidgetInteraction(double* eventPos);
virtual void vtkBorderRepresentation::WidgetInteraction(double* eventPos);
appears to fix the problem.
Maybe this is a peculiarity of the MS VC6 compiler?https://gitlab.kitware.com/vtk/vtk/-/issues/3323MPEG writer is leaking memory2016-08-12T06:35:51-04:00Kitware RobotMPEG writer is leaking memory**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3323). Further discussion may take place here.**
---
When writing out a movie, the MPEG writer is not releasing memory of the differe...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3323). Further discussion may take place here.**
---
When writing out a movie, the MPEG writer is not releasing memory of the different images until the whole movie is generated.
Looks like a minor logic error: although the MPEG writer has code meant to release images from the has h table, this code is not using the erase method properly.
Suggest using the method with single parameter as proposed in following patch.
Fixed problem on local copy.
===================================================================
RCS file: /cvsroot/VTK/VTK/IO/vtkMPEG2Writer.cxx,v
retrieving revision 1.3
diff -u -3 -r1.3 vtkMPEG2Writer.cxx
--- IO/vtkMPEG2Writer.cxx 23 Aug 2005 13:42:26 -0000 1.3
+++ IO/vtkMPEG2Writer.cxx 25 May 2006 01:57:44 -0000
@@ -155,7 +155,7 @@
{
return 0;
}
- this->ImagesMap.erase(it, it);
+ this->ImagesMap.erase(it);
return 0;
}
//---------------------------------------------------------------------------https://gitlab.kitware.com/vtk/vtk/-/issues/3319Loss of precision in many VTK filters2016-08-12T06:35:49-04:00Kitware RobotLoss of precision in many VTK filters**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3319). Further discussion may take place here.**
---
Many of VTK filters that work with vtkPolyData create vtkPoints for the output a...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3319). Further discussion may take place here.**
---
Many of VTK filters that work with vtkPolyData create vtkPoints for the output as:
newPts = vtkPoints::New();
This produces float vtkPoints. If the input vtkPoints are of type double, the filter converts double point coordinates to float, with the devastating loss of precision for high dynamic range data. I think you need to go over all chidren of vtkPolyDataAlgorithm and replace the line above with
newPts = vtkPoints::New(inPts->GetDataType());
Without this fix, many of VTK filters are unusable for visualizing Adaptive Mesh Refinement data, which may easily have dynamic range of more than the precision of float, 10^7.https://gitlab.kitware.com/vtk/vtk/-/issues/3312nested vtkAssembly visibility error2018-05-16T09:43:36-04:00Kitware Robotnested vtkAssembly visibility error**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3312). Further discussion may take place here.**
---
I am using nested vtkAssembly's and am curious about the intended functionality ...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3312). Further discussion may take place here.**
---
I am using nested vtkAssembly's and am curious about the intended functionality of the Visibility. It's my understanding that if you have nested vtkAssembly's and you turn off the visibility of one of the vtkAssembly's somewhere in the heirarchy, that every vtkAssembly and prop that is a child of that vtkAssembly should not be visible. That, I have found, is not the functionality of the current cvs code (or at least the one I checked out a couple weeks ago). The functionality that I am seeing is that if you turn off the top vtkAssembly or the bottom viewProp, then the bottom viewProp becomes invisible. Turning off any intermediate vtkAssembly has no effect whatsoever on the bottom viewProp.
I have "fixed" this two different ways. The first was to add code to vtkAssembly::RenderOpaqueGeometry & vtkAssembly::RenderTranslucentGeometry
to loop over all the nodes paths in order to check visibility.
The second way I tried for fixing this was to put a check for visibility in the vtkAssembly::BuildPaths
so that it stop added props along a path as soon as one of the nodes was invisible. I wasn't sure if this impacted other code in a negative way, however.
I'm attach a cvs dif -u file that has both cvs dif call done separately but concatenated into one file.https://gitlab.kitware.com/vtk/vtk/-/issues/3301Add Median Statistic to vtkImageAccumulate2016-08-12T06:35:44-04:00Kitware RobotAdd Median Statistic to vtkImageAccumulate**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3301). Further discussion may take place here.**
---
The vtkImageAccumulate provides min, max, mean, and standard deviation. It would...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3301). Further discussion may take place here.**
---
The vtkImageAccumulate provides min, max, mean, and standard deviation. It would be very helpful if it also provided median.https://gitlab.kitware.com/vtk/vtk/-/issues/3300Zbuffer disabled when rendering actor with opacity != 12016-08-12T06:35:44-04:00Kitware RobotZbuffer disabled when rendering actor with opacity != 1**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3300). Further discussion may take place here.**
---
The vtkOpenGLActor::Render method disables writing to the zbuffer when the opaci...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3300). Further discussion may take place here.**
---
The vtkOpenGLActor::Render method disables writing to the zbuffer when the opacity is not 1.0 and it is not picking. This is fine most of the time, except when the render operation has been executed for the specific purpose of getting the zbuffer. For example, we render translucent geometry to the OpenGL backbuffer to get the zbuffer for generating a 2-D mask.
It would be very helpful if a flag was added to vtkOpenGLActor to override this behavior.https://gitlab.kitware.com/vtk/vtk/-/issues/3299SwapBuffers not Checked on Mac2016-08-12T06:35:43-04:00Kitware RobotSwapBuffers not Checked on Mac**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3299). Further discussion may take place here.**
---
The SwapBuffers flag, set by vtkRenderWindow::SetSwapBuffers(int) is not checked...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3299). Further discussion may take place here.**
---
The SwapBuffers flag, set by vtkRenderWindow::SetSwapBuffers(int) is not checked in vtkCarbonRenderWindow::Frame(). This results in the OpenGL backbuffer always being swapped to the frontbuffer.
The attached patch has been tested on G4 PowerBook and G5 PowerMac.https://gitlab.kitware.com/vtk/vtk/-/issues/3294erronious multiplication order in vtkCamera usertransform2016-08-12T06:35:42-04:00Kitware Roboterronious multiplication order in vtkCamera usertransform**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3294). Further discussion may take place here.**
---
The current Transform in vtkCamera is computed as:
Transform = UserTransform*Pe...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3294). Further discussion may take place here.**
---
The current Transform in vtkCamera is computed as:
Transform = UserTransform*PerspectiveTransform*ViewTransform
To me this does not make any sense. For what I would like to do (controlling camera position and orientation by an external transform), this would make more sense:
Transform = PerspectiveTransform*UserTransform*ViewTransform
This can be achived by moving the concatenate code in ComputePerspectiveTransform to the end of the function.
Also, when using the UserTransform this way the camera light will not follow, since it only depends on the ViewTransform. Unless the UserTransform is intended for an entierly different use, it would be nice to have the camera light transform depend on UserTransform*ViewTransform.https://gitlab.kitware.com/vtk/vtk/-/issues/3280vtkTextActor messed up.2016-08-12T06:35:37-04:00Kitware RobotvtkTextActor messed up.**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3280). Further discussion may take place here.**
---
The text does not look correct, positions are wrong, shadows are wrong. Some si...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3280). Further discussion may take place here.**
---
The text does not look correct, positions are wrong, shadows are wrong. Some side effects when using the new text mapper are that images disappear in the render window. Other side effects include segfaults when a window is resized which causes the text to be resized (this happens in vtkFreeTypeUtilities where the image is no longer resized to a power of 2, the code dies in a libc malloc.) Some of these problems can be seen by running some of the widgets examples which use scaled vtkTextActors.https://gitlab.kitware.com/vtk/vtk/-/issues/3259Missing include qvtkwidget.h2016-08-12T06:37:55-04:00Kitware RobotMissing include qvtkwidget.h**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3259). Further discussion may take place here.**
---
Building VTK 5.0.0 on Fedora Core 5:
gmake[5]: Entering directory `/builddir/...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3259). Further discussion may take place here.**
---
Building VTK 5.0.0 on Fedora Core 5:
gmake[5]: Entering directory `/builddir/build/BUILD/VTK/Examples/All'
Generating GUI.h
Generating GUI.cxx
Generating moc_GUI.cxx
Scanning dependencies of target qtevents
gmake[5]: Leaving directory `/builddir/build/BUILD/VTK/Examples/All'
gmake[5]: Entering directory `/builddir/build/BUILD/VTK/Examples/All'
Building CXX object GUI/Qt/Events/CMakeFiles/qtevents.dir/main.o
Building CXX object GUI/Qt/Events/CMakeFiles/qtevents.dir/GUI.o
/builddir/build/BUILD/VTK/Examples/All/GUI/Qt/Events/GUI.cxx:24:24: error: qvtkwidget.h: No such file or directoryhttps://gitlab.kitware.com/vtk/vtk/-/issues/3233VTK_WRAP_TCL fails on Darwin-Intel2016-08-12T06:35:24-04:00Kitware RobotVTK_WRAP_TCL fails on Darwin-Intel**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3233). Further discussion may take place here.**
---
Mac OS 10.4.6
VTK cvs
gcc 4.0
vtkTkRenderWidget.cxx fails with the followin...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3233). Further discussion may take place here.**
---
Mac OS 10.4.6
VTK cvs
gcc 4.0
vtkTkRenderWidget.cxx fails with the following error:
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MachineExceptions.h:245:error: declaration does not declare anythinghttps://gitlab.kitware.com/vtk/vtk/-/issues/3232vtkPolyLine computes wrong weights2016-08-12T06:35:23-04:00Kitware RobotvtkPolyLine computes wrong weights**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3232). Further discussion may take place here.**
---
The interpolation in polylines is incorrect because vtkPolyLine::EvaluatePositio...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3232). Further discussion may take place here.**
---
The interpolation in polylines is incorrect because vtkPolyLine::EvaluatePosition is computing the wrong weights.