- wall automations.gif (594.17 KiB) Viewed 1470 times
The prototype has been improved with auto updating opening elements when width changes, and also auto recomputing end joinings.
[Discussion] A different approach to Arch modelling (Arch Assembly?)
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)
It has been a while since I was posting a gif
The prototype has been improved with auto updating opening elements when width changes, and also auto recomputing end joinings.
The prototype has been improved with auto updating opening elements when width changes, and also auto recomputing end joinings.
follow my experiments on BIM modelling for architecture design
Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)
Yes, it seems a reasonable approach, but OCC is the base of every solid you create with FreeCAD, only text and maybe mesh is not using the Part module.
From what i know if a module is already loaded, it is not loaded twice, but the overload of having python to check if the module is loaded is more demanding than loading it and maybe (I'm almost sure that Part is used in a manner or other in FreeCAD, as it have no sense of using a CAD without using CAD features).
A test will surely stop every discussion, time the execution of the same code, loading Part at the beginning, and time the execution using it on every method and the considerations are easily done.
From some reading I have done, importing a module in a method is discouraged.
Regards
Carlo D.
From what i know if a module is already loaded, it is not loaded twice, but the overload of having python to check if the module is loaded is more demanding than loading it and maybe (I'm almost sure that Part is used in a manner or other in FreeCAD, as it have no sense of using a CAD without using CAD features).
A test will surely stop every discussion, time the execution of the same code, loading Part at the beginning, and time the execution using it on every method and the considerations are easily done.
From some reading I have done, importing a module in a method is discouraged.
Regards
Carlo D.
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/
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)
I think this is a delicate topic, and if we want this convention to be changed we should prove it with several tests. From my side my programming skills are not sufficient to have an opinion, so I'm fine with both approaches.
follow my experiments on BIM modelling for architecture design
Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)
Nice progress.
P.S. Using Assembly 4 alike workflow (attaching CS), for constructing beam structures. Maybe that could be explored in the future too.
P.S. Using Assembly 4 alike workflow (attaching CS), for constructing beam structures. Maybe that could be explored in the future too.
Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)
Thanks!
What i'd like to start experimenting with (also if yorik do not agree
) is to bring LCS to the building part 
(or better to use plain App::Part with some added properties instead of a dedicated object).
Attaching would be cool, but at the moment i'd prefer keeping object not too intelligent (at least dumber than me)
Sure thing! probably beams and pillars ar also more suitable than walls for having an own coordinate system.
What i'd like to start experimenting with (also if yorik do not agree
) is to bring LCS to the building part (or better to use plain App::Part with some added properties instead of a dedicated object).Attaching would be cool, but at the moment i'd prefer keeping object not too intelligent
(at least dumber than me) follow my experiments on BIM modelling for architecture design
Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)
By the way, it would be nice if you try those experimental tools and give us a feedback, they are already into the BIM workbench marked with a red star.
follow my experiments on BIM modelling for architecture design
Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)
Go for it with App::Part @carlopav! I don't pretend to know thing better than anyone else 
I started with App::Parts too, but the hassle of adding/removing objects to/from them and dealing with coordinate changes was so annoying to me that I ended up going another path. But you might find a better way.
About importing modules inside methods, all I read everywhere (and also experienced myself) is that once you load a module, it stays loaded globally (it is added to the globals of the python interpreter session), and further imports don't reimport anything, so it is safe to import a same module hundreds of times, it will be actually loaded only the first time, you'll see that statement everywhere on the net...
All I can find is that it is considered ugly and not recommended for code cleanliness reasons. But IMHO if it has an impact on performance, performance must come first. And I think we could mitigate the issues, for ex. group all the imports cleanly at the top of each method...
I started with App::Parts too, but the hassle of adding/removing objects to/from them and dealing with coordinate changes was so annoying to me that I ended up going another path. But you might find a better way.
About importing modules inside methods, all I read everywhere (and also experienced myself) is that once you load a module, it stays loaded globally (it is added to the globals of the python interpreter session), and further imports don't reimport anything, so it is safe to import a same module hundreds of times, it will be actually loaded only the first time, you'll see that statement everywhere on the net...
All I can find is that it is considered ugly and not recommended for code cleanliness reasons. But IMHO if it has an impact on performance, performance must come first. And I think we could mitigate the issues, for ex. group all the imports cleanly at the top of each method...
Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)
Yup, let me scratch the itch!yorik wrote: ↑Wed Jun 24, 2020 10:54 am Go for it with App::Part @carlopav! I don't pretend to know thing better than anyone else
I started with App::Parts too, but the hassle of adding/removing objects to/from them and dealing with coordinate changes was so annoying to me that I ended up going another path. But you might find a better way.
My main concern ATM is trying to merge the current wall tool, any suggestions on that? I want to keep things simple.
follow my experiments on BIM modelling for architecture design
Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)
I don't think we should go that way. You will unnecessarily add unwanted heritage stuff. I'd rather follow your way, and add what you need to your wall object. Then we can progressively retire the current one...
I would say for me what it should have is material layers, I would suggest basing that on Arch Multimaterials because that's what many other Arch objects use, but it's up to you, and be exportable to IFC with correct extrusion and maybe baseline/axis.