What is the current state of Netfabb?

[armstrom 0]

I see a lot of people frustrated with bugs in Netfabb, but I also see that they recently released an updated version. What's the general consensus with regard to the cost/benefit of Netfabb? I recently ordered an ultimaker with the standalone controller so I plan to do most of my prints from SD card anyway... Would Netfabb be worth the 150 euro cost? Or are there still too many bugs?

-Matt

[IRobertI 520]

I bought Netfabb with my printer and it improved my first prints tremendously (tried with skeinforge initially). However, a lot has changed since then when it comes to the free alternatives. I'd say first try out the free alternatives such as cura which is a front end to Skeinforge which aims to make things easier for beginners. There's also Slic3r and Kisslicer and of course stand alone Skeinforge. If you're happy with any of those, great, you just saved some money. If not, give Netfabb a try.

Sure, there might be a bug here and there (although I personally don't have any problem in 99,9% of cases) but no one can argue that it produces great Gcode, works fast and offers other benefits like the great GUI and so on.

The biggest issue IMHO is the lack of volumetric slicing (which supposedly is coming in the next version) which means you might have to spend a bit of time on calibration. But, of course the wonderful community has come up with something for that as well. ddurant has made a nice little program that essentially turns netfabb volumetric, you can read about and download it here.

I haven't personally regretted spending the money on it at all.

Maybe not the definitive answer you were hoping for but I hope it helps you make a decision.

[Daid 306]

Few reactions I had on my free Cura package in regards to NetFabb:

 

(after donating 20$, thanks!) Hi Daid, Cura has made my life so much easier because it just makes a lot of sense configuration-wise And using my Ultimaker is now fun! I wish I hadn't paid for Netfabb...otherwise I could send you more! I didn't get much use of netfabb and it cost $200!, apart from repairing meshes...

 

Ive been playing with your software today, a new experiance for me as I have only ever used NF for slicing before. I liked the experience and it was aster than i expected. If it had been around last July I would probably not have worried about purchasing a copy of Netfabb and saved myself some hard earned cash.

 

In fact I've used nothing but Cura and haven't even touched Netfabb or RepG, I cant see any reason to. So thanks again and keep up the good work.

I do not own NetFabb myself, so I cannot tell you how good it is. But when I started my idea was "I'll try with the free software first, and if that doesn't work I can always buy NetFabb". I think NetFabb comes as a download with license key, so there is no shipping time for it.

[armstrom 0]

Yeah, my concern with the free software packages is the slow slicing time. I plan to produce a variety of parts, some will be fine to just slice at normal 0.1 - 0.2mm layer heights so free software will work well for that (planning to use Cura since it seems to be very well regarded). However some of the parts I want to print will require a finer surface finish so the faster slicing combined with the half-height outer layer feature of netfabb seems to be what I need.

I will never understand why products like Skeinforge are built in interpreted languages like Python. As a software engineer with 11 years experience in the 3D measurement/CAD world I understand how processor intensive cross-sectioning and tool path calculations are. I understand the JIT compiled PyPy runtime helps a bit, but I can't help thinking this could use a port to C/C++ and perhaps some GPGPU optimization.

I hear Slic3r is significantly faster than Skeinforge but has other problems that make it less than ideal... Hmm... I guess I'll start with Cura and keep an eye on Netfabb to see if they resolve some of the issues in the next release.

Thanks for the feedback guys!

-Matt

[Daid 306]

With Cura, my 6-8 hour prints slice in 10-15 minutes. (Note, Skeinforge by default is about 4x slower then Cura!)

Slic3r indeed is faster, but that also largely depends on your object. Some objects slice 100x faster, some only 30% faster. Slic3r looks VERY promising, it has a few of the heavy math core function in a C++ library.

Skeinforge is a dying horse. It's build around string parsing and bad design. It's not even that Python makes it slow, it's the design that makes it slow. The guy that made it had no clue about how to write fast code. There is some Bresenham line drawing code in there that I optimized, it used 3 function calls and a lot of math per pixel. My optimizations ended up in SF36, which made that version about 40% faster. Even now, I'm not sure why there is line drawing code in there, but it used heavily.

I think in a few more months or so, Slic3r is where is should be, stable. When it is, Cura will use Slic3r as back-end instead of it's own brand of Skeinforge.

The problem with GPGPU is that it's hard. Most people working with 3D printing right now are not real software wizards. So something more hackable like python is pretty useful then.

[armstrom 0]

Yeah, I'm hoping once I get my printer and start working with it on a regular basis I will become motivated to contribute to some of the software projects out there. Perhaps work on a slicer of my own. GPGPU stuff is getting much easier with some of the new libraries. If you try to code directly for Nvidia CUDA or ATI's Stream API things can get complicated. Especially if you want to support both. But with OpenCL and Microsoft's DirectCompute things are starting to become more standardized. It's the same old stuff all over again Remember back in the early days of 3D gaming there were many competing standards. Direct3D was just starting to appear, OpenGL had been around for a while but was mostly relegated to university projects and high-end graphics workstations. Back in the mid 90's 3Dfx Glide API ruled the cutting edge gaming world. But then everything started to coalesce around a more mature OpenGL API and microsoft's DirectX. Same thing is now happening with GPGPU today. It's an exciting time

-Matt