2014 Google Summer of Code

[NormandC]

Hello Sean,

Thank you for spending time explaining BRL-CAD's features. It seems that if you're willing to get past its arid UI (and manage to learn it ), it has a lot to offer.

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).

Does that mean that you also support importing files in 3DM format?

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.

This is exciting. An alternative geometric kernel to OCCT would be a very good thing for open source.

If you're not aware, the FreeCAD devs work on it in their spare time, I don't believe any of them is sponsored. In the last year around 10 people have been contributing. I would be surprised if more than 2500-3000 hours in total are spent on FreeCAD every year. And I may be generous (care to comment on that ballpark figure, guys?) So switching from OCCT to BRL-CAD kernel would really be a huge project for these guys.

I've often times read Dan Staples (dir. of Siemens PLM's Solid Edge product development) mention that switching from the ACIS kernel to Parasolid had been a huge job.

[ickby]

Hello Sean,

thanks for explaining, a very intersting read! Also BRL has a very impressive development speed, at least in commits per month you are 10-15 times ahed of freecad. Never realized that so much work is going on on your system. I do belive the two projects do target quite a different audience, however, this makes it eve more interesting to think about collaboration.

One thing I would like to see is file interoperability beyond step. The thing is, Step only has the geometry, but no information on how it was created. therefore we can only use it in freecad as dump bgeometry block (don't know about brl cad though). Both our systems support elaborate desing capabilities, and i wounder if we should work on a direct converter, from your databases to freecad files and back. This would make it possible to get editable elements and preserve the modeling operations. And the operations not supported by one the other software can still be incorporated as dump data.

[jriegel]

Hi Sean,

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.

Ok, thats a very special niche you have there. Besides high energy particle physics, radar perception and nuclear explosions I know no use-case for engineering? I work in the automotive field and our main simulation instrument nowadays are FEA.

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).

Uhhh, why the hell openNURBS!? Its just a proprietary data structure for importing/exporting. It has no algorithms at all. And import/export STEP and ray tracing are not the hard algorithms you would need for a FOSS BRep modeling kernel. You need all boolean operations (hard), offset on non trivial geometry (really hard), fillets and chamfer on non trivial geomtry (very hard), draft angles on non trivial geometry (hard) and many many more. OCC have all these, and the STEP converter also (a very good one I might add). So IMO you have still a long way to go for basic stuff OCC/OCE already has. OCC has now a liberal license (LGPL) is very actively developed and has a strong community arm (with OCE, Salome, Netgen,....).

So thats my main puzzlement, why do you go so separate ways to the rest of the FOSS CAx community? Do you have DARPA funding and not allowed to use something from the French? Or is the LGPL the problem? I saw you going mainly for MIT,BSD and Apache.

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.

Yes your right, I believe that too. But for me this kernel is OCC! You sold me no reason why not.

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.

You consider OCC not as open source? Why? I know, the French company is sometimes special, but since the LGPL switch and the appearance of the OCE project (fork) I would consider OCC/OCE fully Open Source. BtW the Debian guys and the Red Hat lawyers have the same opinion....

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, "Solid modeling for strong defense" is a bit hard to digest in the rest of the world

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.

Yes, enough of words I agree fully with you, interesting discussion and I hope it goes on.

What I summarize for me:

1) Supporting another FOSS CAD-kernel (yours) is IMO not a option. Too far behind and no real benefit to see... (sorry)

2) I know now some of strong points of BRL-CAD, and will send gladly people your way which seek that stuff. Actually we had some particle physicist on the forum which asked exactly for what you offer!

3) I see BRL-CAD more as a simulation tool (like Calculix or OpenFoam) which I would like to support.That means mainly:

a) read your legacy data CSG STEP files and build up a FreeCAD feature group which result in the the same (BRep) model (like we do it with OpenSCAD). That would give you a migration path of your legacy CSG data into BRep. You can say what you want, you will have to abandon your CSG heritage. I don't think your defense industry models the new weapon systems in BRL-CAD. They will use Catia, Pro-E or NX and you will get Brep STEP files to simulate.

b) make sure the data exchange of models works really good (via STEP-BRep). I don't know how many post-processing BRL-CAD is offering, but your simulation capabilities in that field are very valuable and - indeed - unmatched!

I don't know how far you want to go building up your actual modeling. In that field we are practically competition. If asked I would suggest you leave the modeling to us and concentrate on your unique capabilities in large scale solid raytracing! Thats a pretty good field in itself! You will get your simulation geometry anyway from a BRep modeler the one way or the other. Not even the insane money in military projects will pay in the long run for modeling a weapon system twice!

So, thats MY opinion. Our community has maybe a different one. Again apology if I was rude.

Jürgen

[brlcad]

Does that mean that you also support importing files in 3DM format?

Yes, in fact our in-memory representation is actually openNURBS format too. A 3DM import is literally "pack this 3DM data into our file". We use their routines to read/write the data and their API for interpreting/creating/modifying geometry. That let us focus on the critically harder pieces we needed (ray tracing, solid tessellation, surface-surface intersections, etc).

One thing I would like to see is file interoperability beyond step. The thing is, Step only has the geometry, but no information on how it was created. therefore we can only use it in freecad as dump bgeometry block (don't know about brl cad though). Both our systems support elaborate desing capabilities, and i wounder if we should work on a direct converter, from your databases to freecad files and back. This would make it possible to get editable elements and preserve the modeling operations. And the operations not supported by one the other software can still be incorporated as dump data.

STEP is the union of all CAD formats. It does have the "capability" of representing information on how geometry was created, it's just whether a particular CAD vendor actually decides to export that information or create the elaborate structures required. That's similar to jriegel's comment about CSG support -- AP214 supports CSG and many vendors support AP214, but some don't handle those entities, some do. So if you really want to be interoperable with a number of systems, you end up needing to implement a lot of conversion structures.

I like your idea of a faithful round-trip conversion path between FreeCAD and BRL-CAD. I think that's probably the best easiest way to foster interaction in the short term, regardless of any other agendas or issues.

Cheers!
Sean

[brlcad]

Ok, thats a very special niche you have there. Besides high energy particle physics, radar perception and nuclear explosions I know no use-case for engineering? I work in the automotive field and our main simulation instrument nowadays are FEA.

Astute observation. There actually are many other use-cases for engineering, but that's too involved to get into. Our libraries are often used as a much faster alternative to the FEA method by a many 3rd party analysis codes. The use-cases for those codes span the gamut.

Its just a proprietary data structure for importing/exporting. It has no algorithms at all. And import/export STEP and ray tracing are not the hard algorithms you would need for a FOSS BRep modeling kernel.

The data structures of openNURBS is no more proprietary than OCC's data structures, and the quarter-million lines of code involved for importing/exporting/creating/manipulating BREP/NURBS has saved inordinate amount of time. The magnitude of effort and level of expertise required to implement crack-free solid NURBS ray tracing easily dominates everything else and has been our top priority. Remember the niche.

It's taken many years of full-time expert effort (seriously, a multimillion $ effort). It's not like there was an implementation or good research papers to follow. Most of what you can find, we had a hand in. Some of the commercial CAD provide NURBS ray tracing, but none published their method. Just little tidbits here and there, some academic demos (that have no practical robustness or are dog slow). As far as I know, we're the only robust open source solid NURBS ray tracer available now.

It's also not all algorithms. STEP involves no hard algorithms, but is a data management hell. STEP is an incredibly complex conceptualization for geometry. Not hard, but complicated and very time-consuming (years). We got STEPcode whipped into shape, and now it's even beating out the PDES reference implementation used by several CAD engines in several areas.

OCC have all these, and the STEP converter also (a very good one I might add).

Perhaps just a rumor, but I heard the OCC folks are looking into integrating STEPcode to replace their custom parser.

Yes your right, I believe that too. But for me this kernel is OCC! You sold me no reason why not.

My intention is not to sell or convince you (or anyone else) of anything. I'm happy to provide some background information and respond to your comments to help paint a picture, but it's okay if we disagree. We have our needs and interests, you have yours, and I think that is perfectly fine. I still think there are ways to collaborate and accelerate our respective developments.

You consider OCC not as open source? Why? I know, the French company is sometimes special, but since the LGPL switch and the appearance of the OCE project (fork) I would consider OCC/OCE fully Open Source. BtW the Debian guys and the Red Hat lawyers have the same opinion....

OCC wasn't formally LGPL until ... 6 weeks ago? You keep raising that point, but it's not clear to me how that's relevant. FAQ says 6.7.0 released mid-Dec 2013. We started our NURBS ray tracing and STEP import efforts circa 2006. Even if OCC had been relicensed BSD back then, there are other substantial integration issues that we would have had to resolve (all secondary to our goals) and it would have required a comprehensive cost-benefit analysis (which I do for every major effort we undertake).

I do think the company behind OCC is "special" and that's unfortunate. Paviot's OCE work is very commendable. I respect his efforts greatly and appreciate the value amongst the open source community. If I were considering switching to OCE, I would be concerned that he forked from the pre-LGPL 6.5.0 version but there's probably some back story there.

I don't think your defense industry models the new weapon systems in BRL-CAD. They will use Catia, Pro-E or NX and you will get Brep STEP files to simulate.
...
Not even the insane money in military projects will pay in the long run for modeling a weapon system twice!

You underestimate the defense industry's ability to spend money.
No military system is developed with just one CAD system. None.

I don't know how far you want to go building up your actual modeling. In that field we are practically competition. If asked I would suggest you leave the modeling to us and concentrate on your unique capabilities in large scale solid raytracing!

Open source competition is a very good thing (especially when they collaborate). Moreover, I've actually heard a notion from users several times that they want our backend with FreeCAD's front end. Not suggesting we do that, but it's certainly not impossible.

Our community differences are akin to the variation amongst some of the major commercial CAD vendors, like NX vs Pro/E. BRL-CAD is sort of like Unigraphics. FreeCAD is sort of like Pro/E. If the communities were ever somehow forcibly merged, it'd look a lot like CATIA. Very related and similar capabilities, but some fundamental differences. It's all good.

Cheers!
Sean

[cwstirk]

@ickby
to elaborate on brlcad's comment on parametrics.
Modern STEP schemas contain information about how the model was created. Specifically, the STEP AP's 203ed2 and 242 schemas contain construction history and parametric constraints.
http://citeseerx.ist.psu.edu/viewdoc/do ... 1&type=pdf
However, I am not aware of any production use of this capability because different CAD systems use different parametric representations that are not 100 percent translatable. The http://www.macro-parametrics.org team has created a set of standard modeling commands and mappings to/from commercial CAD systems, but once again, there is not 100 percent coverage. Commercial feature based translators exist, for example
http://www.transcendata.com/solutions/proficiency/
but these tools need to be used with quality checking and fixing tools to fill gaps and repair errors.

@all
A workflow from FreeCAD modeling to BRL-CAD analysis, as others noted, would be useful. It is also possible that analysis like FEA could be performed in parallel off of an OCC or other representation. The analysis could drive modification of the geometry to improve analysis results. Thus, a translation from BRL-CAD back to FreeCAD and/or OCC could be required.

Improving the BRL-CAD and FreeCAD translators for STEP is one way to enable these workflows. FreeCAD lacks conformance with STEP external references, material identification, user defined attributes, etc. BRL-CAD needs these capabilities as well as an exporter. Alternatively, one could attempt to map the construction history and parametric constraints and use that to develop a direct or indirect translator, but I doubt that it would be 100 percent.

BRL-CAD uses STEPcode, and FreeCAD is investigating using it for higher-level data along with the OCC translator for geometric shapes. (FYI, I have been in contact with the OCC team, and they would be interested in using STEPcode if it provided them improvements with large files. Paviot from OCE said that he would be interested in comparing the speed and memory handling with STEP files.) In STEPcode, there are several areas that can be worked on that could benefit both FreeCAD and BRL-CAD such as

• a common library that works with the widely used CAD STEP AP's (203/214/242),
  improved translation speed and memory usage,
  tools to assist STEP translator development (EXPRESS-G editor, STEP file to schema validation, test file libraries),
  support for new STEP AP242 capabilities such as PMI, tessellation, kinematics or composites, or
  work-flows to exchange material and density info, user defined attributes, or analysis info (with AP209ed2).

Any of these would make a good GSoC project.

[jriegel]

Hi cwstirk,

its always a pleasure to read you insightful posts.

Actually I'm not interested in conformance test. Its only a method for one company to rip of money from an other company!
As a good tradition I will use our community to test import/export from hell knows how many other CAD systems to iron out errors in the implementation.

Regards OCC, yea, it has a bit dated Part 24 implementation, and if they replace it by STEPCode would be great. But what I'm mainly interested in a CAD-kernel is the Part 42! Transfering the gometry into the kernel data structure with error checking, healing and model tolerance control is a important facility of a CAD-kernel and hard to do for an application programmer...

The rest, transferring the other entities added in the various APs , is our responsibility. No CAD-kernel can do that job, cause it do not have the models and classes for higher level concepts described there. I will start that soon for the Assembly portion, that includes also some of the shortcomings you mentioned. I plan to split the reading process, as mentioned before, in a low level process in C++ (geometry done if possible by the kernel) fairly hard coded and high level for the rest completely done in python and there fore easy to customise... Will see how it turns out.

Your right, transporting modelling history via STEP is practically non existent. But I would make a exception for BRL-CAD If they would be able to write out the CSG tree of their legacy data, it would be pretty cool to translate it in a FreeCAD feature tree.

@sean

There actually are many other use-cases for engineering, but that's too involved to get into. Our libraries are often used as a much faster alternative to the FEA method by a many 3rd party analysis codes. The use-cases for those codes span the gamut.

You have to have a different gamut but even better! If you have a big use-case base and a lot applications using your capabilities.

It's also not all algorithms. STEP involves no hard algorithms, but is a data management hell. STEP is an incredibly complex conceptualization for geometry. Not hard, but complicated and very time-consuming (years). We got STEPcode whipped into shape, and now it's even beating out the PDES reference implementation used by several CAD engines in several areas.

It is, if you use openNURBS most modern CAD-kernels (as OCC and CNext) are basically STEP compliant on geometry level (that's what I meant with openNURBS data is proprietary). So if you look through the code, its basically parameter transfer and a lot of sanity checking and tolerance control. So you would have saved some of your millions by using the right CAD-kernel But that's all history, as you mentioned. You have to decide at some point. I decided for OCC 2001 when OCC was released into the open source and the FreeCAD project started some month later...

[brlcad]

BRL-CAD uses STEPcode, and FreeCAD is investigating using it for higher-level data along with the OCC translator for geometric shapes. (FYI, I have been in contact with the OCC team, and they would be interested in using STEPcode if it provided them improvements with large files. Paviot from OCE said that he would be interested in comparing the speed and memory handling with STEP files.) In STEPcode, there are several areas that can be worked on that could benefit both FreeCAD and BRL-CAD such as...

Thanks for the update and task ideas, Charlie. I'd only heard some of that in passing. I'm making sure we have several prominant STEPcode tasks this year, so hopefully we can get a few strong applicants.

It's also not all algorithms. STEP involves no hard algorithms, but is a data management hell. STEP is an incredibly complex conceptualization for geometry. Not hard, but complicated and very time-consuming (years). We got STEPcode whipped into shape, and now it's even beating out the PDES reference implementation used by several CAD engines in several areas.

It is, if you use openNURBS most modern CAD-kernels (as OCC and CNext) are basically STEP compliant on geometry level (that's what I meant with openNURBS data is proprietary). So if you look through the code, its basically parameter transfer and a lot of sanity checking and tolerance control. So you would have saved some of your millions by using the right CAD-kernel But that's all history, as you mentioned. You have to decide at some point. I decided for OCC 2001 when OCC was released into the open source and the FreeCAD project started some month later...

This makes no sense. The transfer of STEP data into/from openNURBS was trivial, "basically parameter transfer" as you put it with some checks. Certainly didn't take millions of lines of code (our entire system minus external deps is roughly 1M LOC total). Moreover, we weren't shopping for a CAD kernel; we have an extensive highly optimized one already. What we needed was a BREP/NURBS container better than one we already had, which openNURBS provided.

If ACIS had been available under a viable open source license, it still would have been a completely different cost-benefit evaluation that wouldn't have directly addressed our requirements and analysis objectives. Our NURBS ray tracing capability was still priority, one-to-two orders of magnitude harder, and more costly to implement.

Cheers!
Sean

[yorik]

This discussion is really interesting... With IFC also, it would be pretty interesting to capture such modeling history, or design intent