OpenCascade Fillet Fiasco

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
wmayer
Site Admin
Posts: 16875
Joined: Thu Feb 19, 2009 10:32 am

Re: OpenCascade Fillet Fiasco

Postby wmayer » Thu Sep 10, 2020 10:03 am

1. FOSS development in OCC is driven mostly by paying customers and much less by the goodwill of the developers.
OpenCascade has a long list of paying customers: https://www.opencascade.com/content/trusted-industries
Is there really no one who asks for improved fillets?
The complexity of fillets (specifically) requires hundreds of man-days to maintain or (ideally) to rewrite from scratch (that's a legacy code inherited from Euclid).
According to https://en.wikipedia.org/wiki/Euclid_(computer_program) and http://ridwan.staff.gunadarma.ac.id/Dow ... -catia.pdf Euclid was bought by Dassault. In the referenced PDF it says:
Acquisition of Matra Datavision lab (Euclid)
So, is the problem that OpenCascade also lost its knowledge about fillets?

Btw, do you know how to use this overloaded version of BRepFilletAPI_MakeFillet:

Code: Select all

  //! Adds a  fillet description in  the  builder
  //! - builds a contour  of tangent edges,
  //! - sest the radius evolution law.
  Standard_EXPORT void Add (const Handle(Law_Function)& L, const TopoDS_Edge& E);
When I tried it with OCC 7.2 and 7.3 a few years ago it always raised an error. What at least worked was to sub-sample a given 2d curve curve and use this variant:

Code: Select all

  //! Adds a  fillet description in  the  builder
  //! - builds a contour  of tangent edges,
  //! - sets the radius evolution law interpolating the values
  //! given in the array UandR :
  //!
  //! p2d.X() = relative parameter on the spine [0,1]
  //! p2d.Y() = value of the radius.
  Standard_EXPORT void Add (const TColgp_Array1OfPnt2d& UandR, const TopoDS_Edge& E);
EDIT:
tanderson69 asked the same question in the forum but didn't get a reply so far: https://www.opencascade.com/content/bre ... awfunction
Jee-Bee
Posts: 2190
Joined: Tue Jun 16, 2015 10:32 am
Location: Netherlands

Re: OpenCascade Fillet Fiasco

Postby Jee-Bee » Thu Sep 10, 2020 10:32 am

According to https://www.opencascade.com/content/sal ... ware-suite
To satisfy these challenges, SALOME integrates a CAD/CAE modeling tool, industrial meshing algorithms, and advanced 3D visualization functionalities.
What i'm currious about. Salome have a( limited) CAD functionality too. Have anybody experience with that compared to FC.
If salome is able to do some stuff where FC isn't able to do... maybe there are options to work closer so FC can create some fixes...
User avatar
tanderson69
Posts: 1545
Joined: Thu Feb 18, 2010 1:07 am

Re: OpenCascade Fillet Fiasco

Postby tanderson69 » Thu Sep 10, 2020 11:22 am

wmayer wrote:
Thu Sep 10, 2020 10:03 am
Btw, do you know how to use this overloaded version of BRepFilletAPI_MakeFillet:

Code: Select all

  //! Adds a  fillet description in  the  builder
  //! - builds a contour  of tangent edges,
  //! - sest the radius evolution law.
  Standard_EXPORT void Add (const Handle(Law_Function)& L, const TopoDS_Edge& E);
I chased this down to: ChFiDS There are 2 things that confuse me about that function. First, it ignores the edge index into the contour. So the law is supposed to be applied along the whole contour? Second, The function creates a composite law and adds the passed in law to it. But then the composite never gets added to the object, so vanishes after function. The only object state change is the setting of 'splitdone' and the clearing of 'parandrad'.
wmayer
Site Admin
Posts: 16875
Joined: Thu Feb 19, 2009 10:32 am

Re: OpenCascade Fillet Fiasco

Postby wmayer » Thu Sep 10, 2020 11:54 am

It's a while ago that I tried the Law-variant but don't remember the details why it failed.

Currently when you add a variable fillet to an edge of a cube then the two curves are not straight lines.
Fillet_Cube.png
Fillet_Cube.png (9.96 KiB) Viewed 619 times
I tried to achieve this with a linear law function but it always failed. As an alternative I used the TColgp_Array1OfPnt2d where I set a couple of constantly increasing radii and this way I got it working: https://forum.freecadweb.org/viewtopic. ... 10#p188254
User avatar
Quaoar
Posts: 91
Joined: Thu Jul 27, 2017 11:56 am
Location: Nizhny Novgorod
Contact:

Re: OpenCascade Fillet Fiasco

Postby Quaoar » Thu Sep 10, 2020 12:19 pm

wmayer wrote:
Thu Sep 10, 2020 10:03 am
OpenCascade has a long list of paying customers: https://www.opencascade.com/content/trusted-industries
Is there really no one who asks for improved fillets?
Not many of them are developing part design software.
So, is the problem that OpenCascade also lost its knowledge about fillets?
To some extent, yes. It's similar to Booleans which were completely redesigned as we've seen a lot of need in that, so the knowledge was recovered. For fillets, it's still to happen.
FOSS CAD model inspection utility and prototyping framework: http://analysissitus.org
phoemur
Posts: 5
Joined: Wed Sep 09, 2020 4:57 pm

Re: OpenCascade Fillet Fiasco

Postby phoemur » Thu Sep 10, 2020 3:43 pm

I got plenty of errors like this:
Program received signal SIGSEGV, Segmentation fault.
#0 /lib/x86_64-linux-gnu/libc.so.6(+0x3be30) [0x7f0b97c13e30]
#1 0x7f0b7e50e460 in Standard_Transient::IncrementRefCounter() const from /lib/x86_64-linux-gnu/libTKernel.so.7+0
#2 0x7f0b7e89a721 in NCollection_Array1<TopoDS_Shape>::SetValue(int, TopoDS_Shape const&) from /lib/x86_64-linux-gnu/libTKFillet.so.7+0x41
#3 0x7f0b7e88be62 in ChFi3d_Builder::PerformIntersectionAtEnd(int) from /lib/x86_64-linux-gnu/libTKFillet.so.7+0x19b2
#4 0x7f0b7e837710 in ChFi3d_Builder::PerformFilletOnVertex(int) from /lib/x86_64-linux-gnu/libTKFillet.so.7+0x3e0
#5 0x7f0b7e838b46 in ChFi3d_Builder::Compute() from /lib/x86_64-linux-gnu/libTKFillet.so.7+0xdc6
#6 0x7f0b7e9c9f9d in BRepFilletAPI_MakeFillet::Build() from /lib/x86_64-linux-gnu/libTKFillet.so.7+0x2d
#7 0x7f0b77b81758 in PartDesign::Fillet::execute() from /opt/FreeCad/lib/_PartDesign.so+0x438
And since libTKFillet.so and libTKernel.so are part of OpenCascade, I feel like we're discussing the problem in the wrong place, since it's a project outside FreeCAD.

That said, I compiled FreeCAD from the master branch yesterday and it Indeed is waaaaaaaaaaay better than 0.18.4.

I no longer have simple errors like "NameError: name 'os' is not defined" because someone forgot to "import os" in some Py file, and things like that.
And the program closes unexpectedly a little less, showing error messages instead.

So clearly there has been improvements, so I'll stop complaining.
And if the fillets still doesn't work flawlessly maybe its just a reality too hard to change.

But i'll post some pics

My about:
Image
http://imgur.com/hIaWanf

An example of fillet that doesn't work, but should, since the piece is symmetric, and it worked in the opposite edge:
Image
http://imgur.com/ehQTT4y

And this one should also work, since I followed an youtube video of someone doing it on freecad:
Image
http://imgur.com/YrHwp58

But it doesn't, and I don't know how to debug it
Image
http://imgur.com/1otmapK

And this one is almost a piece of art ;), but I recognize the problem is in how I modeled it in first place
Image
http://imgur.com/bZm44ap
Jee-Bee
Posts: 2190
Joined: Tue Jun 16, 2015 10:32 am
Location: Netherlands

Re: OpenCascade Fillet Fiasco

Postby Jee-Bee » Thu Sep 10, 2020 3:54 pm

phoemur wrote:
Thu Sep 10, 2020 3:43 pm
My about:
If you click on copy to clipboard you can just past it here in text view incl some extra info... ;)

a bit like this

OS: Windows 7 SP 1 (6.1)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.21514 (Git)
Build type: Release
Branch: master
Hash: 89ddab33f692a9bd739171689f9ab0eb58d64b35
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: Dutch/Netherlands (nl_NL)
jmaustpc
Posts: 10566
Joined: Tue Jul 26, 2011 6:28 am
Location: Australia

Re: OpenCascade Fillet Fiasco

Postby jmaustpc » Sun Sep 13, 2020 3:31 am

phoemur wrote:
Thu Sep 10, 2020 3:27 am
Kunda1 wrote:
Thu Sep 10, 2020 1:39 am
What version of FreeCAD/OCC are you using ? Paste your About info
I'll try to build from the master branch and see if it helps
I am using 0.18.4 from Debian repo
Post your version data in the manner explained in the Forum Rules link above the help forum.

Guys I think you will find that Debian compiled against OCE not OCC. At least that was the case when I last looked some time ago.

Of course if the OP followed the instructions rather than just chucking a fit like a teenager then we would have known either way in the first post, and if it is OCE then it is likely that the crashes are due to the age of OCE, it likely has now bit rotted to the point where you would expect it to fail and be surprised if it even still compiled.
Quaoar wrote:
Thu Sep 10, 2020 7:11 am
2. Rewriting fillets is still pretty possible, especially, with the help of the community. But the fact is that our community is very small and quite inactive in terms of contributions.

Treat OpenCascade as an open project where you can contribute to your own and other people's benefits. Do not take it as a private property of the Company. Anyone interested can make a change.
I don't want to sound too negative, I do appreciate what you have done but... it's no wonder you get little involvement from the community, you make it too difficult.

You have that stupid contributors agreement thingy which immediately turns off a lot of people.

Then You enforce, or at least used to, signing it for people who are not even offering you code where it could even apply.

The last time I looked you still can't even git pull master anonymously, or other branches for testing any proposed bug fix.

The last time I looked, you made it too complex and difficult to post a bug report.

At one time, possibly still, you only allowed access to major releases under free open source conditions so your latest code was not available for testing. Also that demotivates the bug reporters and presumably prevents them from testing a fix.

I know time consuming and frustrating it is dealing with the general public when they can be so stupid as to make a topic like this without any real information and not even follow the most obvious basic rules like posting their version data.

But you guys go too far in making bug reporting too difficult even for people like me who would have tried harder and learnt over time.


In summary, of course there is a lot of room for improvement in fillets but they are nowhere near as bad as the OP fitty chuck post claims and I suspect that a lot of the problems he is seeing are Debian and its pakage specific.
User avatar
GlouGlou
Posts: 2757
Joined: Sun Apr 05, 2015 9:02 am
Location: La Rochelle, France

Re: OpenCascade Fillet Fiasco

Postby GlouGlou » Sun Sep 13, 2020 7:12 am

Maybe we could post each fillet bug encounter with a picture and a file?

Like this:

OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.22366 (Git)
Build type: Release
Branch: master
Hash: 34c11fcc63efa2fc72cbc74c75c76e9f19d5c84c
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: French/France (fr_FR)
Attachments
Capture.JPG
Capture.JPG (24.41 KiB) Viewed 466 times
FilletIssue.FCStd
(7.2 KiB) Downloaded 10 times
User avatar
Quaoar
Posts: 91
Joined: Thu Jul 27, 2017 11:56 am
Location: Nizhny Novgorod
Contact:

Re: OpenCascade Fillet Fiasco

Postby Quaoar » Sun Sep 13, 2020 11:04 am

jmaustpc wrote:
Sun Sep 13, 2020 3:31 am
I don't want to sound too negative, I do appreciate what you have done but... it's no wonder you get little involvement from the community, you make it too difficult.

You have that stupid contributors agreement thingy which immediately turns off a lot of people.

Then You enforce, or at least used to, signing it for people who are not even offering you code where it could even apply.

The last time I looked you still can't even git pull master anonymously, or other branches for testing any proposed bug fix.

The last time I looked, you made it too complex and difficult to post a bug report.

At one time, possibly still, you only allowed access to major releases under free open source conditions so your latest code was not available for testing. Also that demotivates the bug reporters and presumably prevents them from testing a fix.

I know time consuming and frustrating it is dealing with the general public when they can be so stupid as to make a topic like this without any real information and not even follow the most obvious basic rules like posting their version data.

But you guys go too far in making bug reporting too difficult even for people like me who would have tried harder and learnt over time.
You do not need to sign anything to clone and build the repo. Just do this by https:

git clone https://git.dev.opencascade.org/repos/occt.git

As for the contribution agreement, to be honest with you, this problem is being discussed over and over again in our team. However, there are some legal issues which I cannot comment here (I'm simply not aware of possible implications if some contributor starts complaining that the Company has no rights to use his code), I am a programmer. I just want to put all this in a bit different perspective. You have the basic core that provides you with a B-rep data structure and a Boolean engine. There is a spline engine (BSplCLib/BSplSLib) and a decent approximation framework (AdvApprox). All this you're absolutely free to fork, modify, and extend the way you like. You blame the Company that it does not provide you with a nice blending framework, and you say you wouldn't contribute because of this shitty CLA that you do not like. But.

Do not forget it's a FOSS business. Why not develop a good framework for fillets right in FreeCAD as a dynamic library? You do not have to make it a contribution to the master branch of OpenCascade. You're not obliged to do that. You can keep your algorithm as a separate package and distribute it under the license terms that you find appropriate. You can even sell it as a commercial product, why not. So the problem is not the OCC company that prevents the community from developing cool and reliable fillets. The problem is rather that the algorithm we're talking about is too complicated to be developed by volunteers in their spare time. Also, the Company does not expect that every algorithm developed by the community based on OpenCascade should be contributed back to the library, it's not our business.

I understand that OCC probably drives the open-source project a bit less transparently compared to other companies like Kitware or Qt (BTW, the latter sends very negative messages to its community, so that's a bad example). But this is not because OCC wants to steal your IP or because it is full of misanthropic reptiloids. The very reason for putting some extra barriers such as CLA is shielding from legal risk, and I think that people who put this CLA there had some reasons to do so. Let's rather face reality: there are very few meaningful contributions to the library related to the modeling engine, and that is not because of CLA. Where are many other reasons why people do not contribute back:
  • The community is full of commercial players who do not want to disclose anything they build on the top of the library. They do not want to lose their business.
  • There are some members who are willing to contribute something meaningful but simply cannot do so because of lacking knowledge.
  • Sometimes, people have prototypes of the algorithms but cannot finish them because developing a new geometric operator requires several months of focused work.
We rather expect the community to report bugs (it is not a problem today, you only have to sign up to our Mantis and follow some rules) and help each other on the forum (yes, right now it is not perfect, but it works).

FYI, I'm using OpenCascade in my research projects and some other apps I'm developing out of OCC Company. Standing outside I still can contribute bug reports, and develop extensions or new algorithms without contributing back. The only thing that's necessary for contribution is goodwill. If you want to see this library living, you can help it in many ways. If I had enough time and no other things to do, I would definitely try to develop new fillets and publish it in OpenCascade to reach the audience. If you want to be sure that your contribution does not remain unnoticed, simply publish a paper on it in some journal like Computer-Aided Design or give a public talk.
FOSS CAD model inspection utility and prototyping framework: http://analysissitus.org