Which issues will start to arrive with the splitting of complexity?

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!
User avatar
onekk
Veteran
Posts: 6146
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: Which issues will start to arrive with the splitting of complexity?

Post by onekk »

grd wrote: Mon Aug 15, 2022 5:53 am Because I believe that the structure of today, with everything implemented in one size fits all is not correct (sorry). I believe that the separation with part, assy and drawing to be more correct. At least make it optional.
As said by many others FC is not here to compete with XXX CAD program.

You could use only parts you are accustomed with.

Development is done by volunteers from over 20 years.

So changing this paradigm will mean to have many new developers.

Some has even advanced the idea to change the "modelling engine" but this would involve to rewrite more than 50 per cent of the source code something almost impossible and not very fast to do.

FC is worth every money you have payed for, more than you have payed for as you payed it 0 whatever currency you daily use.

Future development is what developers will produce, maybe investing some time in making FC better will help.


Regards

Carlo D.
Last edited by onekk on Wed Aug 17, 2022 8:04 am, edited 1 time in total.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Which issues will start to arrive with the splitting of complexity?

Post by adrianinsaval »

You see separate filetypes as eliminating complexity, I see it as adding complexity. In FreeCAD I can make a quick assembly with 2 or tree disconnected bodies placed manually very quickly in a single file without even switching workbenches. In soldiworks and many other CAD, I would have to make several files including an assembly file which also requires switching to another workbench, how is this more simple? So that's the first problem that comes from your proposal, you are removing a perfectly valid and useful workflow. If made optional I see no issue besides the possible complexity of the code (for little gain).
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: Which issues will start to arrive with the splitting of complexity?

Post by Zolko »

grd wrote: Mon Aug 15, 2022 5:53 am With that question I mean: What can go wrong if this feature is implemented ?
...
At least make it optional.
It's not going to be implemented for many reasons, get over it.

If you want to separate your filetypes, just do it by adding some pre- or post-fix in de name, it's optional already.
try the Assembly4 workbench for FreCAD — tutorials here and here
grd
Posts: 328
Joined: Wed Apr 13, 2022 5:13 am
Location: Eindhoven, The Netherlands

Re: Which issues will start to arrive with the splitting of complexity?

Post by grd »

Zolko wrote: Tue Aug 16, 2022 4:48 pm It's not going to be implemented for many reasons, get over it.
I already gave a couple of reasons of why it should be an option. Can you give the reasons of not? There are supposed to be many.

But still, my original question hasn't been answered. What are the hooks of implementing it?
About Nim. Latest Release 2.0.2. Here is Nim in 100 seconds and a Nim package. There are Qt and OCCT packages.
drmacro
Veteran
Posts: 8868
Joined: Sun Mar 02, 2014 4:35 pm

Re: Which issues will start to arrive with the splitting of complexity?

Post by drmacro »

grd wrote: Tue Aug 16, 2022 5:03 pm
Zolko wrote: Tue Aug 16, 2022 4:48 pm It's not going to be implemented for many reasons, get over it.
I already gave a couple of reasons of why it should be an option. Can you give the reasons of not? There are supposed to be many.

But still, my original question hasn't been answered. What are the hooks of implementing it?
Hmm...maybe you need to define what a "hook" is?

I can think of different areas of the code base that would need to change considerably. The Python API, probably the internal data structure, the interface between FreeCAD and the OpenCASCADE kernel (maybe COIN as well), the internal structure of the document, a good bit of the wiki, most of the training material that does exist, it would obsolete most of the content on YouTube (though admittedly, there is much of it that is garbage anyway...), it would likely have a major effect on the effort to merge TNP mitigation.

For very little, if any, return on investment. A branch would need to be made where this was implemented and benchmarked against the existing code base to see if there were any performance improvements.

As noted...fairly unlikely I think.
Star Trek II: The Wrath of Khan: Spock: "...His pattern indicates two-dimensional thinking."
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Which issues will start to arrive with the splitting of complexity?

Post by adrianinsaval »

What is clear is that there isn't interest form other devs to do it, if you want to implement it yourself go ahead, but it must be optional and easily convertible to regular FCStd files, it should not require changes to wb commands or it will not be enforceable. You have to look at how document loading and saving/backup work, you'll have to find a way to restrict adding objects per type. It is no easy task and IMO not worth the effort.

for those listing benefit/disadvantages of a mandatory split files, it's useless chatter, it will not happen as it is just not acceptable. Discussion should be done considering an optional situation where if desired one can choose to use a different filetype that holds only certain type of objects.
grd
Posts: 328
Joined: Wed Apr 13, 2022 5:13 am
Location: Eindhoven, The Netherlands

Re: Which issues will start to arrive with the splitting of complexity?

Post by grd »

drmacro wrote: Tue Aug 16, 2022 6:28 pm Hmm...maybe you need to define what a "hook" is?
Well, you create in the sketcher two circles with a diameter of 10, separated with 15mm. So they are are independent of each other. Then you pad it with a length of 10. You get an error message that says: "Pad: Result has multiple solids. This is not supported at this time.".

This is what I mean with a "hook". But this simple exercise also shows that PD already allows only ONE body, where the Part WB allows many.
I can think of different areas of the code base that would need to change considerably. The Python API, probably the internal data structure, the interface between FreeCAD and the OpenCASCADE kernel (maybe COIN as well), the internal structure of the document, a good bit of the wiki, most of the training material that does exist, it would obsolete most of the content on YouTube (though admittedly, there is much of it that is garbage anyway...), it would likely have a major effect on the effort to merge TNP mitigation.
That is -for the first time- an answer to my question. Thank you! And now question two: What do you roughly think that the LOC count is that is involved with this? Three, Four or Five digits? I think Four.
For very little, if any, return on investment. A branch would need to be made where this was implemented and benchmarked against the existing code base to see if there were any performance improvements.

As noted...fairly unlikely I think.
To be honest, I think it depends on the number of former Pro/E (Creo), SW, SE and Inventor users, but I consider that number pretty high.
adrianinsaval wrote: Tue Aug 16, 2022 6:50 pm What is clear is that there isn't interest form other devs to do it, if you want to implement it yourself go ahead, but it must be optional and easily convertible to regular FCStd files, it should not require changes to wb commands or it will not be enforceable. You have to look at how document loading and saving/backup work, you'll have to find a way to restrict adding objects per type. It is no easy task and IMO not worth the effort.

for those listing benefit/disadvantages of a mandatory split files, it's useless chatter, it will not happen as it is just not acceptable. Discussion should be done considering an optional situation where if desired one can choose to use a different filetype that holds only certain type of objects.
You keep on talking mandatory, where I keep on talking optional. To be honest, I think that you are quite right and that there is not much interest in the developers, but once they start using it I am pretty sure that this is gonna work out pretty well, because this is the way it works in their former CAD software.
About Nim. Latest Release 2.0.2. Here is Nim in 100 seconds and a Nim package. There are Qt and OCCT packages.
User avatar
obelisk79
Veteran
Posts: 1062
Joined: Thu Sep 24, 2020 9:01 pm

Re: Which issues will start to arrive with the splitting of complexity?

Post by obelisk79 »

grd wrote: Wed Aug 17, 2022 5:48 am This is what I mean with a "hook". But this simple exercise also shows that PD already allows only ONE body, where the Part WB allows many.
This is the #1 example that you don't understand FreeCAD at all. While I agree the naming of Part and Part design is ambiguous, these two work benches were built for different modeling paradigms. This is why they behave differently, failure to understand this fundamental truth somewhat invalidates every argument you've brought up regarding "complexity" and how splitting up modeling elements into different files is somehow the solution.
You keep on talking mandatory, where I keep on talking optional. To be honest, I think that you are quite right and that there is not much interest in the developers, but once they start using it I am pretty sure that this is gonna work out pretty well, because this is the way it works in their former CAD software.
You really haven't made a strong argument demonstrating how the changes you are proposing would actually be an improvement for the end-user. I think that is where the problem lies. I am still waiting for you to better clarify this and what exactly would this look like? Would it be something like a filetree?

For example would it look something like this?:
ProjectFile (projectfile is the only item a user needs to load to interact with their design)
l_Models
l l_ModelFile1
l l_ModelFile2
l_AssemblyFile
l_TechnicalDrawings

Also, this already appears to be done within FCStd files. The difference is that the data is packaged in a neat and efficient zip format archive. It is probably better explained here: FCStd

If these examples are in-fact what you've been rambling on about, can you adequately explain why your proposal is effectively better than the existing solution?
drmacro
Veteran
Posts: 8868
Joined: Sun Mar 02, 2014 4:35 pm

Re: Which issues will start to arrive with the splitting of complexity?

Post by drmacro »

This a frivolous discussion.

Name the file as you choose, as has been described with pre/post-pend characters as you see fit to indicate it's content. And .FCStd indicates system wide it is a FreeCAD file. People using computers have used this method for decades in all sorts of software.

For those coming from other CAD programs, the file extension is the least of their concern. And it is simple answer, the FreeCAD file is saved with an extension .FCStd.

As I said to you elsewhere, after helping hundreds new FreeCAD users for years, in multiple online media, not one has mentioned file extensions. Well, until now that is... :mrgreen:

:roll:
Star Trek II: The Wrath of Khan: Spock: "...His pattern indicates two-dimensional thinking."
grd
Posts: 328
Joined: Wed Apr 13, 2022 5:13 am
Location: Eindhoven, The Netherlands

Re: Which issues will start to arrive with the splitting of complexity?

Post by grd »

obelisk79 wrote: Wed Aug 17, 2022 9:40 am You really haven't made a strong argument demonstrating how the changes you are proposing would actually be an improvement for the end-user. I think that is where the problem lies. I am still waiting for you to better clarify this and what exactly would this look like? Would it be something like a filetree?

For example would it look something like this?:
ProjectFile (projectfile is the only item a user needs to load to interact with their design)
l_Models
l l_ModelFile1
l l_ModelFile2
l_AssemblyFile
l_TechnicalDrawings

Also, this already appears to be done within FCStd files. The difference is that the data is packaged in a neat and efficient zip format archive. It is probably better explained here: FCStd

If these examples are in-fact what you've been rambling on about, can you adequately explain why your proposal is effectively better than the existing solution?
I have read the FCStd file document more than once. Understanding this document is also a part of writing a PDM. What is your background? With which CAD programs have you worked with? In the past I could do anything with Pro/E. I could read and write it. Restructuring a Pro/E document? Easy. I have worked more than a decade with Pro/E. Then NX came and everything that I learned was going to waste. Then luckily SW came and I could do things again. But Pro/E again was my first choice. The only thing that was lacking was automation (keystrokes for instance). I hope and think they fixed this with Creo.

But I still don't believe you understand what I meant with getting rid of complexity. With Creo/SW/SE/Inventor everything is structured with three separate things: Parts, Assemblies and Drawings. A part can only have one body, not more, and an assembly can only have sub-assemblies and parts. That's it. And a drawing is a reference to a model (part or assembly).
So you can't do a boolean operation with a part. That becomes an assy. In the past I saw this happening in FC, with two bodies with different density being united... I commented that somewhere in the Python scripting group.

The structure of a FCStd file can have anything. But that is not the problem. The problem is that when you want to use it and start creating things it gets bad very easy. And also things such as assigning a material, to which body do you assign it? And what is the weight of that body? And things such as labels, it's the same thing. In Pro/E I could do assign a material and then I could measure the weight and even the COG (all within one program), I didn't need an external WB to do this.

And also things such as exporting a STL file. In Pro/E this is easy, you select export to STL. In FC you first need to select a body to export. When things are separated you don't need to select the body anymore.

This are just a couple of reasons of why I want this.

Edit: The file structure should not change. Only new file extensions of course and limiting it to only allow one body for a part.
Last edited by grd on Wed Aug 17, 2022 12:31 pm, edited 3 times in total.
About Nim. Latest Release 2.0.2. Here is Nim in 100 seconds and a Nim package. There are Qt and OCCT packages.
Post Reply