[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:

• 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 (IfcLocalPlacement);
• 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.

[paullee]

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.

Are these kinds of constraints in Assembly WB ?

Sounds to me like sort of Sketcher constraints.

[carlopav]

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.

Precisely

[vanuan]

Are these kinds of constraints in Assembly WB ?
Sounds to me like sort of Sketcher constraints.

I don’t know whether they exist in Assembly (which one? There are 4 of them), but yeah, if we remove sketcher from walls, there should be an alternative line snapping. IMHO, walls can’t be snap lines themselves. Because of the toponaming problem.

[vanuan]

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

Yeah, assuming that new walls are essentially vectors with origin and length + intersection identifiers, they can function pretty much as lines and snap to anything. What worries me is the direction (topological naming issue).

With simple walls, where start and end of the wall are identical, there’s no issue with topology. But when it’s time to implement left/right/center alignment + multilayer walls, the order will matter. So there should be some reference (“positive” direction according to which left and right are determined). So that when you rotate a wall, it doesn’t change alignment, you have to change the alignment itself. When the wall snapped to an edge, it will depend on the alignment of that edge, which is inherently unstable due to the topological naming issue. But when it’s snapped to an axis system, the direction is stable since it’s impossible to change the direction of a single axis line.

The Axis system suffers from the toponaming issue itself, but at least you know that changing Axis order is dangerous. With re-introducing walls as a solid ground, it would be a pity if it has the very same issue as the original.

[vanuan]

Most BIMs solve this issue by requiring all connecting walls to be of the same direction (clockwise/anticlockwise):

I wonder whether it’s taken into an account. According to what I see now, this is solved by defining a 180 deg angle? To me, this doesn’t seem to be a sustainable approach.

[carlopav]

Wow. Great inputs. You are really helpful.
I think you got the point on several stuff, let me digest them, I have some crazy days at work…

[carlopav]

Wow. Great inputs. You are really helpful.
I think you got the point on several stuff

Yeah, assuming that new walls are essentially vectors with origin and length + intersection identifiers, they can function pretty much as lines and snap to anything. What worries me is the direction (topological naming issue).
With simple walls, where start and end of the wall are identical, there’s no issue with topology. But when it’s time to implement left/right/center alignment + multilayer walls, the order will matter.

I’m expecially happy to discuss this, since it’s something really crucial for a new implementation.
The proposed wall works like this:

• the placement is meaningful: the wall Axis is always locaded on the Placement X axis (at least for the default wall). First doubt: what should we call the axis? the middle line of the wall? the middle line of a core layer? a side of the Wall?;
• the wall object keep a property for the AxisFirstPointX of the axis and for the AxisLastPointX of the axis (their X coordinates) to locate them on the Placement X axis;
• the points can be inverted, but the actual wall object always build it’s shape for AxisFirstPointX < AxisLastPointX or invert the 2 points. This is weak and i’d like to change it (for example making relevant if the wall is built from x1>x2 or x1<x2). The point is: we should say that left direction is always LCS.y positive? or we should say that Placement is just meaningful for locating the wall axis and the right and left should depend on where the first point and end point are located on the axis? hope I could describe my doubt…

The wall does not currently suffer topological naming, but it will if we introduce layers. BTW we could also rely on object methods to make some under the hood calculations, like Wall.giveMeTheInnerFace(). What do you think?

The Axis system suffers from the toponaming issue itself, but at least you know that changing Axis order is dangerous. With re-introducing walls as a solid ground, it would be a pity if it has the very same issue as the original.

This could possibly change using sketches as grid system when we will be able to univocally refer to sketch subelements through a persistent tag (Abdullah is actually also working on that I think).

[paullee]

Most BIMs solve this issue by requiring all connecting walls to be of the same direction (clockwise/anticlockwise):
04_01_Walls_11.jpg


I wonder whether it’s taken into an account. According to what I see now, this is solved by defining a 180 deg angle? To me, this doesn’t seem to be a sustainable approach.

I can’t follow the discussion but seem interesting to know.

What is the reason behind having all walls in same direction ? How about a wall cluster not of a simple ‘口’ rectangle shape like ‘日’ ?

I work on using Sketches as Base of Wall, and now no matter what direction of each edge, Align would works on individual edge. Not sure if this is of any relevance.

[paullee]

This could possibly change using sketches as grid system when we will be able to univocally refer to sketch subelements through a persistent tag (Abdullah is actually also working on that I think).

Interested if Adbullah is working on it, any discussion ?

He once help to explain the tag is ‘semi-persistent’ and that’s what I work on to make something out to make the identification of edges stable.

Thanks

[carlopav]

Interested if Adbullah is working on it, any discussion ?

just what you already pointed to