[3dprint] adaptive slicing and color mix

Some more thoughts on color mixing... One obvious thing to do is simply to slice adaptively, switching colors between layers. For instance, to get 70% of black and 30% of white, simply slice a 0.07 layer of black and then a 0.03 layer of white (thickness to be scaled depending on desired layer height). That is trivial to do in most slicers. Of course, to generate a spatially varying pattern in XY you need to change the slicing heights within the slice (in the XY plane), but this has been proposed before and does not seem too difficult to implement.

... maybe I should just try that!

[3dprint] More gradient examples

Two more examples of filament gradients. The slope -- in particular in overhang regions -- slightly changes the perceived color. The first model uses a linear ramp, while the second model uses a sine wave along the Z direction. I started experimenting with gradients along XY, first tests look promising.

[3dprint] filament gradients

I have been working on a way to blend two filaments together to achieve smooth gradients along a print surface. It is not perfect yet, but here is a brief description of this idea.

When working on our 'clean colors' technique, we made the observation that alternating layers of two filaments would produce different gradients of colors along the sides of the object. What happens is that the filament closer to the observer has more impact visually, than the one slightly behind. Interestingly, this paper made the exact same observation and came up with a very interesting way of depositing filaments to mix colors.

Starting from the same observation I came up with a different idea. Instead of changing the geometry I play with the flow of plastic. I do not alternate filament each layer but instead, at each layer, I deposit plastic twice (once for each filament) with a different flow of plastic. The two flows add up to 100% and by changing the percentage of each deposition you get different blends of colors. It is important though to always start by the filament having the highest percentage. What happens is that you get 'big' and 'small' cross sections of filament. And of course, the big one becomes more visible.

This works quite well and has interesting properties:
- the layer height is unchanged
- there is no change to the geometry of the print
The main drawback is that this requires carefull calibration to align the heads. This can be done in software by printing calibration tests. I have done initial experiments with spatial variations, but I yet have to explore this further. I am also curious to see what happens when doing this with soft/hard filaments and filaments of different properties.

If you experiment with this please let me know! If that works well enough we will include this feature in IceSL.

[3dprint] new CURA engine

I just had a look at the new CURA engine code:
https://github.com/Ultimaker/CuraEngine

Nice, elegant C++ implementation. Internally it relies on Clipper, a fast library to perform operations on 2D polygons. That is an excellent choice: Intersecting each 3D triangle with the slice plane produces a bunch of segments. The segments are then linked back together to form polylines and 2D polygons. The Clipper library is used to compute polygon offsets, creating the perimeter and shells.

Now I have to work hard to make IceSL as fast :) There are quite a few places where large speed ups are possible, so we'll see.

[3dprint] IceSL: Model, slice and print without intermediate meshes

Short story: Model objects through a CSG language inspired by OpenSCAD but based on LUA with real time pixel-perfect CSG (with transparency) and direct slicing. Yes, this is both the modeler and slicer in a same package - no output mesh, only G-code. Small catch: you need a recent NVidia GPU (supporting OpenGL 4.2 ; Series 4 or above).

Download:

http://webloria.loria.fr/~slefebvr/icesl/

Long story: When I first discovered hobbyist 3D printing thanks to the great community around RepRap and derivatives, I was looking forward to modeling and printing my first objects. What's more, I had heard about OpenSCAD, where shapes are described by CSG operations between meshes and basic primitives. CSG (Constructive Solid Geometry) is good for modeling solids, because instead of worrying about a surface mesh you can focus on adding and subtracting matter. Modeling through scripting is also very efficient (reuse) and well suited to describe mechanical parts. It seems Makerbot and Thingiverse users largely agree.

However, what surprised me is how difficult the whole process was: The real-time rendering of OpenSCAD does not always succeed -- fast CSG display with basic OpenGL is no simple matter -- and sometimes the shape displayed on screen is very different from what it should be. When hitting the "Compile mesh" button you have to wait for a very long time before getting the final mesh. This is problematic since you are never quite sure that you positioned your shapes properly, unless waiting for minutes -- and it makes small trial-and-error adjustments tedious. In retrospect, this is to be expected: OpenSCAD is designed to produce very clean meshes and relies on CGAL to compute exact mesh-to-mesh intersections (in spite of numerical errors). This is a smart choice because it guarantees the quality of the output, at the price of more complex and time consuming algorithms, but that is the right way to go when meshes have to be produced.

At the same time I was also stuck with another part of the process: The slicer. I mainly used Skeinforge through ReplicatorG. There are many, many settings which all make sense individually but are really scary for a beginner (which I am/was). Now, ReplicatorG does a great job at hiding things, but ultimately you want to dive deeper and tweak parameters. The result - for me - was lower print quality after hours of tweaking :-). Thus, I decided to look deeper into the problem and started implementing my own slicer to understand the intricacies of the process. I soon realized that the nice mesh computed by minutes of clever state-of-the-art CGAL algorithms in OpenSCAD was ultimately sliced into bits and pieces -- and in fact the large number of triangles only made matters worse when primitives such as cylinders or spheres were being used.

The whole process now seemed a bit wrong: A lot of processing power and complex algorithms are devoted to generating a perfect mesh, but its quality is in fact a total overkill for the slicing that later takes place. So, ... do we really need this intermediate mesh? It turns out you do not need to produce a mesh. Not at all: not for display, not for slicing. IceSL is based on this principle: It is an alternative to OpenSCAD tailored specifically for additive manufacturing. It uses the same code path both for on screen rendering and slicing. And it is made fast by using just a little bit of GPU magic (note: obviously this also gives high requirement for the user - but I am doing research in hardcore graphics, right? ;-) ). This is only a first prototype of this idea: It is far from complete, far from optimized, and lacks many important features (infill patterns in particular, supports as well), but I hope you'll already enjoy the ability to quickly visualize your objects and the relatively fast slicing. IceSL can slice STL files ; it is relatively fast for this but not the fastest (not yet ;-) ). However, it is really fast when slicing CSG models: No need to generate the STL! What is intriguing is that the software, internally, never has to deal with triangles -- in fact, the source code does not even contain a triangle class (apart from what is required to load and send meshes to the GPU).

The way it works is by first building a CSG description of the scene through a scripting language. For this I choose LUA, which is a very nice, easy to learn language. In fact, converting between OpenSCAD and the LUA scripts is not difficult at all -- I include a number of examples such as involute parametric gears. It then relies on a real-time CSG rendering algorithm, which is reused during slicing. So what you see, truly is what you print. Now, after computing bitmaps for each slices the tool path is computed -- this part is more similar to other slicers as far as I can tell.

It turns out my beginner's intuition was not exactly novel: I recently discovered that RepRap Host includes a similar strategy to directly slice from 'csg' files produced by OpenSCAD. As far as I can tell the main difference is that my pipeline relies on a single algorithm for display and slicing, and is therefore somewhat simpler: Meshes (as input) are treated as any other primitive. Btw, I recommend anyone interested in the topic to read through the code of RepRap Host (main author is Adrian Bowyer!). It is easy to read and the wiki does describe parts of the algorithm. It was great to read through it after doing my own, as I was happy to discover that for some parts I made similar choices (although I do not use marching squares for perimeters -- have to consider this). My code relies more heavily on the GPU and rasterization, but the basic principles remain similar. Another interesting prior work I recently discovered is this paper. If you know of other works, please post a comment ; I'd like to get a good landscape of existing methods.

Hope you'll find IceSL useful.

[3dprint] Joystick repair

This holiday season I decided we would play some of our Amiga favorite games, on the real Amiga!

I had a hard time sourcing working joysticks, however I found a few that were broken. This particular one had a stick broken beyond repair and one destroyed microswitch. I decided to turn it into a 1-button joystick, and to rebuild it with a 3D printer :-)

Here is the result. The final version is made of four pieces: the stick, the top button (articulated) and two pieces to fit the original screws. It was all printed using my own slicer on a Makerbor Replicator 1, with Sailfish firmware. The models were designed with Google Sketchup.

The most difficult part was to get the original microswitch to fit, as well as to design the top button so that it would rotate properly and hit the switch in the right place. In the end it only required two prototype prints to get all measures right.

It is not the most comfortable joystick, but it works reasonably well. I'll probably create another 2-button version with new microswitches.

If you like this kind of repairs, check out the full joystick print on Thingiverse!

[3dprint] Slicer

What's so special about this printout of thing #25644 ?

It's been sliced with my own GPU-accelerated slicer :-)