normandc wrote:Sean, what you said about BRL-CAD is very intriguing. Did I understand correctly, 10 man-years are put into developing BRL-CAD every year?
I assume some companies (or government agencies?) are financing BRL-CAD's development?
Yes. Development was initiated and has continued uninterrupted since 1983 (technically since 1979). Some prior years varied but we've measured increasing year-over-year activity since 2004 when BRL-CAD was converted to an open source project. In all, about 300-600 man years directly invested, depending on how and what you count (but not counting our 3rd party developers and dependency developers).
Aside: one of BRL-CAD's claim to fame is having the worlds oldest open source repository that has been under continuous development. Beats out GCC and GNU Emacs by just a bit.
normandc wrote:Like others I installed BRL-CAD in the past and was at a loss to do anything with it. FreeCAD is more along what I am used to in my field of work (traditional parametric 3D CAD paradigm introduced by Pro Engineer more than 25 years ago and made more accessible by SolidWorks).
We recognize that limitation. BRL-CAD's interface usability is terribly complicated for a someone downloading for the first time. Our professional users get professionally trained. The system wasn't designed to be discoverable/explorable. "You're gonna have a bad time." It's been described in the past as an expert system for experts.
After going open source, usability became a greater priority for obvious reasons but it takes time to upgrade a big city with inhabitants. Towards that end, we've predominantly invested in our core infrastructure changes that support usability (like hybridization). Our existing customers don't care about interface so much, so time is still divided and some changes take longer than we'd all like.
Thanks for sharing. I don't know that I've seen that before.
jriegel wrote:GCode is to simple to make a lib of
more interesting is the whole CAM stuff, but thats also lot of Gui stuff and kernel dependent - hard to share, but a possibility.
A CAM connection is why I mentioned GCode, actually, since neither system is really geared for it. GCode itself is simple enough but can be incredibly complicated with the right requirements. For example, how to fill the interior of a solid model for 3D printing where you REALLY don't want to fill all of the interior with your expensive ABS. Maybe you want some special honeycomb pattern or perhaps you want to automatically add snap-off support structures so it doesn't all collapse into a sad mess while cooling. If a lib supports CNC routes, what drill paths should be taken, when should bits be changed, what bits are supported/available? Maybe "gcode meta lib" would have been more apropos. I could see much getting encoded into a reusable library or set of libraries.
jriegel wrote:Which lead to question. Your future plan list shows the point ramping up hybrid design. I think you have some kind of BRep data structure already. The big question is; Do you really want to develop a own BRep data structure and the algorithms there fore?
We're already there. We adopted the openNURBS library for BREP/NURBS representation support. That's the Rhino3D library which they put out to encourage 3DM format adoption. We picked it up and extended it (an understatement) for our more elaborate purpose. We've since implemented most of the hardest algorithms that they stripped out (NURBS ray tracing).
jriegel wrote:I know what man-power Matra invested into CasCade or Dassault into CNext (kernel of CatiaV5+) and I don't think a FOSS project can replicate that.
I disagree whole-heartedly. I honestly believe it's possible to rally dozens of man-years around an open source kernel that is actively-developed by the open source community (not any single company). I know guys on the core devs teams for a number of the commercial products and their 100-1000 person development teams are formidable. However, the same could be said of the compiler landscape just 15 years ago.
One of our long-term objectives is to create a stand-alone geometry kernel that is viable replacement for acis, granite, parasolid, cnext, etc. Raw capability-wise, we're actually almost there.
jriegel wrote:Do you consider using OCE/OCC? Or do you have a general problem with LGPL?
OCE/OCC is well known, but that's an involved discussion for another day. Most of my issues with it are philosophical and historic, not technical. I believe the open source community can do better.
jriegel wrote:Most CAx FOSS projects out there have chosen OCC as the backbone. There are fore example HeeksCNC, Netgen, IFCOpenShell, Salome and many more.
Lack of alternatives doesn't make it a good or bad choice, just the only option available to them at the time. More power to them regardless. We need more open source CAD activity, not less. If we can collaborate, I think we'll all get to where we're respectively trying to be more quickly.
jriegel wrote:Our interface to OCC is very thick. We use hundred of classes, so its nearly impossible to rip it out and replace it by the BRL-kernel.
I measure changes in how many years it might take a competent developer. Hundreds of classes sounds like one, maybe two. Heck, our STEP bindings are more complicated than that. Our NURBS work... oof!
By the way, our motto is simply "Open Source Solid Modeling". We've gone to great lengths to extricate ourselves from our military legacy beyond screenshots and legacy documentation. Our new website set to be unveiled soon should make that even more clear.
Good talking. For the purposes of GSoC, I'm going to shelve this collaboration for now but hope we can keep the discussion going. My near-term goal for now is to work towards faithful export/import between our systems. STEP will likely achieve that, but we can see where we're at after this summer.
If you know of any starving students contributors that want to do computer graphics coding all summer, remind them that Blender, BRL-CAD, and possibly others are participating in GSoC. Better than a student campus job.
Cheers!
Sean