VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2016-08-12T06:45:13-04:00https://gitlab.kitware.com/vtk/vtk/-/issues/5144Boost 1_34 and BiconnectedComponents2016-08-12T06:45:13-04:00Kitware RobotBoost 1_34 and BiconnectedComponents**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5144). Further discussion may take place here.**
---
In line 85 of vtkBoostBiconnectedComponents.cxx the biconnected_components() tem...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5144). Further discussion may take place here.**
---
In line 85 of vtkBoostBiconnectedComponents.cxx the biconnected_components() templated function taking 4 arguments is not being instantiated coreectly.
I using Boost 1_34 and Visual Studio 8.0https://gitlab.kitware.com/vtk/vtk/-/issues/5111coordinate conversions inconsistent2016-08-12T06:45:02-04:00Kitware Robotcoordinate conversions inconsistent**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5111). Further discussion may take place here.**
---
There are myriad ways to convert point locations between DISPLAY, VIEWPORT, VIEW...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5111). Further discussion may take place here.**
---
There are myriad ways to convert point locations between DISPLAY, VIEWPORT, VIEW, and WORLD coordinates. For example: vtkRenderer provides SetWorldPoint(), WorldToDisplay(), and GetDisplayPoint() which can be strung together to transform world coordinates to display coordinates; on the other hand vtkCoordinate provides SetCoordinateSystemToWorld(), SetValue() and GetComputedDoubleDisplayValue() which should do the same transformation.
However, the two methods don't always agree.
There are more examples of conversion inconsistency between vtkRenderer and vtkCoordinate, as demonstrated by the attached test case.https://gitlab.kitware.com/vtk/vtk/-/issues/5084Coefficients wrong for vtkKochanekSpline for 2 point special case2016-08-12T06:44:54-04:00Kitware RobotCoefficients wrong for vtkKochanekSpline for 2 point special case**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5084). Further discussion may take place here.**
---
vtkKochanekspline::Fit1D sets the second coefficient for the 2 point specializat...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5084). Further discussion may take place here.**
---
vtkKochanekspline::Fit1D sets the second coefficient for the 2 point specialization incorrectly.
If the interval is anything other than 0->1, then the interpolation will be incorrect.
Correct value is
coefficients[0][1] = (y[1] - y[0]);
Not
coefficients[0][1] = (y[1] - y[0]) / (x[1] - x[0]);
This is line 228 of vtkKochanekSpline.cxxhttps://gitlab.kitware.com/vtk/vtk/-/issues/5065Build debug and release libs/dlls to the same directory.2016-08-12T06:44:49-04:00Kitware RobotBuild debug and release libs/dlls to the same directory.**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5065). Further discussion may take place here.**
---
An option to build/install debug and release libs/dlls to the same directory.
...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5065). Further discussion may take place here.**
---
An option to build/install debug and release libs/dlls to the same directory.
I think this can be easily done by changging: <VTK_DIR>\Cmake\KitCommonBlock.cmake
From:
IF(VTK_LIBRARY_PROPERTIES)
SET_TARGET_PROPERTIES(${KIT_LIBRARY_TARGETS} PROPERTIES
${VTK_LIBRARY_PROPERTIES}
)
ENDIF(VTK_LIBRARY_PROPERTIES)
to:
IF(VTK_LIBRARY_PROPERTIES)
SET_TARGET_PROPERTIES(${KIT_LIBRARY_TARGETS} PROPERTIES
${VTK_LIBRARY_PROPERTIES}
)
#Add this line to change the output debug library name to *_d.lib/.dll
SET_TARGET_PROPERTIES(${KIT_LIBRARY_TARGETS} PROPERTIES
DEBUG_POSTFIX _d
)
ENDIF(VTK_LIBRARY_PROPERTIES)
This is documented at the following URL: http://www.vesuite.org/forum/viewtopic.php?=&p=341
Can this be extended to include an option to add the _d extension automatically when building VTK?
The rationale is that when building your own code it would be nice to automatically include either the debug or release versions as appropriate.https://gitlab.kitware.com/vtk/vtk/-/issues/5060vtkStripper SegFaults on a simple mesh (but works on others)2016-08-12T06:44:47-04:00Kitware RobotvtkStripper SegFaults on a simple mesh (but works on others)**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5060). Further discussion may take place here.**
---
Hello, I am learning python-vtk and I have run into strange behavior that may be...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5060). Further discussion may take place here.**
---
Hello, I am learning python-vtk and I have run into strange behavior that may be a bug in vtkStripper. I have a short python script which takes a simple .vtk poly data file and converts the triangle list to triangle strips (listing below). The input .vtk file is generated by a Blender export script. The vtkStripper script works fine on all my test data *except* one paricular mesh (also listed below). On that mesh vtkStripper segfaults.
I have disected the mesh and found that the problem involves only a small area (listed below). There are no duplicate points, or wrong-way normals, or anything obviously degenerate about this mesh. Just this small sub-mesh is enough to cause vtkStripper to segfault. The original mesh is a closed surface, which topologicaly seems equivalent to a cylinder. This fragment is one end of that cylinder.
Adding vtkTriangleFilter before vtkStripper does not solve the issue.
I am using VTK 4.4.2-5 bound to python 2.3 on a linux (debian derived) system. The vtk libs were installed from the python-vtk package version 4.4.2-5.
Thank You Very Much!
-brice
############################
from vtk import vtkPolyDataReader, vtkStripper, vtkPolyDataWriter
reader = vtkPolyDataReader()
reader.SetFileName("stripify-vtkinput.vtk")
stripper = vtkStripper()
stripper.SetInput(triangles.GetOutput())
stripper.Update()
stripper = vtkStripper()
stripper.SetInput(triangles.GetOutput())
stripper.Update()
newmesh = None
newmesh = stripper.GetOutput()
writer = vtkPolyDataWriter()
writer.SetInput(newmesh)
writer.SetFileName("stripify-vtkoutput.vtk")
writer.Write()
############################
# vtk DataFile Version 3.0
vtk PolyData input
ASCII
DATASET POLYDATA
POINTS 41 float
0.010 -0.014 -21.389
-3.754 2.721 -20.773
-1.428 4.411 -20.773
3.774 2.721 -20.773
4.663 -0.014 -20.773
3.774 -2.749 -25.096
3.774 -2.749 -20.773
4.663 -0.014 -25.096
1.448 -4.439 -25.096
1.448 -4.439 -20.773
-1.428 -4.439 -25.096
-1.428 -4.439 -20.773
-3.754 -2.749 -25.096
-3.754 -2.749 -20.773
-4.643 -0.014 -25.096
-4.643 -0.014 -20.773
-3.754 2.721 -25.096
-1.428 4.411 -25.096
1.448 4.411 -25.096
1.448 4.411 -20.773
3.774 2.721 -25.096
6.965 5.040 -23.944
8.607 -0.014 -23.944
11.243 -0.014 -22.524
9.098 6.589 -22.524
2.667 8.163 -23.944
3.481 10.670 -22.524
-2.647 8.163 -23.944
-3.461 10.670 -22.524
-6.946 5.040 -23.944
-9.078 6.589 -22.524
-8.588 -0.014 -23.944
-11.223 -0.014 -22.524
-6.946 -5.067 -23.944
-9.078 -6.616 -22.524
-2.647 -8.190 -23.944
-3.461 -10.697 -22.524
2.667 -8.190 -23.944
3.481 -10.697 -22.524
6.965 -5.067 -23.944
9.098 -6.616 -22.524
POLYGONS 70 280
3 0 1 2
3 0 3 4
3 5 6 7
3 5 7 8
3 9 10 6
3 9 6 5
3 11 12 10
3 11 10 9
3 13 14 12
3 13 12 11
3 15 16 14
3 15 14 13
3 17 18 15
3 18 16 15
3 19 20 18
3 19 18 17
3 21 22 20
3 21 20 19
3 23 24 22
3 23 22 21
3 8 7 24
3 8 24 23
3 2 25 0
3 25 3 0
3 26 27 0
3 27 1 0
3 28 29 0
3 29 26 0
3 4 30 0
3 30 28 0
3 23 31 32
3 23 32 8
3 31 33 32
3 34 33 31
3 31 35 34
3 35 36 34
3 23 21 31
3 21 35 31
3 21 19 37
3 21 37 35
3 35 37 38
3 35 38 36
3 37 39 40
3 37 40 38
3 17 39 19
3 39 37 19
3 15 41 17
3 41 39 17
3 39 41 40
3 41 42 40
3 41 43 42
3 43 44 42
3 15 13 43
3 15 43 41
3 13 11 45
3 13 45 43
3 43 45 44
3 45 46 44
3 45 47 46
3 47 48 46
3 11 9 47
3 11 47 45
3 9 5 47
3 5 49 47
3 47 49 48
3 49 50 48
3 32 33 50
3 32 50 49
3 8 32 5
3 32 49 5
################################https://gitlab.kitware.com/vtk/vtk/-/issues/5040inScalar/inTensor usage without NULL pointer check2016-08-12T06:44:40-04:00Kitware RobotinScalar/inTensor usage without NULL pointer check**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5040). Further discussion may take place here.**
---
line 373/374:
cellTensors = vtkDataArray::CreateDataArray(inTensors-&gt;GetDa...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5040). Further discussion may take place here.**
---
line 373/374:
cellTensors = vtkDataArray::CreateDataArray(inTensors->GetDataType());
cellScalars = vtkDataArray::CreateDataArray(inScalars->GetDataType());
line 615/616:
cellTensors->Delete();
cellScalars->Delete();https://gitlab.kitware.com/vtk/vtk/-/issues/5033PATCH: improved anti-aliased rendering2016-08-12T06:44:38-04:00Kitware RobotPATCH: improved anti-aliased rendering**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5033). Further discussion may take place here.**
---
The current anti-aliased rendering in VTK implemented in vtkRenderWindow::DoAARe...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5033). Further discussion may take place here.**
---
The current anti-aliased rendering in VTK implemented in vtkRenderWindow::DoAARender() leads to unwanted jittering of the whole rendered scene. This is a result of the random camera offsets used, which are not guaranteed to be equally distributed over all possible offset directions. The end-result of this is that entire scene can end up "jumping around" in random directions over a 1 pixel distance per frame, even in the case of an unchanging dataset being rendered from the same viewpoint. This is especially noticeable at lower frame resolutions.
At http://staff.science.uva.nl/~paul/vtk_aa/ I have added some examples of different numbers of AA frames for the same scene. Each shows sequential frames for a static dataset rendered from a fixed viewpoint, i.e. any jitter in the frames comes from either VTK's rendering or from video compression of the resulting AVI's (DivX). With 0 AA frames, the model stays completely still, as expected. This also shows that any jittering doesn't come from the video encoding. With 5 AA frames using VTK's current sampling the model jumps noticeably around in the image. With 4 AA frames using the improved sampling the model is already more stable. At 10 AA frames using the current sampling the model is still jumping around, with 9 AA frames using the improved sampling the model stays almost completely still (which can also be seen by the size of the encoded AVI's, as less jittering leads to less inter-frame pixel differences and therefore less bits needed per encoded frame). At 15 AA frames using the current sampling the model is still not completely visually stable, at 16 improved AA samples the jumping around is almost not noticeable.
This patch improves on that by guaranteeing that camera offsets used for the different AA subframes are distributed more equally over the set of possible directions. A regular grid of camera offsets is generated, spanning the set of offsets of [-1/2,1/2] for both X and Y direction. The regularly spaced offsets are then jittered by a small amount.
The patch only uses this different sampling strategy when the number of AA frames is a square number (e.g. 9 samples, resulting in a 3x3 grid) for which a regularly grid can easily be constructed. For other values of the number of AA frames, the currently present sampling is used.https://gitlab.kitware.com/vtk/vtk/-/issues/5018Crash in vtkArrayCalculator::AddScalarArrayName2016-08-12T06:44:33-04:00Kitware RobotCrash in vtkArrayCalculator::AddScalarArrayName**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5018). Further discussion may take place here.**
---
Upon adding a second scalar array name, the method causes a segfault:
The offen...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5018). Further discussion may take place here.**
---
Upon adding a second scalar array name, the method causes a segfault:
The offending lines are in the first loop:
...
this->ScalarArrayNames[i] = NULL;
varNames[i] = new char[strlen(this->ScalarArrayNames[i]) + 1];
I think you meant to use "ScalarVariableNames" in the line above.
This same code also appears in the source for 5.0.3, but I haven't tested thathttps://gitlab.kitware.com/vtk/vtk/-/issues/5011libvtklibxml2.so not installed2016-08-12T06:44:31-04:00Kitware Robotlibvtklibxml2.so not installed**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5011). Further discussion may take place here.**
---
While building the CVS version of VTK of May 10th, 2007 and doing make install I...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5011). Further discussion may take place here.**
---
While building the CVS version of VTK of May 10th, 2007 and doing make install I noticed that several shared libs (e.g. libvtkInfovis.so) link to libvtklibxml2.so. This last one does not seem to get installed with make install, although it is built.https://gitlab.kitware.com/vtk/vtk/-/issues/4931Python wrappers: input/output to and from string broken2016-08-12T06:44:08-04:00Kitware RobotPython wrappers: input/output to and from string broken**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4931). Further discussion may take place here.**
---
(This is using a recent (April 2007) CVS version)
The VTK classes vtkDataWrit...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4931). Further discussion may take place here.**
---
(This is using a recent (April 2007) CVS version)
The VTK classes vtkDataWriter and vtkDataReader provide methods for writing and reading to/from a string, instead of the usual file. These are really handy for situations where a dataset isn't supposed or doesn't need to hit the disk (like when transferring over a network).
Although VTK's Python wrappers do make the necessary methods available to Python scripts, they are not usable in their current form. This is because embedded NULL characters in input/output strings aren't correctly handled.
Specifically:
* vtkDataSetWriter.GetOutputString will return a Python string _up to the first \x00 in the output_, which for a binary VTK file, is somewhere after the header.
* Working around the limitation by setting the file type to ASCII (so no embedded NULLs are in the output string) usually fails in vtkDataSetWriter.Write(). This seems to be related to the amount of space reserved for the output string.
* vtkDataSetReader.Set(Binary)InputString does not allow to pass a Python string containing an embedded NULL character.
* A work-around exists by passing a vtkCharArray instead of a string for the previous point, but this is really inefficient
The problems at the VTK <-> Python boundary come from the specific Python C/API functions used to handle the string marshalling.https://gitlab.kitware.com/vtk/vtk/-/issues/4877vtkImageData doxygen syntax2016-08-12T06:43:51-04:00Kitware RobotvtkImageData doxygen syntax**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4877). Further discussion may take place here.**
---
http://www.vtk.org/doc/release/5.0/html/a01509.html#z1066_2
GetNumberOfPoints, ...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4877). Further discussion may take place here.**
---
http://www.vtk.org/doc/release/5.0/html/a01509.html#z1066_2
GetNumberOfPoints, GetPoint(vtkIdType), GetPoint(vtkIdType, double x[3]), ..., GetMaxCellSize all have the doxygen comment of
"Return what type of dataset this is."https://gitlab.kitware.com/vtk/vtk/-/issues/4862vtkTensorGlyph ignores Scaling ivar2016-08-12T06:43:47-04:00Kitware RobotvtkTensorGlyph ignores Scaling ivar**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4862). Further discussion may take place here.**
---
The vtkTensorGlyph filter completely ignores the Scaling ivar. It is thus imposs...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4862). Further discussion may take place here.**
---
The vtkTensorGlyph filter completely ignores the Scaling ivar. It is thus impossible to turn off scaling when using this filter.https://gitlab.kitware.com/vtk/vtk/-/issues/4826leak in vtkClipPolyData.cxx2016-08-12T06:43:36-04:00Kitware Robotleak in vtkClipPolyData.cxx**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4826). Further discussion may take place here.**
---
when input scalars to clip by, if the array isn't present, then a bunch of 1k bl...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4826). Further discussion may take place here.**
---
when input scalars to clip by, if the array isn't present, then a bunch of 1k blocks allocated at the top of RequestData are leaked.https://gitlab.kitware.com/vtk/vtk/-/issues/4825leak in vtkFeatureEdges.cxx2016-08-12T06:43:36-04:00Kitware Robotleak in vtkFeatureEdges.cxx**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4825). Further discussion may take place here.**
---
missing a Locator-&gt;Initialize() at the end of RequestData.**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4825). Further discussion may take place here.**
---
missing a Locator->Initialize() at the end of RequestData.https://gitlab.kitware.com/vtk/vtk/-/issues/4824Hardware MIP in vtkVolumeTextureMapper2016-08-12T06:43:35-04:00Kitware RobotHardware MIP in vtkVolumeTextureMapper**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4824). Further discussion may take place here.**
---
It would be nice to be able to change the current BlendMode to allow Composite a...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4824). Further discussion may take place here.**
---
It would be nice to be able to change the current BlendMode to allow Composite and MIP blending.
This could be adapted without problems, since the OpenGL extension GL_blend_minmax can to this and is supported by all modern grafics cards. I have added the files that show how to activate this extension. (these files are just samples and contain some other changes that are just experimental!)
With Regards
Michaelhttps://gitlab.kitware.com/vtk/vtk/-/issues/4725vtkXMLShader.cxx places string terminator in incorrect position when reading ...2016-08-12T06:42:59-04:00Kitware RobotvtkXMLShader.cxx places string terminator in incorrect position when reading shaders from files**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4725). Further discussion may take place here.**
---
Under Windows with Microsoft Visual C++, vtkXMLShader places the string terminat...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4725). Further discussion may take place here.**
---
Under Windows with Microsoft Visual C++, vtkXMLShader places the string terminator '\0' in the incorrect place if CRLF line endings are used. Apparently, the ifstream.read() function converts two-byte CRLF line endings into a single-byte line ending. Thus, in the current code, the string terminator is placed beyond the end of the shader code, effectively leaving undefined character values in the shader code which causes the shader compiler to fail. I have attached a path file for a fix to this problem that places the string terminator in the correct position.https://gitlab.kitware.com/vtk/vtk/-/issues/4719vtkFFMPEGWriter needs porting from use of img_convert to sws_scale2016-08-12T06:42:57-04:00Kitware RobotvtkFFMPEGWriter needs porting from use of img_convert to sws_scale**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4719). Further discussion may take place here.**
---
img_convert, currently used in vtkFFMPEGWriter is a deprecated function. If the ...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4719). Further discussion may take place here.**
---
img_convert, currently used in vtkFFMPEGWriter is a deprecated function. If the flag --enable-swscaler is included in the build for ffmpeg, then img_convert is not included in the distribution.
Note that this seems to be an either or kind of situation, so the patch I have uploaded will convert to using sws_scale, but will break the writer if the avcodec library uses img_convert (I believe)
Also, the cmake configuration files need to be modded to include -lswscale as a dependent library
Note, this deprecation hit me with the most recent build of ffmpeg libraries from debian-multimedia.orghttps://gitlab.kitware.com/vtk/vtk/-/issues/4687wrong endianess decision for EnSight Binary Gold file bigger then 4 Gbytes2016-08-12T06:42:48-04:00Kitware Robotwrong endianess decision for EnSight Binary Gold file bigger then 4 Gbytes**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4687). Further discussion may take place here.**
---
I have a 5.6 Gbytes geometry file for an EnSight Gold Binary case. 467 millions ...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4687). Further discussion may take place here.**
---
I have a 5.6 Gbytes geometry file for an EnSight Gold Binary case. 467 millions cells. The reader falsely estimates that the endianness is wrong based on some code comparing FileSize and grid dimensions. The reader refuses to read the file.
However, this->FileSize is declared as int and assigned with a cast to (int).
When the physical size is greater than 4Gb, the result stored is actually the real size minus 2^32. The tests evaluate to true and execution is interrupted.
I tested declaring FileSize as a long and removing the cast to (int) on line 82 of vtkEnSightGoldBinaryReader.cxx
the test on line 2973 rightfully evaluates to false and execution continues correctly. I am able to visualize my large file.
Can this patch be generalized? and included in future paraview releases? I tested under 2.6.0https://gitlab.kitware.com/vtk/vtk/-/issues/4654vtkCornerAnnotation unnecessary method call2016-08-12T06:42:39-04:00Kitware RobotvtkCornerAnnotation unnecessary method call**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4654). Further discussion may take place here.**
---
in vtkCornerAnnotation::RenderOpaqueGeometry,
the method this->TextReplace(ia, ...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4654). Further discussion may take place here.**
---
in vtkCornerAnnotation::RenderOpaqueGeometry,
the method this->TextReplace(ia, wl) should be called only if there is a change in ImageActor or window/level, and not on viewport resize.
The current condition is (line 424):
if (viewport_size_has_changed || tprop_has_changed ||
(this->GetMTime() > this->BuildTime) ||
(ia && (ia != this->LastImageActor ||
(ia->GetMTime() > this->BuildTime)) ||
(wl && wl->GetMTime() > this->BuildTime))https://gitlab.kitware.com/vtk/vtk/-/issues/4631Bug in vtkXRenderWindowInteractor or vtkInteractorEventRecorder?2016-08-12T06:42:32-04:00Kitware RobotBug in vtkXRenderWindowInteractor or vtkInteractorEventRecorder?**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4631). Further discussion may take place here.**
---
I'm having the same issue that Andrew at Sandia ran into : http://public.kitware...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=4631). Further discussion may take place here.**
---
I'm having the same issue that Andrew at Sandia ran into : http://public.kitware.com/pipermail/vtk-developers/2006-March/004062.html . I'm unable to record using vtkInteractorEventRecorder. It just doesn't work. The render window pops up and vanishes immediately.
The proposed fix adds an boolean ivar to vtkRenderWindowInteractor. The ivar forces the interactor to handle the event loop, ignoring any overrides (Overrides allow you to handle the event loop yourself - they may registered by observing StartEvent on the RenderWindowInteractor). The bug in this context, as outlined in the email is that the RenderWindowInteractor incorrectly assumes that InteractorEventRecorder provides an override and hence immediately returns after popping a render window.
So as to not expose this boolean to the public, the fix makes vtkInteractorEventRecorder a friend of vtkRenderWindowInteractor.
Patch attached