[Discussion] A different approach to Arch modelling (Arch Assembly?)

[carlopav]

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...

ok, let's do like this. What do you envision for the blocks functions and the "profile extrusion function"? will they become separated objects as i'm thinking?

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,

The reason why I didnt' already start with that is that i'm really not sure about which path to follow:
Materials:
in Ifc, if I got it correctly we have 4 ways to describe the material of a wall:
-

Cattura.JPG (21.16 KiB) Viewed 1586 times

- monomaterial;
- mixed material;
- layered material;
- profiled material;

the most suitable for a 3d representation should be the profile set material, since it can specify for each layer it's correct position not only in the thickness direction, but also in the z axis direction.
Anyway all of those ways do not necessary have to be represented in 3d. (this is somthing important I think, because we probably want to turn on-off the material visualization in the 3d view and display or not the wall as a monolitic solid).

At the moment Arch Material is the corrispondent of the LayerSet. So if we represent it in 3d, all the layers will start from the same base height and have the same wall height. I think this is limiting.

Wall joining:
At the moment the walls calculate joining of just one monolitic layer. Auto calculating the join between each single layer is far above my math and alghorithms skills. And if you think also about commercial softwares, there are plenty of usecases where they fail, but not because they are bad, just because it is just impossible to guess every different usecase or to retrieve a general rule. So perhaps it can work if you join 2 walls with the same layers, but not if you join 2 walls with same layer sequence, but different layer thickness, or the opposite.
And i'm not really sure I want to measure myself with such an outstanding task.

Work phases:
I do not always need layers to be displayed in my workflow. It is necessary for construction documentation, but not in the half 50% of the desing process... May we think about something flexible?
Something that you can complexify on demand advancing with the design process?

Wall axis and core axis:
Core layer is something revitish. We can't export it in IFC.
I was thinking to build each layer from a core one, but then we can't tell IFC so.
And having a wall center axis is more convenient since the openings can be placed with Placement.Base.y = 0.00. I think we should keep this rule.
Should we just cut the wall in slices according to the layers thickness?

Using basegeometry property:
Each wall layer could be actually be built with separated objects, since BaseGeometry property supports multiple base objects. If each object have it's own material, here you have multimaterial wall.
This is super flexible, but super resource consuming, and in current FC this is not an option.

WAll Types:
As windows and other objects, also wall can have their types. No idea how this can be useful if we use Arch MultiMaterial: this is already a type.

Inside, outside:
The geometry is build keeping reference to the X axis that become the wall center line. let's say positive Y is outside and negative Y the inside? do we have a standard in Ifc?

and be exportable to IFC with correct extrusion and maybe baseline/axis.

This is something I really do not understand how to do:
- you are rewring the importer, are you planning the same for the exporter?
- currently the wall is already recognized as a wall and exported as a Brep geometry. Of course the wall subobjects (in wall.Group) are not recognized and are not exported;
- for the representations it should be easy, since the coordinates are adherent to the IFC standard: wall childrens have their coordinates relative to the parent wall (https://standards.buildingsmart.org/IFC ... cement.htm);
- where should I place the code to treat the new wall special case in the Ifc Exporter? Can we have an object version number?

As you see, still lot of doubts...
What do you think?

[yorik]

About layers, I don't think it's something we either absolutely need to solve now, nor necessarily follow how it's done in IFC. But I know that's something BIM users usually want badly.

About blocks, I'm also not sure that needs to be something walls do. It might be something totally separate... I also don't know any other BIM app that does so, but it seemed cool to me, in low-cost apartment building projects it is common to have well designed block placement, and all hydro pipes and eletrical appliances use that.

About types, indeed it seems to me a wall type is nothing more that what the arch multimaterial provides...

And about IFC export, I am not planning on redesigning the exporter for now, but yes start working on a separate serializer module that would take a shape, and guess the best way to represent it in IFC. IfcOpenShell has such a serializer, but it doesn't go as far as we would want to. But I need to test again.

[carlopav]

About layers, I don't think it's something we either absolutely need to solve now, nor necessarily follow how it's done in IFC. But I know that's something BIM users usually want badly.

What I think:
- wall local x axis should be the wall axis.
- core axis can be calculated with a function.
- core layer is something that IFC does not support, so it doesn't make sense to me to describe it.
- at the moment we can just add the layer property as a material: add a material property, calculate the WallWidth from it, add a property enumeration to display layers in the 3d view ['None','Layers','Profiles'] and turn it readonly None. And postpone their structural introduction;
- add a function to generate subobjects layers (it will create a part wedge for every layer, as a grouped object, in the right position).

About blocks, I'm also not sure that needs to be something walls do. It might be something totally separate... I also don't know any other BIM app that does so, but it seemed cool to me, in low-cost apartment building projects it is common to have well designed block placement, and all hydro pipes and eletrical appliances use that.

I think that blocks feature is a bit controversial. It conflicts with wall layers and it's more related to detailing (Edit perhaps not, but walls can have locked modular lenght also without actually displaying blocks)... I suggest to go for a separate object that can be used as a wall base geometry, together with other layers. Let's keep in mind that when the realthunder href() function will be introduced in the expressions, we will be able to point to the parent wall from its children geometries, so a wall grouped object can be parametrically linked to the wall dimensions!

About types, indeed it seems to me a wall type is nothing more that what the arch multimaterial provides...

Yes and no: it depends on which description of the material layers you want for the wall. So yes if we want to describe them as layered material, no if we want to use a profiled material.
The material part is also a bit complicated to me: it fills the document tree with a lot of objects... perhaps a material editor like the one you developed for annotation styles could be the goal (?).

And about IFC export, I am not planning on redesigning the exporter for now, but yes start working on a separate serializer module that would take a shape, and guess the best way to represent it in IFC. IfcOpenShell has such a serializer, but it doesn't go as far as we would want to. But I need to test again.

This seems a lot of work. I need to ask for your help at least on laying down its structure (as you did for the new multicore importer).


What do you think?

[yorik]

- wall local x axis should be the wall axis.

I still think a wall might not have any clear axis... What of a curved wall, for ex.?

[carlopav]

I still think a wall might not have any clear axis... What of a curved wall, for ex.?

I have quite some ideas for the curved wall, but It's not on my todo list yet.
What i'd like is that the Wall placement is in some way meaningful to describe the 3d geometry:
- for example that the x axis hosts the startpoint and endpoint of the segment of a "linear" wall;
- or that the x axis hosts the startpoint and endpoint of an arc segment;
- in general the xy plane hosts what we call the axis... (also if I do not surely know what is that)

Of course you could substitute the default shape with whichever object you want (circle, piramid, bsplinesurface), so at that point the placement will not be anymore meaningful to the object shape, but in that case - in my opinion - you can also understand that many joining automations will just not work.

What do you think?

Any ideas on the other points?

[yorik]

Yes, definitely. In absolute terms, the placement of a shape can be anything. But for specific objects where we can control it, of course we can place it somewhere more meaningful. For example, the Draft Rectangle always has its placement at a corner, and the Draft Wire at its first point.
I think you got the idea perfectly, nowhere in FreeCAD when we deal with a shape we should assume that the placement is at some specific place, but if we meet a specific, well-defined object with consistent placement, then it can be a good shortcut. As a simple example, the Placement of a sketch always gives you the plane where that sketch lies.

[vanuan]

Is it possible to link the wall to the Axis? So that when you move an Axis, a wall is moved along with it? Shouldn't an Axis system be the reference grid for the walls?

[carlopav]

Not yet, but this can be an interesting feature to implement... I'll think about it.

[vanuan]

It would be an awesome feature. That's the only thing that is unclear to me with this approach: constraints/locks/pins. That is, how do I "lock/pin" the wall so that it doesn't move. Or so that it moves, but the angle or dimension remains constant. Or so that it doesn't move, but I can scale it up and down relative to some reference point.

[carlopav]

That's the only thing that is unclear to me with this approach: constraints/locks/pins. That is, how do I "lock/pin" the wall so that it doesn't move. Or so that it moves, but the angle or dimension remains constant. Or so that it doesn't move, but I can scale it up and down relative to some reference point.

What I was thinking is that the wall can keep a link to the subelement we want to bound the wall axis to (let's say an edge or an axis line).
When this linked subelement changes, the wall is notified and it's placement is changed accordingly.
When the wall placement changes, it's axis is recomputed on the fly and the wall auto-connect to the other walls.
The only thing that i'm not sure and i'd like to try is that this could trigger an error "object still touched after recompute", but i do not think this is the case, because the only thing that should trigger recompute is the third step.