2014 Google Summer of Code

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
jmaustpc
Veteran
Posts: 11207
Joined: Tue Jul 26, 2011 6:28 am
Location: Australia

Re: 2014 Google Summer of Code

Post by jmaustpc »

keithsloan52 wrote:I found this blog comparison of BRL-CAD and FreeCAD http://blog.fridoverweij.com/20_3_2013_CAD.php

He seems to have given up early :( on FreeCAD because of the lack of the assembly module.
Roll on 0.14 going GA
I think he's an idiot, if you read what he has said it doesn't make sense on many levels. It looks like he spent 5 minutes with FreeCAD and yet days just learning BRL-CAD's basic operations.

Perhaps he could have spent 5 minutes working out what is wrong with this computer that caused FreeCAD to crash....

Did you notice that he didn't even quote what version of FreeCAD 0.13 he used.

He also had a spelling mistake.

Look at the date 20 March 2013,

He wont use FreeCAD because it doesn't have an Assembly module ...yet he spent a few DAYS just trying to work out how to operate BRL-CAD because its GUI is so bad that its almost non-existent.

look at what he had to do to get an STL.

Look at the flue and fly wheel, the curves look like a low resolution triangulated mesh, the edge of the flue is stepped.

He doesn't even mention cross platform or Linux, he's totally focused on Windows.

Not a fair, reasonable, professional or even rational article.

Honestly very disappointing, because I would seriously like to know what BRL can do, what it is good at and what advantages it could offer a user.
User avatar
NormandC
Veteran
Posts: 18587
Joined: Sat Feb 06, 2010 9:52 pm
Location: Québec, Canada

Re: 2014 Google Summer of Code

Post by NormandC »

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? :shock: I assume some companies (or government agencies?) are financing BRL-CAD's development?

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).
keithsloan52 wrote:I found this blog comparison of BRL-CAD and FreeCAD http://blog.fridoverweij.com/20_3_2013_CAD.php

He seems to have given up early :( on FreeCAD because of the lack of the assembly module.
Roll on 0.14 going GA
I find it quite exasperating when people dismiss FreeCAD because of lack of an Assembly module. Assemblies can already be made in FreeCAD. AutoCAD, the ubiquitous 2D/3D CAD software from Autodesk, does not include an "Assembly module" yet millions of designers and engineers build assemblies with it. :roll:
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: 2014 Google Summer of Code

Post by jriegel »

Hi Sean,
thanks for the information, now the picture is much clearer!
STEPcode is more than enough in my opinion, but any shared import or export linkage would be a win. Anything we could turn into a common library is a possibility (e.g., 3D PDF, 2D geometry lib, GD&T lib, GCode lib, etc). Ideally, something that can be licensed as openly and future-proof as possible (e.g., bsd/mit/apache2).
That would be possible. I intend anyway to contribute my work on the STEPCode python Part 21 parser back to STEPcode in its BSD license. 3D-PDF is very problematic. I think already declining. Adobe sold it, and it uses with ASIS-bin a very problematic format for BRep. We had some way to export triangles and using pdfTex to generate 3d-PDF (triangle mesh representation - the older 3Dpdf format), but basically very problematic for a FOSS project. 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.
Not true. AP214 and AP242 have full support for CSG, but we still convert to Brep as needed and focus on AP203 (thanks to GSoC and other funded efforts). We have a STEP AP203 importer beta working now. We're in the middle of implementing an exporter, scheduled to be completed by the end of summer.
Thats technically true :) but I doubt you will find a lot STEP files in the wild which use the CSG objects.
Do you know if one of the big CADs can read CSG elements?

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? 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. Do you consider using OCE/OCC? Or do you have a general problem with LGPL?

If you using OCE/OCC we will have a lot of connection points. I could even think of reading Step CSG elements and transfer it into BRep (which opens a migration route for you old projects toward BRep modelers).

Talking about STEP we have to separate two things. The first is the transfer of geometry, which at the moment we use the OCC facility. OCC has a pretty good translator there, including healing and model tolerance control. There are other FOSS projects which transfer geometry, e.g. BRL-CAD or IfcOpenShell, but I would regard them as not so complete and tested.
But the other thing is the "other" information in a STEP file, like product structure, release labels, dates and checks, version information, and many more. This are informations easy to transfer, but very Application dependent. Here it depends on what the interpreting application has models and work-flows for the specific information. E.g. we have a Architectural workbench which can be feeded with IFC STEP file. There fore I intend to use the STEPCode python binding, which allow transfer the high level stuff via simple python scripts...

I don't think I'm familiar enough with FreeCAD to answer that with due justice, but our strengths are in conversion formats, geometry representation (there's not much we cannot represent implicit or explicit, NURBS, meshes, volumetric, etc), and geometric analysis (e.g., ray tracing for analysis and other CAE purposes). Conversion seems obvious. Modularizing your use of OpenCASCADE so we could explore putting BRL-CAD under your hood in the future also comes to mind, but I realize that may be heresy to this crowd.
Mhh, that mainly depends on your choice of kernel. Most CAx FOSS projects out there have chosen OCC as the backbone. There are fore example HeeksCNC, Netgen, IFCOpenShell, Salome and many more. That are all projects we can share code with. And if not code, then bug-fixing and feature improvement of our mutual CAD-kernel. 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.
Most of the best showcase material on BRL-CAD cannot be publicly shared. I can say that there is a full model of nearly every military asset (foreign and domestic) that has been fielded in the last 50 years (i.e., hundreds of exceptionally detailed down-to-the-nut-bolt-and-wire models). BRL-CAD is actively used by a number of governments. It's the best in the world in a few critical areas. Gladly share more over a glass of Scotch (or beer/wine if that's your thing).
Ok, then I think I know the main purpose of BRL-CAD was/is used for. Actually not quit my turf. I use to think our main customer is the Tinkerer and Maker or in the long run small businesses. Actually I know some guys in our community which won't like it. Especially your motto ;)

I know there's quite a chasm between our communities (and I'm sure mutual misunderstanding), which is the point for reaching out to see if we can at least start a dialog. If not this year, perhaps next year under a foundation.
Yea :) I hope we doing better from now on. Sometimes you stuck so deep in your own project that your view becomes a bit narrow ;)
Stop whining - start coding!
User avatar
cblt2l
Posts: 155
Joined: Sat May 15, 2010 3:59 am

Re: 2014 Google Summer of Code

Post by cblt2l »

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).
Same here for me. I usually play with the new releases but can't really ever figure out how to go beyond modeling simple shapes. I did once use the wheel generator (which is pretty nice) to make a part for 3d printing but that is about the extent of it. I would like to play around with some of the different analysis tools that are supposedly integrated (FEA, Ballistics, etc) but there is pretty much no documentation on how to do this.

The brlcad site has some pretty awesome renderings in the gallery. I wonder if its feasible to use brl cad for external rendering in the raytracing workbench?
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: 2014 Google Summer of Code

Post by jriegel »

Using an other CAD modeler for RayTracing ;) interesting use-case...
Stop whining - start coding!
jmaustpc
Veteran
Posts: 11207
Joined: Tue Jul 26, 2011 6:28 am
Location: Australia

Re: 2014 Google Summer of Code

Post by jmaustpc »

Sean
It's the best in the world in a few critical areas.
Is there any chance you could elaborate? I am interested for myself, but it would also be good to know if BRL can do something that FreeCAD can't, so we could direct anyone asking for that functionality to BRL. :)

Jim
brlcad
Posts: 8
Joined: Thu Jan 23, 2014 8:05 pm

Re: 2014 Google Summer of Code

Post by brlcad »

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? :shock: 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.
keithsloan52 wrote:I found this blog comparison of BRL-CAD and FreeCAD http://blog.fridoverweij.com/20_3_2013_CAD.php
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
brlcad
Posts: 8
Joined: Thu Jan 23, 2014 8:05 pm

Re: 2014 Google Summer of Code

Post by brlcad »

jmaustpc wrote:Is there any chance you could elaborate? I am interested for myself, but it would also be good to know if BRL can do something that FreeCAD can't, so we could direct anyone asking for that functionality to BRL. :)
Jim, there are two areas in particular where we're fairly unparalleled. Geometry representation and geometric analysis via ray tracing.

Our ability to represent exceptionally complex geometry representations efficiently in a variety of formats is central to our design. There are many models that our modelers will open up in Pro/E or NX only to watch it churn for a half hour before ultimately crashing or only partially loading. Think big industrial models.

Those same models open up in full detail with BRL-CAD's libraries pretty much as fast as the data can be read from disk into memory (i.e., instantly). If it's implicit format geometry, things get even better as disk I/O is rather optimized per object too.

We also particularly well with exceptional scale and detail. For example, BRL-CAD was used to model the CERN supercollider when it was first being conceptualized because it was the only CAD system at the time capable of correctly modeling the 17 mile span with submillimeter accuracy everywhere. Several other commercial engines have since caught up, but we're still one of the best at it.

Probably BRL-CAD's strongest feature is solid ray tracing. We've invested more time and effort than anyone I know of in verifiable and validated geometric analysis, and we do it fast.

Basically, this is answering the question of "what geometry is along this path?" Not just the first surface hit like you would with optical ray tracing (rendering images), but evaluating all hits along a ray and knowing with 100% certainty where you enter and exit geometry (i.e., a crack-free solid representation). We inspect grazing-hit behavior with close scrutiny for consistency, repeatability, correctness. We obsess over regression tested behavior spanning decades of activity.

This is all critically important for analysis and simulation codes. BRL-CAD's libraries are used to drive a number of them.

Performance-wise, I've personally run ray-trace comparisons with the evaluation engines in Pro/E, NX, and some others, and we outperform most by several orders of magnitude. A typical case might involve shooting a few million incoherent sample rays at a 2GB detailed solid model, getting your answer in less than a second. And these are not simple polygon models. And we still put effort in every year to make it all go even faster.

There's other areas were BRL-CAD excels, but those are particularly engrained in the implementation, design, and development methodology. Hope that elaboration is helpful.

Cheers!
Sean
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: 2014 Google Summer of Code

Post by tanderson69 »

brlcad wrote: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.
Ok, I am listening! Any pointers for exploring the brep geometric capabilities of the brl-cad api?
brlcad
Posts: 8
Joined: Thu Jan 23, 2014 8:05 pm

Re: 2014 Google Summer of Code

Post by brlcad »

tanderson69 wrote:
brlcad wrote: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.
Ok, I am listening! Any pointers for exploring the brep geometric capabilities of the brl-cad api?
Appreciated, but that's quite an involved topic and far beyond GSoC collaboration. You're welcome to explore the code or ask on one of our communication channels if you're really looking to dive in now, but I'm honestly not looking to poach devs. Plus, I feel that's a big enough project that someone would need to take point, write a plan, and involve others.

My responses (besides dispelling misconceptions about BRL-CAD) were to just share that we do, in fact, have much more potential together than we do apart. There's certainly a time and place for having that discussion and I hope we will over the upcoming year.
Post Reply