Hi Sean, You are absolutely right that it would be the best solution to completely avoid export to STL for 3D printing and to make a direct export to g-code instead. But I am afraid that it would take very very long time and BRL-CAD might meanwhile miss a great opportunity for attracting new users and new developers from explosively expanding 3D community, which could in turn rapidly auto-accelerate the BRL-CAD development. 3D printers are becoming so cheap and their use so simple that they will soon be considered as normal household appliance like PC or laserjet today. It will create millions of new CAD users, which, like me, will soon want to move from the "kindergarten CAD" like SketchUp, 123D or Tinkercad to something more powerful but still free. For them to stick to BRL-CAD, they will require these three things:
1. User friendly GUI. BRL-CAD has a notorious image in the CAD internet community as very mature and powerful extraordinary solid modeler but with a terrible user interface "like from the 1980s". If the first-time users do not find the easy graphical editing, visualization and manipulation features they are used to from "the kindergarten CADs " they will quickly move to try alternative CADs like FreeCAD, OnShape or Fusion. 2. Good STL import/export. The 3D printing users have available millions of existing models in STL from the internet repos or their own past work which they want just slightly modify in the CAD and export in STL to a slicing software they are used to (Sli3er, Simplify3D, Cura). The same is true for new models they make directly in the CAD, they do not have a need for avoiding the slicing software they know. 3. Easy-to-follow video tutorials are today´s must for attracting newbies. They will first be looking for simple-to-understand YouTube tutorials to see what they can practically expect from the software before installing it. People are simply too lazy to read written tutorials today (TL;DR). If the BRL-CAD community has a goal to attract more users and developers from the "new" 3D community, these three points should be the highest priority for the current BRL-CAD development, IMHO. If I can daydream a perfect CAD for 3D printing and more, I would love to see this combination: 1. Mature mathematical and geometrical background and raytracing of BRL-CAD. 2. Easiness of SketchUp GUI for graphical manipulation, editing and visualization. Best if written in Qt as a mainstream platform known to a large amount of developers. 3. Project tree structure and direct object parametric editing of FreeCAD (or SolidWorks or Inventor). 4. Editable from-beginning-to-end complex code-based parametric modeling of OpenSCAD, replacing current "command-enter" CLI of BRL-CAD, for more advanced work. I hope that I do not sound too negative or naïve, I really started to love mged more and more with every tutorial I already followed :) I am just little bit pity that such nice system like BRL-CAD would become undiscovered by 3D printing community only for missing the user friendliness they are used to. Best regards, Mike -----Original Message----- From: Christopher Sean Morrison [mailto:brl...@mac.com] Sent: Tuesday, November 15, 2016 12:51 AM To: BRL-CAD Developer Mailing List <brlcad-devel@lists.sourceforge.net> Subject: Re: [brlcad-devel] Newbie to BRL-CAD > On Nov 14, 2016, at 1:21 PM, Michal Hanus <mikeha...@seznam.cz> wrote: > > In my opinion, BRL-CAD does not have to replace the slicing software, > which is quite complicated and specialized. Direct g-gcode export > would thus not be necessary for 3D printing. An error-free export > g-stl would be enough for using BRL-CAD with any type of a 3D printer. Mike, it’s very true that BRL-CAD does not have to replace the slicing software. I don’t see BRL-CAD having good gcode export or direct printer integration soon also, as you noted there are other tools that do this already. Consider, though: there is not any CAD system that guarantees error-free STL export. There’s not even one that does an exceptionally good job at it. Pro/E, NX, CATIA, etc, all fail, often spectacularly for seemingly simple cases. The general rule of CAD is to not move between systems and if you must, to avoid format conversions too. Longer-term, CAD software is in a far better position to slice as that is where the actual geometry resides. Everyone reads STL because it’s simple, not because it’s good. Converting from CAD geometry to STL invariably results in errors (e.g., invalid geometry due to new overlaps). A primary reason STL took off for 3D printing (aside from makerspace hobby coders being able to implement STL easily) is because printer resolution was far more coarse than triangle tessellation errors. That’s quickly changing with the latest printers. For BRL-CAD, we still need to strive for some of the best polygonal export regardless, so getting STL robust is still needed. The best option for that is to finish our NURBS Boolean evaluation project. There’s a great doc in our repo detailing how to sort through the remaining issues, and that should give us the best possible export capability. Separating and cleaning up our NMG library and replacing its Boolean evaluation support with a different implementation is a close second. For absolutely robust, a point sampling approach based on ray tracing might take the cake near-term. Alas, they all need investment of effort. :) Cheers! Sean ------------------------------------------------------------------------------ _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel ------------------------------------------------------------------------------ _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
