use a online services like i.e. dropbox, https://ufile.io/ etc and post a link
Freecad fails to be serious CAD because of poor language choice
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Freecad fails to be serious CAD because of poor language choice
Re: Freecad fails to be serious CAD because of poor language choice
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
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 !
- adrianinsaval
- Veteran
- Posts: 5552
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Freecad fails to be serious CAD because of poor language choice
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.
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.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 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.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.
Re: Freecad fails to be serious CAD because of poor language choice
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 ?
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 !
- adrianinsaval
- Veteran
- Posts: 5552
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Freecad fails to be serious CAD because of poor language choice
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.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
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.Now I understand that the stl to shape implemented in Freecad is very naive and the algo cannot understand subshapes like circle
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.
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.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 ?
Re: Freecad fails to be serious CAD because of poor language choice
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.
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.
Re: Freecad fails to be serious CAD because of poor language choice
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
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 !
Re: Freecad fails to be serious CAD because of poor language choice
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.
- adrianinsaval
- Veteran
- Posts: 5552
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Freecad fails to be serious CAD because of poor language choice
That's fine, but why should the rest of the world bend to your preferences?
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.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
You are out of your mind...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
And this statement is based on what?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.
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.