Guidelines problem / bug?

Hello,
I am trying to get some profits from guidelines, but there are (for me) at least 2 problems, just from the start. The first is, why these guidelines levitate over the model in some unpredictable manner? Here we are with top view:


But the 3D view shows some random location (and dynamic, it gets changed when the view is manipulated):

The second problem is that I cannot say what is connected to what… If I put a wall first, then a guideline, these two are connected - or not… Then, when I have a grid of guidelines I also would like to have intersection points as, let’s say, anchors. It means, moving one guideline should keep the wall at guidelines intersections. Now it doesn’t…


Maybe I am doing something wrong, what do you think?
Cheers, Jaro

Hi @jerry.bakowski,
Guides are displayed in projection on the current level’s CPlane, in Top and Perspective viewports. That’s why from the Perspective viewport they change location if you switch from one level to another, from the Level Manager.

Is that behavior consistent in your tests, or does that behavior make sense to you?

In the guide style options, you can tell the guide to be displayed on the level cplane or in every level’s elevation at the same time:

Objects get linked to guides as long as you snap on the guides when you insert them. You can break this link if the object moves away entirely from the guide, or if you unlink it from the Constraints option in the properties panel:

If you create a guide after an object, the object will get linked to the guide if any of its edges or vertex sits on the guide. In the case of walls, the walls will get linked to the guide also if the guide is aligned with any ot the edges of the wall or its central axis.

Guides also work as intersection anchors. If you draw a wall that ends on an intersection of 2 guides, the wall will be stretched or will move if you move any of these two guides. Doesn’t work like this for you?

Guides

All these details are explained in the User’s guide if you want to take a look (vaHelp). If something is unclear, I’ll appreciate your comments.

To clarify how guides (and level constraints) are implemented in VisualARQ 3:

Objects are never linked to guides. There is nothing stored in the document that says: “this object is linked to this guide”. When a guide is moved, the guide will look for all model objects that are geometrically “coincident” with the guide, and then modify them accordingly. It doesn’t matter if object or guide is created first.

Enric

Is it possible to make connect the wall to guide line so the face of the core is locked to the guide, not just the middle of the wall or the face of the wall? Thank you.

Hi @Kristjan,

Yes, you can define an alignment offset in the wall so that it is aligned to the guide:

2 Likes

Hi

I am struggling to get guidelines and layers to link to objects on VA3 beta.

Walls will initially link to a guideline if conincident, but if then detached and reattached the link is lost.

Levels do not seem to be linking to walls no matter what I do.

A simple drop down dialogue to select the host level and / or guidelines to link to would be so much more reliable. The links that an object is creating need to be able to be seen and edited by the user.

Revit has had a problem for years (ever) where it tries to guess whether an object is linked to grids or other objects, that can often make moving geometry (or flexing in the family editor) a bit of a nightmare.

Links must be specifically set to keep control of your project.

This is partly why Grasshopper is so amazing, as the relationships between objects is so explicitly controllable.

Hi @user1640 Crispin,

Do you have an example of this? walls should link to guides if any of their longitudinal bottom edges (or the wall center alignment) sits on the guide.

Wall-Guide

Also, check the “constraints” properties of the wall, and make sure the “link to guides” is checked:

Walls (and other objects) will update their location if you change a level’s elevation in the level manager, as long as the Constraints button of that level is enabled:

level manager constraints

If you don’t want objects to move by mistake when editing the level’s elevation, simply make sure the constraints button is off. Or you can disable the “Link to levels” setting by object in the Constraints section in the properties panel.

VisualARQ objects and Rhino geometry don’t have a property that says in which level they are. It automatically checks for the location of objects inside a level, and moves them up or down depending on the objects constraints settings and constraints status in the Level manager. We considered this behavior the most simple and user-friendly, but we are open to suggestions for future versions.

Hi Francesc

I’m aware of the settings - thanks. Have had a good play but neither are working in Rhino 8 for me sorry - gif attached.

Other issues are :

levels - plan view - cut plan set at level 3 - slab of level 4 above (by 3m) is being selected and moved - cut plane set at default 1400mm

linework - not being selected when coincident with VA objects - need to be able to cycle through object selection (tab key on Revit)

guides (grids) - osnaps - can’t snap to near or intersection - makes these unusable

osnaps - only working 70-80% of the time - very frustrating …

I’ll try and make a few more little gifs to demonstrate issues for your team.

Regards

Crispin

Hi Crispin, in the gif attached, you are not enabling the Constraints button next to the level you are editing in the Level Manager. So object won’t change their position when you change that level’s elevation.

I can see the wall doesn’t follow the guide when you move it. This may happen if the wall is not completely sitting on the guide from its central axis. If you share the file I can take a look, just in case there is an error from the VisualARQ side.

I assume you are selecting the slab located above from their “Overhead” representation. Perhaps we should prevent this from happening and don’t let objects be selected from their overhead representation. What do you think?

Please provide some example of this issue.

This should work. Please provide some example we can analyze.

Again, please provide some examples to reproduce this issue. There was a problem with the objects extension arrows, not snapping properly, that has been fixed in the next Beta. Maybe those issues are related to that. See this post: VA3 drag arrows don't seem to snap - #3 by arcus

It would be great to prevent accidentally selecting objects based on their “Overhead” representation. I’ve accidentally done that a few times and then had to hunt down the change and fix it.