Wall join problem with coplanar walls

Hello!
I’m working on a project where a finish/facade sits on top of a structural timber wall. The finish does not cover the entire wall, but will be cut along some curvature (In fact it will be 3 or 4 different finishes, on top of each other, touching at some curves along the facade).
I use vaWallExtend to cut the facade with some planes.
For that reason, I had to create different wall styles, since one wall layer cannot be used with vaWallExtend, right?

However, now I have problems joining the walls correctly now - see screenshot.

I tried all ‘Sort Order’ combinations…

On the left example, it seems to work with Sort Order 4, but not really, since it’s not a correct miter.
The right example is a copy/paste piece of wall from the actual project - I couldn’t manage to make the facade join at all!

Is there anything I can do except moving the whole facade to another location to make it ignore the structural wall and join correctly?
I played with the Cleanup Radius and Maximum Extension parameters, also, but to no avail.

Wish:
Could there be some ID parameter on walls, slabs etc., so only walls that share a common ID will join, the others will be ignored?
Should be fairly simple to implement.
Yet I understand that VisualArq follows BIM standards…

In my opinion the whole approach with ‘Sort Orders’ is impractical. I made this experience in Revit, too. There can be dozens of joint variations, and one has to toggle through all of them to find the right one. Bad idea…

Maybe you could have a look at the attached file - can you manage to make the gray facade pieces join?
Thanks a lot!!
Best regards
Eugen

wall joints problem.3dm (611.5 KB)

Hi Eugen, we need to figure out why the join is not working properly after extending the walls. Apparently this issue seems to be caused by the fact you have two walls to close along the same path. The fact the wall style has 1 or more layers should not affect whether it can be extended or not.
As a workaround you can try to use the vaSubtractSolids command and an auxiliary volume of subtraction (you can extrude the polysurface you have used to extend the walls to). It would help if rather than 2 walls with 2+1 layers you had one single wall with 3 layers and then locate the volume of subtraction aligned with the desired layer to trim.

Regarding the wish of wall joins, we will study how to improve it.

Kind regards,

Thanks, Francesc!

That’s the problem - too many walls intermingle, yet I want them to be on the construction line.

Allow me to suggest this ‘connection-ID-thing’ again:
Every object could have a list of IDs (integers). Default is [0]. Could be [1,7,23] also.
The first thing your auto-conneciton algorithm does is check if two objects share at least one common ID, and second, if they are inside the Cleanup Radius, and only then are they connected.

The facade problem here could then be solved easily by giving the interior walls ID 0, and the facades ID 1.

Some time ago we talked about the problem that it’s not possible to keep old VA parts in the scene on some hidden layer, because they always interfere. Could also be solved easily the same way.

Using vaSubtractSolids might be a solution for now. Trying it out now…

Cheers!
Best regards
Eugen

1 Like

Hi @Eugen,

Using two (or more) parallel wall objects to represent a real single wall is not a good solution. It could work in some situations, but it is problematic in many cases and I don’t recommend using it. It may make fail the following processes:

  • Space calculation
  • Wall connections
  • Door / window placement
  • IFC export
  • etc.

The best currently working solution is the one that @fsalla suggest: use vaSubtractSolids command. The only problem I see with this solution is that you may have to redo this operation if you modify the walls.

I’ve been thinking how to solve this in a future VisualARQ release, and these are the solutions that I found:

  1. Allow the command vaWallExtend to specify which layers are affected by this extension. This data will be lost if the wall style changes.

  2. Allow to specify which operations will be applied to each wall layer using some check boxes. For example:

    • Top extension.
    • Bottom extension.
    • Door / Window opening hole.
  3. Make a command like BlockEdit, called vaWallEdit or vaElementEdit for example, that allows to modify parts of the element individually. Allowed modifications could be:

    • Attributes (layer, color, material, etc)
    • Custom parameters
    • Element operations (booleans, extension, etc)

I think that the third option is the most powerful and probably the most intuitive. What do you think?

Enric

Hi!
Hard to say, since I have little insight into VA’s internal way of storing objects.
What you say in 3) about storing Materials and custom parameters per layer is already implemented, in the Wall Styles panel, is it not?
The only thing missing is a height profile, so 1) makes sense. How about a command called vaWallLayerExtend?
If someone changes layers afterwards and the information get lost - his fault. Would be ok.

Still, I’m not fully convinced that, in principal, using walls on walls is such a bad idea.
It’s not that uncommon in a building that walls touch. I’ve seen it recently on a site.

  • Space calculations… depends

  • Wall connections… true, as it is. If we had a more granular way of defining which wall connects to wich, it would surely help.
    Maybe you think about this ID thing, too?

  • Doors/windows… true. However, if vaOpening could quickly grab the shape of a door/window…

  • IFC export… not sure.

Revit is pretty sophisticated when it comes to wall layers and their heights:

Not sure if I like fumbling on wall’s geometry deep down some dialog instead of the viewport, but they surely invested a thought or two into the topic.

Regarding using vaSubtractSolids:
The fact that one looses parametricism by using this approach weighs pretty high, does it not?
And, will there be troubles with coplanar faces/z-fighting/artifacts when I cut away the topmost layer exactly at the layer’s border, or is the boolean algorithm smart enough?

Thanks a lot!
Best regards
Eugen

Hi @Eugen,

That’s exactly what I mean with the option 1, allow to extend the whole wall, or only some or just 1 layer.

In Revit, you can explode the wall into its parts (wall layers), and then edit them individually. That is, more or less, the same I proposed on option 3.

That’s true, you could have some boolean problems with coplanar faces.

Probably the vaWallLayerExtend command is the simplest implementation. We’ll try to add it in a future VisualARQ 2 update.

Thanks,

Enric

1 Like

Complex topic, indeed. I trust you will find a smart solution! =]
Thank you!

… and maybe you introduce a way to prevent walls/objects from joining (besides the Cleanup Radius) as well… =D

1 Like

They all seem very useful!

If I understand them correctly: EDIT revised after re-reading

  1. Manual, per-object command; generally suitable for simple junctions
    (If the VaWallLayerExtend command was used then afterwards someone changed the wall & the customisation are lost, would undo command bring it back?)

  2. Procedural/applied to styles (types) to influence commands used on those objects by those subsequent commands. suitable for more complex junctions/interactions

  3. Manual and while powerful/suitable for all junctions/interactions IT IS MANUAL…

I definitely have a preference for procedural/rule based for workflow; though the control of a more powerful implimentstion can be useful.

P.s. As a Revit user I only model co-planar walls (or even walls with co-planar faces) to allow for more complex staged disassembly of parts of wall; for relining a lift lobby for example. And it’s rare. Even walls with parts & seperate/specific control over the parts is not common on the projects I work on in AU.

If the different layers were different scope (completed by different trade contractors) it might make sense to Have two adjacent elements (rather than one compound element)?

I’m super curious about the use cases being considered here…

:+1:
There are cases where adjacent walls that should not join do make sense. If it would be possible to have walls (or any other object) side-by-side without having them auto-connect… (nag, nag)

If you don’t want to do this, at least, in the ‘Sort Order’ parameter of the wall joint, there should be enough variations to find one that suits - outer walls have correct mitering, and interior walls, too.
In my wall testscene, the right 4 walls only offer 2 Sort Order variations.

Btw., Revit has a tool called “Wall Join” to toggle through all the joint variations (as you might know). It even has a warning message like “…would be more than 50 variations, are you sure…”. However, it has it’s own quirks and problems with the topic.

Thanks!
Best regards
Eugen

Hi!
I didn’t mention before that in fact the client wants multiple facade designs on the structural wall (seriously).
Something like this:

Plus windows/doors of course. Might be a rare case, but it’s going to happen nonetheless.

So in this case there are even 4 walls overlapping. I see no way to get the corner miterings right with VA walls.
Still investigating a way to achieve this… any tips?

What I tried to suggest before was introducing some kind of ‘join groups’. Only walls that are inside such a join group (simple IDs per object) are connected.

Thanks a lot!
Best regards
Eugen

My brain still drills back to ‘are they carried out by different trades’

Or it is a precast wall with three applied finishes?

It’s solid timber walls (still very rare in eastern Austria) with 3 different finishes.
The client has a faible for Gaudí =) and he thinks sustainable and ecological. We all do.
Building design is not mine, however, but I don’t complain helping them realize something off the beaten track - like it or not, it’s got spirit!

@Eugen, running the command vaSubtractSolids command on these walls is the most feasible solution up to now, although you might not want to play with the walls length and joint position after that operation, or you will go crazy. You can also generate a Grasshopper definition that automates that process.

Hello!
Ok, thanks! Sounds like an idea. I’ll try…