We just released IceSL online. If you enjoy solid modeling (CSG) and 3D printing, don't miss it! You can directly model with code (in lua!), customize objects (in real time!) and generate G-code from your web browser.
From a technical point of view, IceSL online was quite an endeavor. Imagine taking a state-of-the-art GPU modeling and slicing engine, that by the way requires OpenGL 4.2 to run, and now squeeze it into a WebGL 1.0 javascript engine...
... Errr?
That's also how I felt the first time the thought occurred to me: no way! But well, who does not like a challenge :-) It turns out WebGL 1.0 is more or less at the level of what was available back in 2004-2006 when I was a PhD student and postdoc. And at the time, I had quite some fun with GPU programming. Only, 2016 GPUs are much much more powerful. This is a perfect situation for a complete abuse of good old-school OpenGL GPU programming!
And this is what made IceSL-online possible. It is a new engine, yet it shares many (most) core algorithms with IceSL (the new version, not yet released) and SliceCrafter (slice STL files online).
I am hoping to find the time to describe how it works -- nothing ground breaking for experts, but it is quite fun. Even possibly a bit novel. In any case, I hope you'll enjoy using it!
Of course it has limitations compared to the desktop version and it will not support large designs, but most of my models work just fine in it. I have already made several projects, and it is super convenient to fire up the web browser, customize or model a little something and directly get the G-Code for a quick print. I am also hoping it can be a good educational tool, to learn programming and 3D printing.
Stay tuned for upcoming features, and please spread the word!
Thursday, December 8, 2016
Friday, August 5, 2016
[3dprint] hierarchical rhombic infill
Rhombic infills are both strong and fast to print. If you are using IceSL, you probably already have seen these patterns as they have been the default infill for the past year. I also did a number of experiments with a hierarchical version of a rhombic infill. However, the question of how to select the subdivision level depends on the target application.
A recent article by Wu and colleagues explores interesting ways to subdivide a rhombic infill to strengthen objects, for instance using a finite element simulation to subdivide weak areas in priority. This increases the density of the structures locally to obtain stronger parts.
Beside their good properties (self supporting and mechanical strength), rhombic infills are also very efficient to generate and print. Our web based slicer, SliceCrafter, includes an improved rhombic infill that prints very fast because it only uses 45 degree angled print paths (an idea suggested by IceSL user Maze Mietner). Try it out!
A recent article by Wu and colleagues explores interesting ways to subdivide a rhombic infill to strengthen objects, for instance using a finite element simulation to subdivide weak areas in priority. This increases the density of the structures locally to obtain stronger parts.
Beside their good properties (self supporting and mechanical strength), rhombic infills are also very efficient to generate and print. Our web based slicer, SliceCrafter, includes an improved rhombic infill that prints very fast because it only uses 45 degree angled print paths (an idea suggested by IceSL user Maze Mietner). Try it out!
Wednesday, June 15, 2016
[3dprint] Plastic deposition flow control in IceSL
IceSL has a nice feature to control plastic flow that I never took the time to explain.
There are several ways to produce the toolpaths for plastic deposition, and some of them result in paths that can slightly overlap : if you were to follow the paths with a thick marker, some places would receive color twice. Well, the same happens with plastic resulting in overflow! The reason a slicer might want to do that is to avoid the opposite: leaving a gap. IceSL tends to squeeze more paths within a slice so as to reduce some of these gaps (it is not perfect though, as some thin walls are still problematic).
While often small, if such overflows occur always at the same place across layers, they will accumulate and result in bad looking 'bumps' (or worse, the nozzle will collide with the part).
The 'flow' module of IceSL takes care of this. It uses OpenGL rendering tricks and follows the path with the virtual equivalent of a marker. Only, in each pixel it counts how much color (plastic, really) is deposited. If this amounts exceeds the target, it tunes down the extrusion rate so has to avoid overflow. This works quite well in practice! I believe this could also be used for SLA / laser engraving where 'beam energy' can also accumulate more than desired (the beam footprint is not an exact dot, but rather a small circle).
The two images at the end of the post show a slice before flow optimization, and the same afterwards. The grayscale levels indicate a reduction of the plastic flow ; they are especially visible in the thin areas (you might have to zoom in to appreciate the changes.
Now is this the best way to do this? Possibly not ; geometry analysis of the path thicknesses could be faster than the brute force GPU approach -- which is also quite approximate.
I am currently exploring better ways to limit gaps and overflows in IceSL. Stay tuned!
There are several ways to produce the toolpaths for plastic deposition, and some of them result in paths that can slightly overlap : if you were to follow the paths with a thick marker, some places would receive color twice. Well, the same happens with plastic resulting in overflow! The reason a slicer might want to do that is to avoid the opposite: leaving a gap. IceSL tends to squeeze more paths within a slice so as to reduce some of these gaps (it is not perfect though, as some thin walls are still problematic).
While often small, if such overflows occur always at the same place across layers, they will accumulate and result in bad looking 'bumps' (or worse, the nozzle will collide with the part).
The 'flow' module of IceSL takes care of this. It uses OpenGL rendering tricks and follows the path with the virtual equivalent of a marker. Only, in each pixel it counts how much color (plastic, really) is deposited. If this amounts exceeds the target, it tunes down the extrusion rate so has to avoid overflow. This works quite well in practice! I believe this could also be used for SLA / laser engraving where 'beam energy' can also accumulate more than desired (the beam footprint is not an exact dot, but rather a small circle).
The two images at the end of the post show a slice before flow optimization, and the same afterwards. The grayscale levels indicate a reduction of the plastic flow ; they are especially visible in the thin areas (you might have to zoom in to appreciate the changes.
Now is this the best way to do this? Possibly not ; geometry analysis of the path thicknesses could be faster than the brute force GPU approach -- which is also quite approximate.
I am currently exploring better ways to limit gaps and overflows in IceSL. Stay tuned!
Sunday, January 31, 2016
[icesl] Things to do with IceSL: Arcade bartop!
After an exciting but somewhat stressful SIGGRAPH deadline I allowed myself a little fun and decided to use IceSL to model and laser cut (and 3D print) a complete Arcade bartop :-)
Here is the design in IceSL:
This is of course powered by a Raspberry Pi 2, running RetroPie. I went for Sanwa hardware ; no regrets, the buttons and joystick are indeed super nice. I use a small USB pad emulator board to plug the joystick and buttons -- but it seems GPIO pins could be used as well. The screen is a HDMI TFT panel, size 10.1 (ref LP101WH1), which has a reasonable resolution of 1366x768 -- but there are many other models out there, I picked this one based on price/availability. For the sound I took apart a pair of Logitech Z130 speakers (50mm diameter, fits nicely).
I learned quite a few lessons building this. The 3D preview in IceSL has been incredibly useful, as well as the ability to interactively move things around. I used 3D models of all electronics so that I could check for a proper layout and avoid collisions between the different parts. Nevertheless, I got a few things wrong mostly because I did not model the plugs (USB, HDMI, power) and these take *a lot* of space. This is the second prototype I made, the first one had a few issues and required some manual work to adjust. This one was taken right out of the cutter bed and assembled without requiring any drilling or gluing (everything tightly fits together).
I model all planks in their cutting position (thickness along Z), and define for each a transform to place it in the final 3D model. For instance the pad board is named 'pad_board' and its transform is 'pad_board_T' (just a matrix). To cut the board I use 'emit( pad_board )', whereas to display it in the final model I used 'emit( pad_board_T * pad_board )'.
To create the finger joints I model only one side on one board and then use the following trick, e.g. between the left side board and the floor board:
side_L_board = difference( side_L_board , inverse(side_L_board_T) * floor_board_T * floor_board )
If you are not familiar with 3D matrices and transforms this may be a bit tricky to understand. 'side_L_board_T' is the transform (matrix) that puts the side board in position in the final model. Thus, inverse(side_L_board_T) is the matrix that moves everything back to the side board cutting space ; as if the entire final model was rotated to lie on the left side. Thus, writing 'inverse(side_L_board_T) * floor_board_T * floor_board' means that the floor board is first placed in the final model (by matrix floor_board_T) and then rotated back to the side (by matrix inverse(side_L_board_T) ). This is when I subtract the floor board from the side board. This effectively carves the connectors (from the floor board) out of the side board. By following this method you can easily model all connectors while being sure they will match. Another example of the power of CSG :-)
I still have a few things to add to finalize the bartop: external USB/Ethernet plugs, and most importantly an independent power supply (it requires three power plugs!) and of course paint and stickers. But for now, let's play some retro-games!
Here is the design in IceSL:
Of course it is fully parametric! It can easily be adapted to screens of different sizes, other joysticks and buttons. The bartop is quite small, I wanted something that would nicely fit on a table and not look bulky.
Here is a transparent 3D view and an exploded view in IceSL:
And the final result!
All parts are laser cut using G-code produced by IceSL, using the 'laser' profile (gcode is sent to a smoothieboard driven CO2 laser cutter). This is using 3 mm plywood.
The insides of the 'beast':
This is of course powered by a Raspberry Pi 2, running RetroPie. I went for Sanwa hardware ; no regrets, the buttons and joystick are indeed super nice. I use a small USB pad emulator board to plug the joystick and buttons -- but it seems GPIO pins could be used as well. The screen is a HDMI TFT panel, size 10.1 (ref LP101WH1), which has a reasonable resolution of 1366x768 -- but there are many other models out there, I picked this one based on price/availability. For the sound I took apart a pair of Logitech Z130 speakers (50mm diameter, fits nicely).
I learned quite a few lessons building this. The 3D preview in IceSL has been incredibly useful, as well as the ability to interactively move things around. I used 3D models of all electronics so that I could check for a proper layout and avoid collisions between the different parts. Nevertheless, I got a few things wrong mostly because I did not model the plugs (USB, HDMI, power) and these take *a lot* of space. This is the second prototype I made, the first one had a few issues and required some manual work to adjust. This one was taken right out of the cutter bed and assembled without requiring any drilling or gluing (everything tightly fits together).
I model all planks in their cutting position (thickness along Z), and define for each a transform to place it in the final 3D model. For instance the pad board is named 'pad_board' and its transform is 'pad_board_T' (just a matrix). To cut the board I use 'emit( pad_board )', whereas to display it in the final model I used 'emit( pad_board_T * pad_board )'.
To create the finger joints I model only one side on one board and then use the following trick, e.g. between the left side board and the floor board:
side_L_board = difference( side_L_board , inverse(side_L_board_T) * floor_board_T * floor_board )
If you are not familiar with 3D matrices and transforms this may be a bit tricky to understand. 'side_L_board_T' is the transform (matrix) that puts the side board in position in the final model. Thus, inverse(side_L_board_T) is the matrix that moves everything back to the side board cutting space ; as if the entire final model was rotated to lie on the left side. Thus, writing 'inverse(side_L_board_T) * floor_board_T * floor_board' means that the floor board is first placed in the final model (by matrix floor_board_T) and then rotated back to the side (by matrix inverse(side_L_board_T) ). This is when I subtract the floor board from the side board. This effectively carves the connectors (from the floor board) out of the side board. By following this method you can easily model all connectors while being sure they will match. Another example of the power of CSG :-)
I still have a few things to add to finalize the bartop: external USB/Ethernet plugs, and most importantly an independent power supply (it requires three power plugs!) and of course paint and stickers. But for now, let's play some retro-games!
Subscribe to:
Posts (Atom)