My 3d DLP printer software Monkeyprint software seems to gain momentum. Recently it was tested by 3d desktop printer manufacturer Aleph Objects Inc., resulting in some nice improvements and bug fixes!
When I first published Monkeyprint I wasn’t sure if open source was the right way to go. For quite some time, nobody seemed to use the program, which was mainly because of it’s beta status, some bugs, missing features etc. And to be honest, if I were looking for a stable, out-of the box DLP printer software, I wouldn’t have used it as well, simply because it wasn’t ready.
However, things changed in the last months; Monkeyprint is maturing due to the G-Code support and the prospect of a Windows version. Another very positive aspect that reassured me in my decision to go open source was a recent collaboration with Colorado based 3d printer manufacturer Aleph Objects Inc.
They started testing Monkeyprint DLP using an Autodesk Ember DLP printer (see some print results below) and, when bugs came to light, actively contributed to the project by providing fixes and pushing them into my Github repository. That’s how open source can work: people working together from all around the world to make better software!




Monkeyprint DLP now with VTK 6 support
Youness Alaoui, a freelance software engineer contracted by Aleph Objects was assigned to the testing and made a major contribution. As he uses the 3d visualization library VTK 6 on his development system (as opposed to VTK 5 currently implemented in Monkeyprint) he immediately started to port Monkeyprint to VTK 6 — an issue that had been opened some time ago but which I never found the time to solve. So, Monkeyprint now runs with VTK versions 5 and 6. Thanks Youness!
No more slicer crashes
Another issue were crashes during slicing. They didn’t happen very often on my machine as my test model (mainly the Blender monkey head that I provide with Monkeyprint) had been pretty small — which reduces the number of slices and therefore the possibility of crashes. This made it very hard to debug for me…
Aleph Objects developer Nicholas Tait however thought bigger. For testing he used a pretty detailed Eiffel tower model in combination with a layer height of 0.01 mm — resulting in about 8800 slices. This crashed Monkeyprint almost every time. Youness suggested a race condition between slicer threads and with this info I managed to fix that issue. Since then, Monkeyprint didn’t crash during slicing even once.

Memory usage during slicing and slicer speed
The large Eiffel tower model with its 8800 slices also lead to a different problem: huge memory usage during slicing. In fact, slicing the Eiffel tower with an XY-resolution of 800 x 800 pixels resulted in about 12 gigabytes of memory eaten by Monkeyprint within seconds — which will cause a system with less RAM to freeze instantaneously.ย I didn’t find this bug because I never used large models like that and also didn’t opt for the insane Z-resolution of 0.01 mm ๐ The fix for this issue is currently in development: the cure is to simply cap the number of preview slice images using a user definable amount ofย memory. With the maximum number of preview slices fixed, the preview layer height will simply be increased accordingly to fit larger models. The full resolution print slices with the actual print layer height will be saved to disk instead.
During this development I’ve also just found a different method of generating the slice images resulting in a speed-up of the slicer. In the current version some slices with lots of details in the Eiffel tower take about 8 seconds to generate using the current approach (based on VTK) — which is insane. However, slice generation time can be reduced by my new code (using OpenCV) to as little as 0.06 s. That’s a factor of 133! The new code will be in the next release when the memory issue is solved as well.

Open source for the win!
Well, I’ve been skeptical of open source before but, as the last weeks have shown, it provides great possibilities! Getting in touch with professional developers was a cool new experience for a hobbyist programmer like me. And more importantly, I’ve learned that shared development can simply lead to better software faster. So going open source definitely was the right choice for me. Thanks Aleph Objects ๐
If you like this (or if you don’t), comment below and subscribe to be notified about the next updates on Monkeyprint DLP!
Best,
Paul
hello, u are not alone and his initiative by the software was great, I’m always watching her work. Now I’m developing my SlaLCD printer and would like your permission to use the software in MonkeyPrint mimha machine.
Send feedback for e-mail
Tank’s
hello, u are not alone and his initiative by the software was great, I’m always watching her work. Now I’m developing my SlaLCD printer and would like your permission to use the software in MonkeyPrint my machine.
Send feedback for e-mail
Tank’s
Hi Michel,
thanks for your nice comment!
Of course you have permission to use my software. If you finish your machine, I’d be happy to receive some pictures to post them here!
Good luck with your printer build,
Paul
Your Software looks really nice , I’m currently using NanoDLP ( on RPI 3) , I was looking for a more robust slicer and also support generation . I wold like to know if Monkeyprint would run on a RPI 3 ? and also if there’s a way to save job to SLC file or Zipped PNG ?
Many thanks for your work !
Hi Olivier,
thanks a lot for your comment!
Regarding your last question: at the moment it is possible to export slices as png files. It would be easy to zip them and export the zip file if that’s more convenient.
The SLC file is a bit trickier as it consists of polyline data for the slice contours. The tricky part is that internal and external contours are ordered oppositely so I’d have to identify which ones are internal and which are external. If SLC file export is an important feature for you, please open an issue on my github and assign the feature request label and I will look into it…
By running on a Raspberry Pi I guess you mean as a standalone host accessible via network? Unfortunately, that feature is not quite ready yet. If you manually transfer an mkp project file to your Pi, access it via ssh and run Monkeyprint with the –server option an the file name it will run the print job. However, I’d suggest waiting for the next release that will solve a memory issue in the slicer, otherwise large models will crash your Pi due to its small memory.
Sorry if everything is a little confusing, I still have to do a proper documentation…
If you have further questions, feel free to post them here!
Best, Paul
Paul, any chance to get a Mac Version of Monkeyprint in future?
Regards
Gerd
Hi Gerd,
there should be a Mac version along with the Windows version that I started working on using Qt as an alternative GUI toolkit. However, this might take a while as I’m totally busy with some slicer redesign I’m releasing soon… I think half a year might be a good estimate.
Meanwhile, did you try running Monkeyprint on Mac?
Best,
Paul