Walls are not affected by sublevel's elevation

VisualARQ
1

Hi

the wall should change with sub-level’s elevation. No?

magnet-wall

I’ve sent to you the .3dm by e-mail.

2

Hi @GabrielB got your file! we will revise this case. The problem seems related to walls that end in a sub-level of a different level where they are located.

3

Hi @fsalla,

I believe I tested the wall end with a normal Level as well, not only a Sub-level, and I think I managed to get the same inconsistent behaviour. I’ll try to reproduce it properly.

My feeling is that the current mechanism may be too dependent on the sequence of actions. For example:

  • create a Sub-level with constraints/magnet off;
  • move the wall end to that Sub-level;
  • enable the magnet afterwards;
  • then change the Sub-level elevation.

This may behave differently from:

  • enabling the magnet first;
  • then moving the wall end to the Sub-level;
  • or creating the Wall only after the Level constraint is already active.

There are several variations like this, and I suspect the same may also apply to normal Levels.

This is why I think this needs to be tested a little more holistically rather than only checking whether one specific sequence works. Ideally, once a wall end is associated with a Level/Sub-level, I would expect that relationship to remain deterministic regardless of the order in which it was created.

A more explicit Base / Top Level constraint, similar in concept to what Revit uses, seems more reliable to me than an inferred relationship based on position and the current magnet state.

This also connects a little with the broader workflow question I have raised before: Wall connections strategy - desired outcome.

For example, in practice we usually create separate Walls per floor, even when they are nominally the same Wall, because small differences between floors and intersections can make a continuous multi-storey Wall difficult to manage. But whether this is actually the recommended VisualARQ workflow is part of that larger question.

I don’t want to mix the broader workflow discussion too much with this specific issue. For now, I think the important thing is to check whether the Wall–Level/Sub-level relationship works consistently under the different normal ways a user may create and edit it.

And since VA4 is coming, I think it would be useful to look at these things a bit more holistically as well: how Walls should relate to Levels, how they should be split or continue between floors, how constraints should work, and what the recommended project setup should actually be.

4

Hi @GabrielB, the way the Level Constraints work is simple. When you activate the magnet on a level and change its elevation:

  • Objects sitting on that level or located within that level and the upper one update their elevation.
  • VisualARQ Objects that have a Height (walls, stairs, curtain walls, etc) and are finishing in that level, adjust their height to the new level elevation

Anything else that is not behaving like this needs to be revised. You reported an issue recently that has been fixed in the upcoming 3.13 RC2 release (it affected objects that were going through different levels and sub-levels).

Yes, this is something in our roadmap to develop this feature further. But we want to keep it simple from the user experience point of view.