I think this is solved with last magic by realthunder:
1 object per wall segment in the default case;
1 object and 1-2 sub-objects per wall object in the case we use a complex sketch or polyline as a base object (i think this is good because that workflow would save tens of objects anyway: for example @Paullee workflow).
Changing that would also allow to share some code with @Moult using part of his really well coded BlenderBim! Perhaps we can start to implement this logic in the wall prototype before extending it to the whole Arch wb. I’m in favour of working in that direction, and I’d be thrilled if we could make it together.
This is going very well!! But don’t forget that the hard part will be IFC export…
I begin to think the best way forward is to do like Bernd with rebar2: Start integrating your wall as an alternative one (maybe rename the existing one to “old-style wall” or something), and have people use it.
About section planes gaining more functionality and, somehow, “separate” view-related stuff from the model itself, yes, definitely! I already started to add a lot of stuff in that regard to the BuildingPart, as now BuildingParts can behave almost exactly like a SectionPlane. We should actually backport all that stuff to the SectionPlanes.
Also, in the BIM WB there is a “BIM Views” tool which basically does that… It’s lie an additional tree view just for view-related elements. Still experimental, but that would be basically the same direction. Also, IIRC it is now possible to hide objects in the tree, which could be convenient here too.
I know! unluckly. I’d like to use this as a testcase for separating IFC stuff from objects as you were suggesting, but I’m really too ignorant about that, so i’d love if we could discuss it in depth.
I begin to think the best way forward is to do like Bernd with rebar2: Start integrating your wall as an alternative one (maybe rename the existing one to “old-style wall” or something), and have people use it.
I’d like to leave that for after 0.19 is released. Also before doing that several changes are needeed: windows for example. They works the contrary as they work now: Wall.Group = [Window001] and Wall.Windows = [Window001] vs Window.Host = Wall. If this is correct, this means we just cannot use current window object with this prototype, so a new window object is also needed (that can integrate the old one to not lose all the precious window library).
About section planes gaining more functionality and, somehow, “separate” view-related stuff from the model itself, yes, definitely! I already started to add a lot of stuff in that regard to the BuildingPart, as now BuildingParts can behave almost exactly like a SectionPlane. We should actually backport all that stuff to the SectionPlanes.
Yes, the experiment was something I wanted to do since I started contributing, but I didn’t have the proper object to do it.
Sorry, but I think it’s kinda wrong to have the building part contain a section plane. I really find more flexible to have them separated. And what I really need for my ideal workflow is to have a view/section/whateverview object capable of containig its detail elements, and to show or hide them on demand. We can, and i’m planning to add the possibility to bind the view to an object like a Building Part (or an App::Part), so they will move accordingly.
Also, in the BIM WB there is a “BIM Views” tool which basically does that… It’s like an additional tree view just for view-related elements. Still experimental, but that would be basically the same direction. Also, IIRC it is now possible to hide objects in the tree, which could be convenient here too.
Yes, this is the direction to go. Even if IMO the Arch_View object i experimented seems really more intuitive and easy to use…
If you put a few windows, would it be hosted in the complex shape Wall ‘BaseGeometry’ or under the ‘new Wall’ (Wall003)
If you want to alter the shape of the BaseGeometry, how would the windows follow?
Here is what i was thinking (BUT i did’t check if it works):
3 workflows:
1: wall --> window
2: sketch --> wall --> window
3: wall --> profile extrusion (current wall) --> basesketch (probably an App::Link to the sketch outside the wall)
|--> windows (attached to the sketch), #here i'm open to suggestions
The “new wall” should be the only object that performs subtraction and additions to the base shape. The other objects (base shape of the wall and window) provide the shapes for the boolean operation.
I was asking for help on the 3rd workflow, since you are the one that studied it more…
copy the zip content into Mod/Arch/ folder, overwriting Arch InitGui.py module;
run FreeCAD;
you will find 3 new tools: 2 walls in the toolbar (one is used to create the wall prototype, one joins 2 selected walls) and the prototype for ArchView object (it’s a black/white section plane in the arch toolbar).
I don’t think we need to work with existing walls… It would pollute much the code of the new one, and after all the idea is to retire the old one at some point when the new one has all the needed features
Just want to ask how can I help on the 3rd workflow ? (if possible with beginner knowledge in python) And as @yorik indicates, working with existing wall (by encapsulating it?) seems complicate the issue ?
Since the prototype is going to substitute the current wall object, I still want users to be able to extrude a wire or a sketch as they do with current wall. So I think we need a new object that do that (ThinElement or ProfileExtrusion).
It would be cool if you could isolate the code in the current wall that perform such tasks, so we can move it into the new ThinElement or ProfileExtrusion object. This code will be triggered on execute and will output the shape of the ThinElement or ProfileExtrusion.
So we have to extract also all the current wall properties that are needed for that.
So instead of encapsulate the existing ArchWall, do an object that just do the extrusion ?
Hmmm… how about ‘extracting’ the method / code (getExtrusionData(), execute() …) that ArchWall that do that into a function(), so every object needs this function can call it, existing ArchWall, new Wall, etc.? If it makes sense at all - as reiterated, having only very beginner knowledge in python, i may break a lot of things and currently with very limited leisure time out of work
Hmmm, I think this could be good at the beginning, but all of a sudden we could want to add more features to it, so probably I still think a brand new object is the best option. But we can for sure experiment other solutions.
Please enlighten me, so you will encapsulate the new ‘Thin Element’ ‘ProfileExtrusion’ object - what is the difference encapsulating these 2 objects OR what are the difference you are expecting between the Thin Element’ ‘ProfileExtrusion’ vs ArchWall OR any problem ‘building in’ the extrusion functions/method in the new Wall.
I’m a real beginner too! Apart some random Python and Processing approach in 2012, this is my first experience in coding
I want to keep the new wall as light as possible. And the current code is huge and quite tangled, because it performs looooots of things. The new one will just handle 1 case by default. All the other cases will be handled with “geometry plugins”, constituted by separated geometry objects. My hope is that will keep it simple (at least as much as possible).
weeeellll… I have to admit that I can’t wait for the integration of the prototype… and probably you are right that if it is inside we can get more feedback from the users (and also other developers can jump in more easily)…
So I was thinking: can we make an experimental toolbar so the user will know that he just cannot rely too much on the objects that are contained there? and we are free of changing them as much as we want? Maybe that toolbar can be invisible by default until we release 0.19…
I tried to look at your code for the new wall but it is way too advance and complex for me Anyway, my understanding of the crux of ArchWall is getExtrusionData(), and of course there are a numbers of things that I do not understand.
BTW the term ‘Thin Element’ remind me of this thread Feature request thin element for Part and PartDesign workbench which somehow hint what getExtrusionData() does and helps to do the extrusion for a wall with multi-segment basically. And recently @yorik further explain it run rebase() which make the ‘extrusionData’ fits for export to IFC.
That’s more or less the basic of ArchWall to my understanding.
But if you need to accept things like flexibility of a wall shape which like e.g. Ronchamp, you start to add some codes like in ArchWall.execute()… and other features… it become the existing ArchWall. So maybe you want to have a look at this method or @yorik may provide some comments
Replying here to not hijack you PR topic.
The SubShapeBinder is really exactly what we need. I have some questions to plan the implementation:
is it possible to extend the SubShapeBinder object with python?
or provide a make_window function to create and customize a SubShapeBinder according to an original PartWindow object (similar to the one I posted in my original request) in a way that:
PartialLoad = False (so the linked document will be loaded just in case of reSync);
BindMode = Frozen (so it will be syncronized only on demand);
a “WallVoid” Part::PropertyPartShape is added to the SubShapeBinder. So SubShapeBinder.WallVoid = PartWindow.WallVoid.Shape (this will serve later to boolean cut the wall);
the properties in the Variables object are also added to the SubShapeBinder (so we can use them to update the linked PartWindow also if it was previously changed by another SubShapeBinder ).
And a second python function that will control its properties editing and syncronize it, after injecting the updated properties to the PartWindow object…
Yes, PartDesign::SubShapeBinderPython, PartDesignGui::ViewProviderSubShapeBinderPython is already there
or provide a > make_window > function to create and customize a > SubShapeBinder > according to an original PartWindow object (similar to the one I posted in my original request) in a way that:
PartialLoad = False > (so the linked document will be loaded just in case of reSync);
BindMode = Frozen > (so it will be syncronized only on demand);
a “WallVoid” > Part::PropertyPartShape > is added to the > SubShapeBinder. So SubShapeBinder.WallVoid = PartWindow.WallVoid.Shape > (this will serve later to boolean cut the wall);
These are trivial to do just like any other Python extended objects, so is changing the icon. BTW, you also want to change the view style by setting its view property ‘UseBinderStyle’ to False, and this will cause the binder to display the color just like the bound object.
the properties in the > Variables > object are also added to the > SubShapeBinder > (so we can use them to update the linked PartWindow also if it was previously changed by another > SubShapeBinder > ).
And a second python function that will control its properties editing and syncronize it, after injecting the updated properties to the > PartWindow > object…
Now, this is where the magic begin. With my PR there, you don’t really need the ‘Variable’ object. You shall put all configuration variables (i.e. direct user configurable parameters) to the top parent object, which is the App::Part object in your case. You can reference these variables in any of its children without cyclic dependency problem by wrapping it with href() function. See my PR post for details. On the other hand, you can choose to keep the ‘Variable’ object if you like. Maybe you don’t want to type all those extra href() everywhere. You can instead, bind the variables in the ‘Variable’ object to App::Part using href(). And other child objects just reference the ‘Variable’ object as usual.
Once you have created all the parameters in App::Part, right click each of these properties, and select ‘CopyOnChange’. Later on, when you bind to this App::Part, and set ‘BindModeCopyOnChangeMode’ to enabled, these ‘CopyOnChange’ properties will be automatically injected to the binder object. Changing any of these published properties will trigger a copy and recomput in a hidden temporary document. And there you have your variant instance. You can experiment these steps with my image. The only problem right now is that the color is lost, which I’ll fix soon.
Anyway, my understanding of the crux of ArchWall is getExtrusionData(), and of course there are a numbers of things that I do not understand.