WISH: Reclassifying Visualarq objects without exploding them

I find the vaBeam function to be good for sketching finishing details (see below). Being able to drag the extrusions as well as its auto-mitering capabilities are a godsend. However, there doesn’t appear any way of changing the ifc tag without exploding said objects (thereby losing its inherent display/print attributes). There’s also currently no option of deleting unused profiles?

Another quality of life improvement would be to allow for marking a custom insertion point for said profiles. If I have a bunch of curves grouped together into a single profile like in the picture below, the alignment function does not work (the “beam path control point” appears at an arbitrary location) and so becomes a slight hassle having to manually move each piece into position.

1 Like

Hi @himwailai,

VisualARQ objects can’t get a different ifc type than the object type they are. This is made on purpose in order that a Beam can’t be tagged as a Window, (for example). Only the “Element” object (which is a generic object) can get any ifc type.
But I guess that for the beam object, there might be other ifc types that could apply. Which ones are you interested in?

That’s in our wish-list. I’ll let you know when we implement this feature.

Hello @fsalla ,

Thanks for the response. The idea is to push the model-space beyond its current capabilities for outputting general building plans and into the realm of integrating working details. The picture in the previous post, for example, is composed of multiple profiles: one for the balustrade, one for the glass panel, one for the flashing and one for the seals/gaskets. Another example below:

I’ve utilised the Beam function to generate the window detail, the staircase finish, and even some of the wall finishings that wrap around the actual Wall element (the less “intelligent” joining makes it easier to control at intersections than utilising a multilayered wall).

So yes, I would like to be able to tag the beam as a window, wall, railing etc. Maintaining them as Visualarq elements as opposed to exploding the geometry also allows for solid operations more flexible than the default Rhino Boolean system which do not “remember” the additions/subtractions made. Another reason would be to preserve the linework output/section attributes of the profiles.

Sketching details in this manner means the list of profiles will build up very quickly and so it would be nice if there was a better system of curating/renaming/deleting profiles.

Attached is the file I’ve been sketching some of these details (refer to section B). I don’t know how typical a use-case my problems are, but I do hope it provides some insight into how the preexisting Visualarq functions could be further modified. (Apologies for such a long-winded post.)

Hi @himwailai,
In future versions, we have plans to provide a “Profile Manager” function that will let you edit the custom profiles you have created, edit them, change its name, etc… I guess it will be quite useful for you, after seeing the way you squeeze the beam tool from custom profiles.
I’ve actually never seen the beam tool being used for all these stair details, openings framing, etc.
In some cases it makes sense, but in other cases, like the railing in the balcony, or the wall external layer, could have been done differently (why don’t you create the wall external layer as a multilayer wall?)


Hello @fsalla ,

A profile manager would be great!

I plan to automate some of the more banal details through grasshopper definitions in the future. However, not everyone in my workplace is so technically inclined and so using the Beam function this way could allow them to further the model-space and output relevant drawings in a suitable timeframe.

As for multilayer walls, early stage submissions usually do not require accounting for wall finishes (at least where I live) so when the time comes to add it back in, all the walls must be realigned. Multilayer walls also have a tendency to bug out at more complex intersections (3 or more walls coming together) and when they are not, it becomes a chore cycling through the 10+ joining options to find the right one. Walls in general also seem more taxing on computer performance than other Visualarq elements? So finding other methods of drawing the finishes and maintaining a lower wall count helps to keep the file usable.

In the case of the window in the previous post, there’s currently no method of wrapping the outer finish into the opening created by a solid subtraction?

1 Like


I’m interested to see any bug you experience with wall joins so we can take a look and fix any possible errors. When two walls join, you have just 2 solutions. If 3 walls join, then you get 6 solutions. In the case of 4 wall joins, (which is not very usual) then you have 24 solutions (which I agree it’s a lot to test back and forth. However, I didn’t find any 4 wall join case in your file).
I still think it’s way easier to work with multilayer walls than using beams to do the wall wrappings (it requires extra work to do all the subtractions when there are openings, and update them when moving openings).
In terms of performance, the difference of using multilayer walls vs walls+beams should not be significant. The performance gets affected when a single wall with multiple layers has many openings in it, or it intersects with a big number of columns (since columns subtract their volume on the wall). If you experience an unexpected slow performance with your models, please let me know, and we will analyze it.

Thanks, I’ll let you know if I come across any weird interactions in the future.

I know these questions aren’t relevant to the title post; should I start a new thread?

Given the scale of the projects I currently have to handle, I find one floor per file seems ideal (with all files linked to a master file). The only major problem is with cutting large sections, I would have to embed all the smaller files for vaSectionview to read the cut and stacking 3-4 embedded block instances/floors already creates significant lag. Is there a better way to work on larger projects?

1 Like

It’s not possible to wrap wall layers into openings. This is a feature planned for future versions.

If you need to insert files into a Master file, make sure you use the “Linked and Embedded” option, otherwise the section attributes or the plan view representations won’t be displayed correctly.
In terms of performance, it will be similar to have all geometry saved in the Master file, or referenced from external files. What really matters is the amount of visible geometry in the current viewport, or the amount of viewports you see at the same time (it’s always better to maximize the current one).

Yes, for the next topics, please open a new Thread.

1 Like