Any ideas on how to make T and X joint multilayered walls?

[ABeton]

So the question is how would this kind of walls be programmed? I mean just a description of it would be useful. I am in the process of going through some older forum discussions, more specifically paullee’s and carlopav’s posts on how they built walls using two different approaches. It is a very interesting read.

For example most payed BIM software have separate walls so they can easily be moved individually. I like this approach because it is simple for users. So I have been trying to understand how these programs create T and X joints of multilayered walls so that they blend seamlessly. It would be a really nice feature to have in FreeCAD. Any ideas on this?

[carlopav]

Hello there, interesting topic to me and good to have it in Open discussion to gain more visibility

you should definitely ping @yorik here.

ping

First I do not think that many softwares out there represent wall layers in 3d... IMO they represent the wall in 3d as a full solid, and layers are only computed in 2d representations (plan views and sections). But that's just a guess...
Also in my experience the auto join feature is something very error prone, and you have always to take into account that you will have to refine it somehow. Just think that many people out there, when coming to a construction phase, they draw each wall layer as a separate wall... frightening...
I really do not think that it is possible to write an algorithm that always predict the result the user expects. So in my opinion is really important for the user to be able to tweak it somehow after the software guess it...

Anyway, you should check out the IFC definition of a material layer this, and expecially the priority attribute:

The relative priority of the layer, expressed as normalised integer range [0..100]. Controls how layers intersect in connections and corners of building elements: a layer from one element protrudes into (i.e. displaces) a layer from another element in a joint of these elements if the former element's layer has higher priority than the latter. The priority value for a material layer in an element has to be set and maintained by software applications in relation to the material layers in connected elements.

I do not think that Arch_MultiMaterial support layer priority. So this could be a first thing to support, but then we need to enable the geometry generation to take that into account.

For example most payed BIM software have separate walls so they can easily be moved individually. I like this approach because it is simple for users.

I agree with you here, anyway I also think this is just a matter of how the user interact with the object: we could for example 1) keep each wall separate as I tried to do, but also 2) have just a single wall object based on as sketch as @paullee is doing, and create some modifiers that allow the user to interact with each wall segment as they were separated walls...

So the possibilities are a lot, and all of them are less or more opened at the moment

To finish, nice to read that more than one person is going through the topics of last year, it really give the power of open source and of the FC forum! So, about the experiments I was carrying on with the support of @realthunder (I wouldn't even had started without this) and all the others that you will spot in the topics, I mainly concentrated in joining the wall ends, X joint was expected to be treated as two T joints.

[onekk]

what you intend to priorities:

1) if use the fuse option, it will be a boolean join, so no priorities.
2) if you leave it two separate entities, the overlap is not a problem.

Speaking of separate entities, I see no problem at all in placing things, maybe if you state a dimension, to make the thing overlap you have to add, say 1/10 or 1/20 of the other wall thickness to the original dimension, to make the thing "intersect" and have been visualized without gaps.


I think that adding a properties like "prioritiy on joins", and make some assumptions during the "fusion part", that I think, could be done in "the visualization routine", this way the lenght of the wall is retained and only when visualizing it could be "enlarged to fit".

As I'm not an expert of GUI but from what I've seen also the update or the recompute could do the job, a sort of two level.

During recomputing if the wall is marked to be "joined" it will be "enlarged by an amount" and visualized so there are no gaps between parts, but hid Length property could be retained with the "original dimension".

If the wall is not marked to join, the "original dimension" could be visualized without enlarging.

I don't know enough Arch to know implications and relation between tools, and how the different tools use object properties.

And i don't know if it is possible to implement such "two level visualization" routine, "with or without" the "join level" and the "this element is joined" properties.

I think that also a "join position" and maybe a reference on "with walls it has to be joined" properties (in this case a list, as you could have one, two or more elements), has to be added to achieve such thing.

And I don't know if IFC will support this sort of things, as usual, if IFC is implementing it, maybe an eye on the way it is implemented could be an useful help.

I know the position of Yorick about the fact that FreeCAD has not to mimic "IFC" as the underlying things are different, but as many people ask for "compatibility" and "interoperability" of FreeCAD in "work environments" I think that some "compromises" have to be done.

My two cents (or maybe five)

Regards

Carlo D.

[ABeton]

Hello there, interesting topic to me and good to have it in Open discussion to gain more visibility

you should definitely ping @yorik here.

ping

First I do not think that many softwares out there represent wall layers in 3d... IMO they represent the wall in 3d as a full solid, and layers are only computed in 2d representations (plan views and sections). But that's just a guess...
Also in my experience the auto join feature is something very error prone, and you have always to take into account that you will have to refine it somehow. Just think that many people out there, when coming to a construction phase, they draw each wall layer as a separate wall... frightening...
I really do not think that it is possible to write an algorithm that always predict the result the user expects. So in my opinion is really important for the user to be able to tweak it somehow after the software guess it...

Anyway, you should check out the IFC definition of a material layer this, and expecially the priority attribute:

The relative priority of the layer, expressed as normalised integer range [0..100]. Controls how layers intersect in connections and corners of building elements: a layer from one element protrudes into (i.e. displaces) a layer from another element in a joint of these elements if the former element's layer has higher priority than the latter. The priority value for a material layer in an element has to be set and maintained by software applications in relation to the material layers in connected elements.

I do not think that Arch_MultiMaterial support layer priority. So this could be a first thing to support, but then we need to enable the geometry generation to take that into account.

For example most payed BIM software have separate walls so they can easily be moved individually. I like this approach because it is simple for users.

I agree with you here, anyway I also think this is just a matter of how the user interact with the object: we could for example 1) keep each wall separate as I tried to do, but also 2) have just a single wall object based on as sketch as @paullee is doing, and create some modifiers that allow the user to interact with each wall segment as they were separated walls...

So the possibilities are a lot, and all of them are less or more opened at the moment

To finish, nice to read that more than one person is going through the topics of last year, it really give the power of open source and of the FC forum! So, about the experiments I was carrying on with the support of @realthunder (I wouldn't even had started without this) and all the others that you will spot in the topics, I mainly concentrated in joining the wall ends, X joint was expected to be treated as two T joints.

Thank you for a detailed response I agree it is mostly important to have layers displayed in 2D, 3D would be optional.

I drew each layer in FreeCAD one by one... so much fun We need something automated for sure. The priorities principle makes sense, that we definitley need to implement. I guess it will be important to chose what wall generation principle it would be best to work with. Like you said we have the already implemented walls by Yorik, the walls you did, and the ones Paullee did. I am not sure yet what approach would be best at the end.

Also I experimented a bit with boolean unions and differences. What could perhaps work is to create a boolean union group of all layers that have the same priority number, and than do a difference boolean union groups based on these priorities(from 1 to 100 for example). I made a simple example(forgot to save it of course ) without coding. The main concern here would be the computing speed. All these unions and differences... just lovely

what you intend to priorities:

1) if use the fuse option, it will be a boolean join, so no priorities.
2) if you leave it two separate entities, the overlap is not a problem.

Speaking of separate entities, I see no problem at all in placing things, maybe if you state a dimension, to make the thing overlap you have to add, say 1/10 or 1/20 of the other wall thickness to the original dimension, to make the thing "intersect" and have been visualized without gaps.


I think that adding a properties like "prioritiy on joins", and make some assumptions during the "fusion part", that I think, could be done in "the visualization routine", this way the lenght of the wall is retained and only when visualizing it could be "enlarged to fit".

As I'm not an expert of GUI but from what I've seen also the update or the recompute could do the job, a sort of two level.

During recomputing if the wall is marked to be "joined" it will be "enlarged by an amount" and visualized so there are no gaps between parts, but hid Length property could be retained with the "original dimension".

If the wall is not marked to join, the "original dimension" could be visualized without enlarging.

I don't know enough Arch to know implications and relation between tools, and how the different tools use object properties.

And i don't know if it is possible to implement such "two level visualization" routine, "with or without" the "join level" and the "this element is joined" properties.

I think that also a "join position" and maybe a reference on "with walls it has to be joined" properties (in this case a list, as you could have one, two or more elements), has to be added to achieve such thing.

And I don't know if IFC will support this sort of things, as usual, if IFC is implementing it, maybe an eye on the way it is implemented could be an useful help.

I know the position of Yorick about the fact that FreeCAD has not to mimic "IFC" as the underlying things are different, but as many people ask for "compatibility" and "interoperability" of FreeCAD in "work environments" I think that some "compromises" have to be done.

My two cents (or maybe five)

Regards

Carlo D.

Thank you for the detailed response as well

It would be interesting to know if the visual and real model could be displayed differently. Like you to have them displayed without gaps.

The experimental walls Carlopav made use a similar principle of joining walls I think as you mention. Where users can select to walls and use a command to join them.

For starters if we could create a working example of this it would be great, later we can worry about IFC

[onekk]

@ABeton computing speed is somewhat critical, in fusion, as many things could do wrong, especially if you fuse some walls, and maybe you want to fuse them on a window or door.

I think that maybe it would be possible do do things, in another manner, I don't know if it is possible, when moving a wall to make the positioning, a copy of the wall is used, retaining the original reference as "data", or maybe using a wireframe of the wall.

When the wall is correctly positioned, the original copy is used to build the correct wall and fuse it, but fusion maybe is not needed, as if the "destination" wall has an high "priority" the moved wall could be simply "enlarged and left "entering" the "high priority" wall.

But usually an example to work on would be useful, at least to see what is not working "right" in the actual implementation.

As if you have and angled wall, there are ever the "edge" line visualized, so the difference with a fusion and two overlapping solids are minimal, I suppose that you will se on the top of the bottom the original lines, so maybe a simple different "visualization" routine that hide those line will be sufficient a part for the enlarging".

Another way could be to make a "static" copy of the wall, built with all his features and fuse only "static copies".

For static sopies I think of the "final solid" of the wall, not having to cope with all the "intermediate features", and retain the reference to the original "object", in this manner some assumption could be made:

1) Visualization is done only with the "static copies"
2) if you need to "edit" a wall when you click on the wall the selection point is used to choose the "original object" and you modify the "original object".
3) a new "static copy" is created with the "original object" modified data.

Obviously also in this scenario there are some "recompute" time to take in account, but a solid creation is not too heavy.

Some experiment could be done, or maybe could be see how PartDesign or Assembly workbench will manage complex things, so maybe pinging @realthunder or contact him by PM or other ways could be a more interesting discussion.

In a very simplified thinking, there is no difference between a "Part Design" or "Assembly thing" and a full featured wall.

Regards

Carlo D.

[paullee]

Glad that @Abeton start to think how this should be tackled

Could be very complicated just to consider a T-joint. Hope there are more ideas here.

[carlopav]

Just for inspiration, another thing that i always found clever, is how GIS handle roads joining:

Cattura.JPG (47.12 KiB) Viewed 2318 times

the roads are not represented as 2 parallel lines, but as 2 coincident lines, one thicker than the other. the thicker is black and the thinner is white. rendering the thicker before the thinner makes X joint appear perfect without any boolean calculations

[ABeton]

Hi, sorry for the late answer, I was really busy in the last two weeks.

I went through the sugestions quickly and will have to do a more detailed reading of your posts. I made a quick test on a similar sistem to what you sugested carlopav, and it would perhaps be the simplest solution I tried it in 3D(of course walls are one inside another which is not nice) but visually it works very well What I did is, I just change the height of each wall a bit, so to represent them in different order. I think if we would have a dedicated 2D page we could easily apply this system and avoid most of the boolean stuff.

Perhaps we could modify the current multilayer walls to work in this way The inside layers would be placed above all others and than each other layer could be placed a bit lower than the previous one.

Bellow I attached just some images of the experiment.

Pasted Layer #1 (1).png (219.85 KiB) Viewed 2056 times

Pasted Layer (1).png (108.18 KiB) Viewed 2056 times

Pasted Layer #3.png (637.64 KiB) Viewed 2056 times

Pasted Layer #2 (1).png (248.35 KiB) Viewed 2056 times

[carlopav]

Nice, it's less or more what every layer could do with the given joint priority: be represented in front of the others when the priority is higher...
i'll be thinking more about that... thanks for visualizing it!

[ABeton]

Sure thing, I really think that this could be a solution to this problem Good that you remembered of the QGIS example Here is an example with outer and inner walls. I used two sketches as a base for the walls. One sketch for each different kind of walls.

Pasted Layer (2).png (147 KiB) Viewed 2035 times

Pasted Layer #1 (2).png (215.76 KiB) Viewed 2035 times