I have written a tool for VTK that generates a text file that describes the class hierarchy as one of the first steps in the build process. Why would I do this? Well, one of the problems with the VTK wrappers has always been that the wrapper-generators see only one header file at a time. This leads to a few complications:

• method inheritance must be dealt with at run time
• parameter type-checking must be done at run time
• return-value construction can become a mess when typing is uncertain

Fortunately, (1) can be dealt with efficiently at run time for Java, Python, and Tcl. However, (2) and (3) require run-time type lookup on both the expected parameter type and the type of the value that is passed. This can be expensive, and to make things even worse, a switch statement would be needed to properly deal with the possible outcomes. This could easily double the amount of code in the wrappers. Right now, the wrapper generators avoid this by assuming that any type beginning with "vtk" is derived from vtkObjectBase (except certain other types like vtkIdType which are automatically converted to int). This is not a safe assumption, and in fact, wrapping a method that takes a "vtkSomething *" that is not derived from vtkObjectBase can result in a segfault.

The solution is a pre-wrapping step called Hierarchy Wrapping builds a text file that describes the class hierarchies of all classes that are encountered in the header files. With the benefit of this file, the wrapper-generators for Tcl, Python, and Java can know, at code-generation time, the base class of any encountered type is. I have written Hierarchy Wrapping code for my WrapVTK project, and will merge it into VTK itself in the coming weeks.

The last couple weeks have involved a lot of work with lex and yacc, which are two profoundly useful programming tools that are almost as old as I am. I've done a lot of work to re-vamp vtkParse.l and vtkParse.y so that they can parse much more of the C++ grammar, in fact they are able to parse each and every VTK class header file without any need to use //BTX, //ETX to block out the more complex bits. The new parser can do the following:

1. Parse all operator methods and return them as e.g. operator->
2. Return names for all types e.g. someclass<double>sometype
3. Parse multiple classes per file, and store info for the one that matches the filename
4. Parse templates, typedefs, enums, scoped names, simple math expressions, etc.

However, the most important feature is perhaps that it can parse complex instances of C++ grammar without choking… this has always been a major problem with the old VTK wrapper generators. There are still many features that I want to add, and I need to expand the FileInfo/FunctionInfo data structs that vtkParse uses so that it can store enum, template, and typedef information.

The parser can be found in my VTK on github and in WrapVTK.

As a side-project to my work on WrapVTK (itself a side-project of SimVTK), I've dug deep into the VTK python wrappers to see how easy it would be to make VTK classes that aren't derived from vtkObjectBase available from python. The answer I dug out is that it wouldn’t be easy, but it wouldn’t be particularly difficult, either.

So, I'd like to announce that I’ve gone ahead and updated the VTK python wrappers so that they can wrap the special type "vtkVariant" and, potentially, dozens of other special-purpose types used by VTK. You can find the code at my VTK fork on github, http://github.com/dgobbi.

This will be an ongoing project (but hopefully not going on for too long). Things are already working much better than expected.

I've updated the vtkClipClosedSurface class to make it create a watertight output. That is, every edge in the output polyhedron is shared by exactly two faces. In comparison, my original version of this class aimed for robust creation of a surface that looked watertight.

The main difference is in the details of how the data is clipped. When a polyhedron is clipped, each polygon edge at the clip plane is cut twice — once per polygon. Each time the edge is clipped, a new vertex is created. So if an edge is clipped twice, it is necessary to merge the two created vertices so that only one vertex appears in the final data set. Originally, I used an Octree-based point locator, which automatically merged points that were coincident or very close. This was a "sloppy" approach. It had the benefit that if the original polygon edges didn't quite match up, then at least an output could still be robustly created. However, a sloppy approach such as this can alter the topology of fine details in the polyhedron's structure. So my new code uses connectivity information, rather than physical location, to determine when newly-created vertices should be merged.

What does this mean, overall? The new version is less tolerant of bad inputs, i.e. it requires the input to have correct topology. But, if given a topologically correct input, it can provide a better guarantee of producing a topologically correct output.

This morning I added a new geometry filter to VTK. It does clipping with an important extra feature: it treats the surface geometry as a topologically closed surface, so that if you give it a closed surface as an input, it will produce a closed surface as an output. Perhaps a better way of saying this is that it treats the data like a solid object, instead of treating it like just a collection of polygons. There are several applications for such a filter in VTK:

• Generating and manipulating data for use in stereolithography a.k.a. 3D printing.
• Visualization of arbitrary closed clipping regions (which is what I originally developed it for).
• Generating closed geometries for use in GPU volume rendering
• FEM model creation (though a triangle refinement step would be necessary)

A more complete description is provided on the VTK wiki page: http://www.vtk.org/Wiki/VTK/Closed_Surface_Clipping.

Approximately three years ago, I started a project at Queen’s University to generate XML descriptions of all of the VTK classes. This project was part of the larger SimVTK project for generating Simulink wrappers for VTK (see previous post). The first version of vtkXML was written by myself and one of the Queens' undergrad compsci students and produced XML output that was really only useful for SimVTK and not useful for anything else.

Finally, I have given vtkXML a life of its own. This new version provides a comprehensive description of all class methods and documentation for each method. It essentially does two things: it provides a dump of all the information the VTK's lex/yacc wrapper front end can glean from the header files, and it synthesizes that information to give an overview of all class instance variables. A full description is provided here.

My pipe dream for vtkXML is for it to become part of a specialized VTK debugger that can inspect and modify VTK pipelines at runtime. There are python based pipeline inspectors, but none (as far as I know) that are pure C++. The idea is that the debugger can attach to a VTK process at runtime and get access to all VTK objects e.g. via the garbage collection system. In the immediate future, however, vtkXML will just be used to enhance SimVTK.

Update May 2nd, 2010: I've renamed this project to WrapVTK and pushed it out to github.