Freecad fails to be serious CAD because of poor language choice

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!
User avatar
easyw-fc
Veteran
Posts: 3629
Joined: Thu Jul 09, 2015 9:34 am

Re: Freecad fails to be serious CAD because of poor language choice

Post by easyw-fc »

chrisb wrote: Tue Jan 11, 2022 8:50 am
andremiv wrote: Tue Jan 11, 2022 2:16 am EDIT : the attachement doesnt seem to work,
Attachments are limited to 1MB.
use a online services like i.e. dropbox, https://ufile.io/ etc and post a link
andremiv
Posts: 56
Joined: Thu Sep 02, 2021 10:45 am
Location: France

Re: Freecad fails to be serious CAD because of poor language choice

Post by andremiv »

thanks easyfwc, here's the link to play with my stl : https://ufile.io/ux44tgr0

kisolre pointed that Freecad can do globoids without having to C program them, I knew for sure that but I abandoned because of overall slowness of everything but also because of learning difficulty, I am still freecad noob, can't figure out the workflow, the methodology of the program. I came from master in physics so I love natural coordinates systems and when everything is formula based which is not really what freecad offers

I am very curious to see the difference in speed when generating the file
1)For the C generated stl file
2)For the freecad generated stl file

Also Am I right to expect a speed boost with freecad's stl when operating BREP CGS tasks on it ? Because Freecad having generated the file should know some specific about the shape and should treat the problem differently than loading a random stl file, I hope so anyways.

André Miville
A new era of point programmation has come !
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Freecad fails to be serious CAD because of poor language choice

Post by adrianinsaval »

andremiv wrote: Tue Jan 11, 2022 2:12 pm I love natural coordinates systems and when everything is formula based which is not really what freecad offers
FreeCAD has a very powerful feature to set expressions for most properties of an object so you can have almost everything based on formulas, that you choose to work the non parametric way in a parametric software is your fault, making cuts on STLs is the most stupid way of modelling if you can avoid it.
I am very curious to see the difference in speed when generating the file
1)For the C generated stl file
2)For the freecad generated stl file
this makes no sense, a program made specifically to generate a specific stl will obviously be faster than a multi purpose general CAD software that has scripting and extension capabilities... If you want to write your models by coding maybe OpenSCAD or another similar software is better suited for you.
Also Am I right to expect a speed boost with freecad's stl when operating BREP CGS tasks on it ? Because Freecad having generated the file should know some specific about the shape and should treat the problem differently than loading a random stl file, I hope so anyways.
This is not how stl works, stl saves no history of the object or any info on the original shapes, just the mesh. Exporting the stl should be the absolute last step of your procedure, the boolean operations should be performed on the BREP model.
andremiv
Posts: 56
Joined: Thu Sep 02, 2021 10:45 am
Location: France

Re: Freecad fails to be serious CAD because of poor language choice

Post by andremiv »

Ok so freecad operate CSG tasks on brep files. stop me when wrong

The brep file format is this one : https://dev.opencascade.org/doc/occt-6. ... ormat.html

I assume Freecad use a binary BREP variant because otherwise if it is the ASCII variant like described, it is very bad and slow, I hope it is not the case. Can someone confirm because it could be one of the culprit of slowness

The brep file format detaills subshapes and geometry elements with the important property like convex. It is very good because it can provide better algo to perform the CSG tasks than brute force algo in stl file.

So in essence the brep format should be faster to compute CSG tasks on it than with my STL.

Now I understand that the stl to shape implemented in Freecad is very naive and the algo cannot understand subshapes like circle

So Finally to solve my problem, I should program my C file to output to a brep file format instead of a stl so that Freecad can better work with them. Do we agree ?
A new era of point programmation has come !
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Freecad fails to be serious CAD because of poor language choice

Post by adrianinsaval »

andremiv wrote: Tue Jan 11, 2022 4:01 pm Ok so freecad operate CSG tasks on brep files. stop me when wrong
The brep file format is this one : https://dev.opencascade.org/doc/occt-6. ... ormat.html
I assume Freecad use a binary BREP variant because otherwise if it is the ASCII variant like described, it is very bad and slow, I hope it is not the case. Can someone confirm because it could be one of the culprit of slowness
It's saved as ASCII, FCStd files are just zip containers and the brp files for each object are inside, these come from OCC so I don't know if FreeCAD can do anything about it. Still I don't think this gives much overhead, I don't think the file is read at every operation but the shape is loaded to memory at file open, presumably not as ASCII but the internal data structure from OCC and this is what is passed on to OCC to perform operations, not really ASCII files. But don't trust my word for any of this.
Now I understand that the stl to shape implemented in Freecad is very naive and the algo cannot understand subshapes like circle
stl is a very rudimentary format to begin with, the are no circles in them, just a point cloud. The shape from mesh tool just creates a bunch of planar triangular faces from all the points, nothing more. Performing boolean operations on a shape like this is bound to be slow. You can try refining the shape to at least combine coplanar adjacent faces but all the "curved" parts will still be a bunch of triangles.
Here someone is attempting to make an algorithm to better detect the shapes in an stl to try and get a parametric file https://forum.freecadweb.org/viewtopic.php?t=61662
Of course this won't be a reliable method and it's unlikely to give meaningful results for complex shapes.
So Finally to solve my problem, I should program my C file to output to a brep file format instead of a stl so that Freecad can better work with them. Do we agree ?
You could do that, I guess using the OCC libraries (note that it has to be a proper BREP of the shape, not just your point cloud in brp format as this would yield the same result). Or you could script it on FreeCAD with the python interface or directly go and use OpenSCAD that is script based. Or you can try and model that gear on the FreeCAD GUI or if it's a standard part see if you can get and stp file for it.
c3kkos
Posts: 10
Joined: Thu Nov 15, 2018 7:42 am
Location: Pisa

Re: Freecad fails to be serious CAD because of poor language choice

Post by c3kkos »

I see in andremir a lot of knowledge.

He showed his skills and rightful thoughts but i'm stuck focusing his real goals.

Why are we even talking about stl and meshes?

This is no Blender's discussion board (nor we have Blender's sponsors hehe)

As already noted, there is also no reason doing comparisons with "custom made 1-purpose-only stl generating softwares"

FC perfomances are indeed a good discussion point.

Let me face you the fact that, for my own point of view, priority now is to align Freecad to the industry standards in terms of TECHNICAL usability.
openBrain
Veteran
Posts: 9034
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

Re: Freecad fails to be serious CAD because of poor language choice

Post by openBrain »

c3kkos wrote: Sun Jan 16, 2022 3:04 pm I see in andremir a lot of knowledge.

He showed his skills and rightful thoughts
:shock: :shock: :shock: Not about programming and programming languages for sure... :!:
andremiv
Posts: 56
Joined: Thu Sep 02, 2021 10:45 am
Location: France

Re: Freecad fails to be serious CAD because of poor language choice

Post by andremiv »

Sorry Openbrain but I have my preferences about languages, why should I have skills in object programming languages like C++ and python when C can do everything

Three misconcetions I understand from this thread
1) People in this thread seems to say that Freecad needs python for easy scripting, so they wrote wrappers, API bindings in a mix of C++/python.
2) Another key argument was that somehow Python is more beginner friendly and simpler to script with than C.
3) Another point people said was that my special purpose program in C loses its generality so I can't compare it with Freecad performance

Three answers for you :
1) You can create a kind of a C based language script to make everything faster that clearly exposes API and make it simpler to learn and way faster than python
2) Python is way harder than C, even from beginners from my point of view, maybe it is an affair of taste, we could have a poll to see what people thinks
3) The C language based script would loses only a small fraction of speed compared to the special purpose program. The cost of generality is maybe a factor 2 at most, mind you that a special purpose code is only an application of a more general theory. In freecad the cost is a factor 100. That is to say, it is 100 to 1000 times slower, it's unacceptable.

The C based language script idea is just a call to C compiler in a formatted text, then runtime linking to the C script object so not too difficult to implemant.

EDIT: Freecad needs python dependancy, so a C compiler dependancy like gcc should not be a problem

Andre Miville
A new era of point programmation has come !
chrisb
Veteran
Posts: 53930
Joined: Tue Mar 17, 2015 9:14 am

Re: Freecad fails to be serious CAD because of poor language choice

Post by chrisb »

You are still ignoring all the posts telling you that not Python is the bottleneck. So speeding up the Python stuff would not speed up the whole FreeCAD performance. It would probably speed up a rather neglectable part. And interpreting your C-like scripting language would make it slower too, wouldn't it?
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Freecad fails to be serious CAD because of poor language choice

Post by adrianinsaval »

andremiv wrote: Thu Jan 20, 2022 11:36 pm Sorry Openbrain but I have my preferences about languages, why should I have skills in object programming languages like C++ and python when C can do everything
That's fine, but why should the rest of the world bend to your preferences?
1) You can create a kind of a C based language script to make everything faster that clearly exposes API and make it simpler to learn and way faster than python
But why do it? It most definitely isn't easier to learn, just for you because you already learnt C and you refuse to learn others. And you've already been told that the main slowdowns do not come from python to begin with but from OCC.
2) Python is way harder than C, even from beginners from my point of view, maybe it is an affair of taste, we could have a poll to see what people thinks
You are out of your mind...
3) The C language based script would loses only a small fraction of speed compared to the special purpose program. The cost of generality is maybe a factor 2 at most, mind you that a special purpose code is only an application of a more general theory. In freecad the cost is a factor 100. That is to say, it is 100 to 1000 times slower, it's unacceptable.
And this statement is based on what?

Regarding compiler dependencies I guess it would be trivial to manage on Linux. Not so sure for Windows and Mac... And is compiling a script before running it really gonna give a significant speed a up to begin with? Keep in mind that it's not just to make a macro or add-ons, it's also to allow you to enter commands in the built-in console and get results immediately. And it's also easier to distribute python add-ons.
Post Reply