Do walls always have higher priority in intersections with slabs or not? If so, this priority is not always consistent and persistent. Either we should manually control interferences with interferences functions, or this should be fixed. As you can see wall is not cutting the slab. With vaUpdate this is not getting corrected.
Hi @GabrielB Up to VisualARQ 3.10, wall layers have priority over slab layers in equal conditions (same type). We have changed this behavior in the upcoming VisualARQ 3.11 update, where slab layers will always have priority over wall layers of the same type.
Why is this change needed? I mean, we try to build up strategy routines, and now we have the opposite behavior. I would like to see why slabs over walls is better then walls over slabs. In my opinion, we should work with interferences and 100% control.
The change you mention, is breaking a very important workaround for linking geometry to grid guides.
The only way to have connected corners of walls are guides. And when the guide is changing location the walls follow this change. Slabs if created with snaps onto guides, they follow the guides changes as well.
So with the change you mention, this will not work and when we want to have slabs interior of walls, we should snap in the interior faces and when guides are changing the slabs do not follow.
And we will end up with slab faces in the wall exterior faces.
We don’t you leave the priority to the user to work with various workflows and strategies per user preference?
I am a bit worried about this change. You know we build workflows based on the way VA functions and they become fragile if updates of VA change dramatically the way VA works. Again, at least if possible with VA 3.11, if the mentioned refactor is needed, then the preference of which has more priority should be set by the user.
In order to make it clearer, so if all the projects (past and ongoing) are built with walls over slabs priority, after the update, no project can be opened safely? Please consider revising this.
We can review this change. However, I think that in most cases, CORE slab layers tend to take priority at intersections with CORE wall layers. The same applies to “Normal” layers. There may always be exceptions, but in a construction process, slabs rest on walls and columns, which is why it is more common for slabs to cut walls rather than the other way around.
We know this is an important change, so we are willing to reconsider it.
If you had to choose one object, which one do you think should have priority?
I agree that the ideal solution would be to let the user decide and define the intersection priority criteria, but that involves more interface work, and I don’t think we will be able to implement it until a future version of the program, although we will look into it anyway. This change in 3.11 is due to an incorrect decision when defining the intersection criteria between walls and slabs in VisualARQ 3, as some users had complained about this behavior.
Even so, you will still have some control over these intersections by working with the “Normal/Core” layer type for walls and slabs. In other words, if you don’t want a slab to cut a wall, you can mark that wall layer as “Core” and the slab layer as “Normal.”
You can set a higher value for the guide snap radius, so you don’t have to draw the slab exactly on the guide:
What do you think?
Fransesc as you know better than me, software usage and preferences upon this, involve always specific workflows, workarounds, developement via scripting etc. I agree, maybe the decision was incorrect. But now, it’s crucial not to loose all the work done in VA in previous and current projects. This is clear and straightforward.
My suggestion is to delay the refactor of the software, on such a centric function and provide a more holistic intersection behavior, involving suggestions of users including mine, for example locking walls-corners etc. On the core of the refactor you are thinking of providing with the 3.11 version, normal and core functions should be enchanced, as discussed in other topics. Personally I do not use always core. In a gypsub-board, the air-stud layer should be core. But should it be core or another function?
Moreover, grid radius is not accurate and cannot be the solution for accurate intersections. Not all models are simple like the one you provided. Take for example a model i’ve already sent to you in the past. I’ve set a guides system very complex but in order to be controllable 100%, in order to overcome VA limitations. Take in mind that i use alignment offsets for this scope, which I bet will not work nicely and accurately with the planned change or the guide radius.
Please consider about ealier comments about the way va-dev team priotizes changes and software improvement. I believe giving the right value on users’ time and effort and suggestions is the way to go. But user personal preference must be kept important and for this reason more complex preference dialogues etc might be always built instead of making big changes without taking into account the workflows involved.
If I were to respond about what I prefer, it depends, concrete building or metal stud one? or timber one? functions and types should be enchanced before any major change in my opinion.
Also why don’t you start by improving the layer-offsets system? It’s taking ages to create proper intersections with the current byobject offseting system. We are doing work that should be done in an hour, in 2 days. THere are things should be improved strategically and once more i suggest providing a bible on how to work with va, on all aspects.
I don’t think this change will make you loose your work. I can send you an internal version of the 3.11 if you want to test this in advance and see how the program behaves with your models. If there are situations where the change goes for bad, we can reconsider this change or find some solution for them.
This change is based on an error of how the slab-wall intersections were meant to be initially.
Core and Normal are layer types, not functions (which is a useless property of wall layers right now). In future versions we will add improvements related to Core/Normal and Layer Functions behavior.
Core and Normal layers are meant to be used for controlling the wall intersections, where Core layers will tend to intersect each other, and Normal layers will wrap around the Core layers. Therefore, in a gypsum-board wall, the air stud layer should be a Core type, if you want it to connect with the air stud layers of other walls.
Do you have examples of this innacuracy?
Keep in mind that you can also have different guide styles, according to the object types they work with, so you get a better control of the linked objects:
What do you mean? can you provide more information about this?
I don’t think this change will make you loose your work. I can send you an internal version of the 3.11 if you want to test this in advance and see how the program behaves with your models. If there are situations where the change goes for bad, we can reconsider this change or find some solution for them.
I’ll can you some .3dms and maybe your team can test for situations that the change goes bad. I’ve not got the time test every single situation, report and discuss about. I am sure it’s going to break things. The BEST solution is not to have default priority that not changes, but to have priority set by the user. I am wondering, why in walls intersections you have the butt, miter, 1, 2 options for priorities between walls (which does not work optimally for sure) and you do not plan a logic of intersections between wall and slab, with 1, 2 priorities as well?
Core and Normal layers are meant to be used for controlling the wall intersections, where Core layers will tend to intersect each other, and Normal layers will wrap around the Core layers. Therefore, in a gypsum-board wall, the air stud layer should be a Core type, if you want it to connect with the air stud layers of other walls.
There should be more options than core/normal. At first, core /normal should be only a checkbox wether is core or not (boolean). Normal is useless. The core/normal should become more robust by working along with functions. Not all core should connect with all core. There are priorities for example is the same priority between a gypsum-board wall with stud-air layer that as you say and I agree should be core and a stone wall that has core in the stone, but from the inside we have air-stud layer as well that should also be core? Then this wall has two core layers, how does this affect the way the intersections are done? Core + function + better centerline control combination must be the key for this. * by centerline I mean, to enrich the exterior, center, interior and the top, center, bottom of walls and slabs with centerlines, exterior and interior per function like in revit → exterior[4], interior[5], structure[1], substrate[2], air[3]. Imagine the control we could have of such a combination. Anything else is producing problems
Do you have examples of this innacuracy?
Of course. guides are supposed to be continuous and run through multiple wall-styles. If you have thickness of 25cm, 50cm, 110cm walls connected, which is a very simple scenario (I have worse to think about as well) and common in restorations and existing buildings, with various alignment offsets applied (offsets like 0.60m in many cases from the guide), which guide style would you select, how many of them would you use, and how complex the guide system would result to be? If I have to use 3 guides along 5 walls, it’s not a solution.
Keep in mind that you can also have different guide styles, according to the object types they work with, so you get a better control of the linked objects:
Useful, but the whole workflow is getting overcomplexing and this should not have to with controlling slabs due to the planned change. This is used only for example to have diffferent sets of guides in order to control different things.
What do you mean? can you provide more information about this?
The layer-offsets system, is byobject, it’s very slow, it lags all the workflow 100x times. It has bugs like highlighted text is for all the wall-layers instead for the text you’ve actually highlighted, and a simple intersection between wall and slab, if you want to cover the slab’s vertical edges, takes a significan amount of time and it’s focused on specific cases, not able to be reused as a rule for specific cases. That’s the problem with byobject settings. What I was suggesting is why don’t you leave for now the wall-slab intersection and start fixing the system as a whole, starting from alignment offsets, continuing with core/normal+function+centerlines?
Yes please. Share a file to test. Please indicate in which parts you are afraid the change will affect the model.
Well, this is something we can implement, but it will take time. It’s something to study for future versions.
Ok, these are interesting suggestions to improve the wall-slab intersections. But we can only do this in future versions. In order to address this properly, we need to see specific cases where the current intersections options are not enough or hard to handle. The more cases you can provide, the better to find a good solution.
I need an example to better understand the scenario you are facing. Perhaps a single guide can be enough to link walls of different thicknesses with guides, so this should work properly already.
Layer offsets can be set by style, not necessarily by object.
I don’t understand what you mean here.
The change on the wall-slab intersections criteria is a necessary change since it was not properly implemented from the beginning. The option to set wall alignments according to their layers (if I understand you properly), is a new feature/improvement set to a future version.
There are cases where normal core system is useful, but maybe as a future development where the user can define in the settings a hierarchy, as long as the settings allow to set primary and secondary normal and core assignments.
For example a wall with primary normal cuts through a wall with secondary normal, while a core wall (or any other core assignment) cuts through both.
This would solve cases where dual setting of core normal are not sufficient to solve, like the one i have already described where when inserting a door to an interior wall which is built on the slab level, there is not a combination of core normal settings to somehow have the small part of interior wall removed, that is left there from the door that is constructed on the final floor level. (That small part lies exactly under the door and has in section the thickness of the substrate and final floor construction)
I am sure there are other cases too.
best
alex.
Thanks for this suggestion. We will consider it when we improve the options for solving wall and slab intersections.