Distance Transform

Distance function visualized through a gyroid volume. Solid red and blue are uncalculated inside/outside areas. Gradients are distance from the surface. Otherwise I thought it just made a cool animation.

This forms the core of applying surface effects at a specific distance. You could hollow a model > some distance from the surface or you could apply a pattern up to some distance on the surface to make it more interesting. Check out DistanceTransformExact.java for the code. We’re working on more optimized versions as well but this class forms the basis for unit testing other approximations. When we get the library level done then we’ll expose this at ShapeJS.


Posted in Uncategorized | Leave a comment


One of the main goals of the AbFab3D toolkit is to make it easier to create 3D printable objects. As a Java toolkit it’s only going to reach a limited audience(cue Venn diagram of Java programmers with graphics programmers). The web has gone crazy over Javascript as its scripting language. Say what you will about its shortcomings as a language but you can’t fault its uptake numbers. There are many more people out there interested in making 3D printed objects that know Javascript then Java. This brings us to today’s post topic, ShapeJS. We’ve written an application that executes Javascript code using AbFab3D as the backing library. This type of language binding is very common in the game world. You provide an easy to program language that level editors can script game behaviors. This makes creating a game much more accessible and allows many more creative minds to help with the project.

The ShapeJS language provides a powerful system for generating 3D printable objects via a simple Javascript program. Shapeways is hosting a development environment where you can edit ShapeJS scripts, execute them on a server and then view the results in your browser using WebGL. When your happy with your model you can print it Shapeways or download the model for yourself. Here’s hoping this deployment environment is easier then writing a bunch of installer code for Java applications. Been down that road several times and don’t want to repeat it.

We’ve made a bunch of examples to show how to create some cool 3D printed items.
ShapeJS Examples

I have a feeling that someone soon is going to make a creator that’s a break out hit. Let’s define a hit as a million in revenue. So far no creator I’ve seen has made it near that mark. But the time is ripe and the market is expanding fast. There are a few gems in the examples which I think might qualify. I can tell you that dice and jewelry have been extremely popular at Shapeways.

The final piece you need to make these into your own creators is a way to execute the ShapeJS scripts in response to your own user interface. We’ll be putting out examples soon which will show you an easy and inexpensive way to deploy these to cloud providers such as Amazon. Stay tuned!

I’d also like to mention an early user, Leon Nicholls who’s made a cool riff on the project. Currently it doesn’t support color information. He’s made a colorizer that can add colors after the fact. This is a nice way to add color to your models. We’ll get around to adding color support but for now I thought I’d pimp he’s system: Colorized ShapeJS.

Posted in Uncategorized | Leave a comment

Voxel Sculpting

We’ve continued to hone the volume sculpting code. We recently added the ability to have GyroidGradients. These gradients allow you to modify the gyroid properties along the object space. A real world of example of this would be in reducing the cost of a 3D printed item while maintaining its strength. In this first picture we have a structural member that’s completely solid. It’s volume is 2.63 cm^3 and it’s area is 14.16 cm^2.


In this second version we’ve intersected a Gyroid with the Box. This lowers the total volume while increasing the area. This version using an uniform gyroid has a volume of 0.32 cm^3 and an area of 20.90 cm^2. This is a great savings in costs and it looks cool. In fact with the greater surface area you’d find this object cools much more rapidly.


In the third version we’ve started to use the GyroidGradient. The gradient is set to double the frequency of the gyroid by the time it reaches the end of the object. Notice how both of the ends are more dense. You’d use this if you needed to strengthen the ends of the object while keeping the main member light. This object has a volume of 0.36 and an area of 25.95.


The last object has the frequency doubling at 1/4 the object size. In this case we’ve significantly strengthened the ends. The volume is 0.67 and
the area is a whooping 59.73. In terms of cooling capacity this object would shed heat considerably faster then the original object and it
weighs and costs about 1/4 of the original.

As we move into multiple material 3D printers you’ll be able to change individual voxel material properties as well. AbFab3D will give you
individual control of each voxel you print with.


All of these sculpting patterns can be found in the abfab3d.grid.op.VolumePatterns class. They also include new implementations of Lidinoid, Schwarz, Enneper, Scherk patterns.

In addition to new Volumetric space filling patterns we’ve been extending the symmetry engines. We’ve added a Plane and Sphere symmetry group that can be added to a GridMaker pipeline. See DevTestSliceWriter for some examples such as hyperBall. These two pictures show you the fun you can have with symmetry and voxel spaces. You can make some really cool objects with this type of system.


We’ve been getting some requests for more end-user level usage of AbFab3D. We’re considering adding a scripting language that could setup GridMaker pipelines. This would allow you to rapidly create 20-30 line programs that make really cool objects. Definitely pulling a card from OpenSCAD if we go down that front. If that interests you drop a comment so we know it’s desired.

Posted in Uncategorized | Leave a comment

Multi-threaded Scaling

We’ve been doing a fair bit multi-threaded testing and optimizing. In theory voxel graphics should scale nearly linearly to the number of cores. That said you never know to break out the benchmarks and prove it. The following graph shows the scaling factors for a few of the operations. The first item, PureCPU is a scaling test of just a set of float operations. The machine we used us an Amazon AWS cc2.8xlarge instance. This contains 16 cores with hyperthreading turned on. We max out at 20X faster then single threaded. Not perfect scaling but a fairly nice speed up. The erosion operation is fundamental to a bunch of voxel algorithms and it scales up to 13.6X faster. Subtraction is a boolean subtraction and it scales to 14.8X. When we implement a multi-threaded version of a an operation it get’s a MT appended to its name, such as SubtractMT. The original operation is unit tested against the multi-threaded version to make sure they give the same result.

Thread Scaling

Thread Scaling

So far we have multi-threaded versions of the morphological operations Erode and Dilate, the boolean operations of Subtract and Intersect and the core GridMaker and voxel to triangle classes. Over time we’ll migrate the rest of the operations over as we use them in projects.

We’ve also been playing around with some fun voxel space operations. The following screenshot shows a volumetric sculpting example. This object is created by intersecting a sphere with a volumetric gyroid function. The goal is to make it easy space fill objects with regular patterns. This allows you to change the looks and material properties of your items. You could make an item cheaper to print, more flexible or change how it distributes heat.

Volume Sculpting

Volume Sculpting

Here is another example, a solid shoe model that’s been made much more interesting and cheaper to print.

Volumetric Shoe

Posted in Uncategorized | Leave a comment

AbFab3D 1.0 is Released

We’re happy to announce that AbFab3D has reached its 1.0 milestone goals. The codebase architecture changes have settled down, the unit tests are in place and its starting to feel like a usable codebase. Took longer then I hoped but that’s software development for you.

The main architectural changes are a refactor of the Grid interface to explicitly separate voxel state from per voxel attributes. We know over time we’ll want to hang more data off each voxel but we also want to make implementing memory efficient grids easy. The original Grid interface has been split into two interfaces: Grid and AttributeGrid. An attribute grid layers on the concept of per-voxel attributes. These attributes could be 3d printing material information, normals, colors, whatever you’d want to store there. As time goes on we’ll leverage those attributes on the exporters to communicate better with printers.

A good example of using that information is this visualization we did for showing wallthickness and hole size visualization. Green are areas safe to print, red are too thin and purple are holes which might close during printing.


The other core changes are centered around exporting from Voxels to Triangles. We’ve spent a lot time improving its quality and ability to handle large grid sizes. Below is a beautiful example of exporting a fractal image using AbFab3D.


Vladimir Bulatov created this 3D printed object using AbFab3D. It’s the limit set of a discrete symmetry group of 4 dimensional hyperbolic space. If your interested you can order a copy here: Shapeways Model

From here we will be concentrating on a couple areas. We’ll be doing a hard multiprocessor pass on most of the core functionality. One of the promises of voxel graphics is the ability to easily throw multiple processors at a problem. Tests so far look promising that it works to least to 4 processors with linear scaling. In addition we’ll be improving the Triangle to Voxel routines, concentrating on quality of voxelization and multiprocessor speed.

Fun stats, the codebase is now 142K lines of code. Test coverage now at 23% which is dropping, time to get back into the testing habit.

Posted in Uncategorized | Leave a comment

Where are we headed?

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.

Recent Additions

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:
AbFab3D Forums


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.

Posted in Uncategorized | Leave a comment

Voxel Fonts

A common request to customize 3D objects is the ability to engrave, emboss or make stand-alone text.    Previously I’ve done this with triangle based text and it turned out to be a pain.  The code paths for subtracting text where very different to engraving.  Boolean subtraction operations in triangle space are much more complicated then in voxel space.  In addition the vectors for some fonts cross each other and sometimes have zero area which complicate the triangulation process.

Creating voxel spaces from a font is just an extension of the ApplyImage code I discussed in my last post.  Java makes creating images from fonts easy.   You select the font, its size and style and then render to a Graphics2D object.  You can then use this image to create a voxel space using the ApplyImage operator.  With that voxel space you can either use it stand alone to create an object or use the Subtract or Union operators to get engraved or embossed text.

Here is an example of stand-alone text:

You can find this example in the apps/lettering directory.

Posted in Uncategorized | Leave a comment