I want to give you a better idea of where we we are headed with this toolkit.
I’ll give you an overview of the project goals, the release schedule and some new
developments in the toolkit.
The toolkit comes from a need to move easily between triangle and voxel
representations. Recently I’ve found myself solving more problems
in voxel space instead of triangles. Some operations in voxels are just much easier
to code. The lack of topology concerns can really make some problems easier.
This has lead to the need to frequently change domains. AbFab3D is targeted at
developers that want to solve problems using both triangle meshes and voxel operations
In addition it contains a bunch of standard voxel operations. I looked around
for a Java based voxel library and didn’t find one that suited my needs.
One of the primary goals of the toolkit is to stay ahead of the 3D printing resolution
curves. 3D printers commonly use .1mm resolutions. A typical printed object is less
then 10cm so we’ll need 1,000 voxels in each direction. If someone wants to operate on
a model that fills the printer bed then we’ll need more like 10,000 voxels. Using
one byte per voxel would take a terabyte of memory. Clearly we’ll need some good
data structures to handle this type of voxel grid efficiently. A major part of the
architecture of this toolkit is allowing different data structures to be used without
having to change the rest of your code. Some data structures work very well for sparse
operations, others are really fast but chew memory. I doubt we’ll find one data structure
that will handle all conditions.
The other primary goal is to make it easy to implement voxel based algorithms. A large chunk of my day job is processing 3D models for printing. A lot goes into taking a model from a user and getting it printed. Most of those operations are best expressed as voxel operations. As I develop basic low level code for voxel processing I’ll put that code in the toolkit. I want it to be useful for general 3D programmers in a wide range of disciplines. In addition to 3D printing the toolkit should be useful for the medical and simulation communities.
Right now we are in the pre 1.0 release phase. I’d like to describe how I view this phases. In the pre 1.0 phase I consider the architecture under trial. I’ve sketched out basic interfaces I think will work for the domain. Those interfaces are likely to change over the coming months. Specifically the Grid interface and how it represents additional attributes is under review. I’ll mark the codebase 1.0 when I think there will be no major changes to the Grid interface. At that point you can expect stability out of the core library.
The other area that might entail some rework is in multi-threaded and hardware enhanced support. Currently I’m more interested in scaling by CPU’s then GPU’s. Mostly this comes from my need to run this code on the back-end of a busy website. The design should support throwing more CPU’s or GPU’s at a problem. I have doubts that it’s fully fleshed out yet. I’d like to prove this point for at least multiple CPU’s before calling the design 1.0.
The codebase is already in production usage at Shapeways. In order to keep production quality we have a full-time QA engineer helping with the project. Currently 30% of the codebase is test code expressed as JUNIT tests. Anyone checking in code must insure that the existing test code still runs. Already this has paid a huge benefit in allowing us the freedom to implement multiple Grid data structures. The existing body of tests really teases out corner problems in a grid.
Since Siggraph we’ve been very busy using the toolkit for several projects. I’d like to briefly detail what’s been added to the toolkit recently.
- ImageEditor – An example 3D editor using images to emboss or engrave a 3D model.
- Block Based Grid – A Grid inspired by the Field3D project. Best memory/speed performance grid so far.
- Erosion / Dilation – Common operations used on voxel grids for Shape Morphology
- Set Difference / Union – Common operations used on voxel grids
- Region Finding – Identify regions of voxel space based on connectivity and similar attributes
We’ve also been working on the open source infrastructure side. We have a new forum for support and discussions available here:
In the works are a new grid based on Ken Museth’s work on DB-GRID/DB+GRID. This looks to be a really fruitful way to express grids, possibly up to 10K voxels per side in reasonable memory. We also expect to add a voxel based Area Calculation and some other operators needed for Shape detection. Finally the triangle output methods we’ll be improved as we implement Marching Cubes and Dual Contour.
Stay tuned and get involved! We are actively looking for new developers on the project and want feedback from new users of the library.