This was a fun little project. I wrote a C++ preprocessor for WrapVTK and will probably add it to VTK itself sometime this week. This preprocessor is specifically meant to be used with a wrapping system, it includes all header files and stores all macros but it does not expand them, instead it allows the wrappers to wrap them. Except for the lack of macro expansion, it is a full preprocessor. It can evaluate expressions and handle #if directives. It can provide an integer value for any macro that will evaluate to an integer after expansion.

The addition of a preprocessor to the VTK wrappers allows a bunch of "hocus pocus" to be removed from the wrapper code. No longer will inscrutable regular expressions be needed to block out odd code chunks that can't be wrapped. No longer will the wrapper-generators need to rely on #ifdefs to decide what types can be wrapped. Instead, the parser will be able to correctly follow the #ifs and #elses in the wrapped header files themselves. Even better, difficult header files like vtkType.h and vtkConfigure.h can be wrapped and all the constants that they define can be made available in Python. It's all good.

Last week I played around with the VTK_IGNORE_BTX setting that I recently added to VTK. This setting tells VTK to ignore the markers that it used to use to block off code that its old wrapper-parser was unable to parse. My new parser has no such difficulties, and after a week of checking the VTK dashboards to see how they responded, I have decided that it is safe to let the new parser to ignore these old markers and just parse everything. This is a big score, because it means that I have successfully managed to create a full C++ parser. I'm not claiming that it is fully compliant to the standard, but it is darn close.

With this, the wrapper project is finally, ahem, wrapping up. I still have a large wish list of things that I would like to add to the project, but for now I have to move on to other things. Hopefully I will have time to come back to this project and fill in my wish list bit-by-bit.

I have dumped my second batch of wrapper changes into VTK. The biggest addition is vtkWrapHierarchy, which creates a text file listing the VTK class hierarchy. Getting the makefiles to properly do the dependencies for this was a pain, because a huge number of files depend on this file, and in turn it depends on everything. So some timestamp tricks and a fake target were required to make everything work nicely.

The other big addition, which I am very proud of, is a more-or-less complete C++ parser. Templates, enums, namespaces, nested function pointers, etc. are all parsed and stored in a data structure for the wrappers to use. Typedefs, unions, and nested classes are missing… but I will get to them soon.

Also, I've been blogged. But no news post. Ah, well.

My enhanced Python wrappers have finally been merged into VTK! A few warnings and a compilation issue on AIX had to be fixed, but the merge was very smooth. The merge provides the following new features to VTK/Python:

• Automatic conversion between python unicode and vtkUnicodeString.
• Support for vtkVariant, vtkTimeStamp, and vtkArray.
• Overloaded method resolution for based on C++ semantics.
• Automated arg conversion via constructors based on C++ semantics.
• Formatting of in-line documentation for python, including some doxygen tags.
• Clean-up of the code, removal of all global variables from the code.

In addition, the following improvements have been added for all wrappers, including Java, Tcl, and the ParaView ClientServer:

• A cleaned-up parser front end that understands much more C++ syntax.
• Proper string support in all wrappers via vtkStdString.
• Significant code clean-up (but not as much as for Python).

All of this is on top my earlier change to vtkParse that replaced all the hard-coded hexidecimal constants from the code and replaced them with clearly-named constants.

More information on the changes can be found on the VTK wiki. There are more wrapper improvements that I will be merging in the future. I have already written a vtkWrapHierarchy tool to improve type checking in the wrappers, which will finally eliminate the need for BTX/ETX markers in the header files. I've also added a page to the VTK wiki for all the enhancements that I have planned for VTK/Python, but I'm not sure how many enhancements I will have time to complete.

SimITK 0.2.2 has been released! This release adds the ability to watch the transform parameters converge while the registration is taking place, plus a few important usability fixes. The SimITK project is a collaboration between myself and others at Queen's University and UBC to provide a Simulink interface to ITK, in order to facilitate image analysis within the MATLAB/Simulink environment.

SimITK Image Registration Model

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.