[BUG] Stairs element remains “flight” on the list even after changing it’s type to landing.
[WISH] Ability to draw stairs with different flight and landing widths.
It is very rarely that we design stairs that has the same landing and flight widths in our country. This results from law requirements that are different for both. Inability to do it so equals great inconvenience for us. This feature could be possibly controlled by style (two separate width parameters) or by stair elements (as shown on picture below). Of course, the best would be to have both possibilities
[BUG] Objects with custom 2d representation are not displayed properly when covered with another objects. This could be solved for example by assigning the custom 2d representation to objects only when the cutting plan is intersecting the bounding box. It has it’s disadvantages but may be the option.
[BUG] there is a problem with plan and section representation of nested objects, like for example furniture containing another furniture with it’s custom 2d representation. 2d elements are flying all around the drawing.
[BUG] There was some problem with section representation of objects containing curves crossing the section line. Entire section drawing goes crazy.
[WISH] Maybe I missed this feature, but i suppose there is no control or any possibility to separate cutting lines over projected lines in plan and section views. Could be great to have some control over the cutting line width in the plan and section styles and have them for example on separate layer(s) when exploding the view.
[WISH] We have an option to subtract solids from walls and we have the possibility to “make holes” in them when creating openings, windows, doors etc. So when creating custom window styles we define the opening by the profile curve that “makes hole” in the wall - and that opening doesn’t allow creating glyphs, reveals etc. What about giving us an ability to cut the opening with solid instead of (or together with) curve profile with specified cutting depth? It’s form in GH definition seems obvious, but it could be also done in non-GH objects - solid, whose location would be defined inside Rhino block and be relative to insertion point of VA object. To say more - this feature could be also an option for other VA objects, like railings (examples below).
[BUG] Holding shift, pressing tab and multiple selection (by rectangle) doesn’t work when operating on VA objects control points. Selection issue is not working at least on stairs.
[BUG] My VA objects are sometimes being automatically exploded when exported / copied to another document. I don’t know what causes it because I realise it after some time working on the file when I no longer remember what specifically I did before.
[BUG / WISH] Elevation marks are always in horizontal plane. I can not rotate them so they be visible in section views and elevations. Unless there is some way to make this type of elevation mark by ourselves (so it could update automatically based on insertion point’s elevation) it would be great to have it work or have another elevation mark that could work also in vertical plane.
[WISH] Grasshopper is widely used for creating parametric architectural structures that are based on surfaces or polysurfaces. It would be great to be able to have them in BIM in similar way that we have curtain walls - in single parametric objects containing multiple panels, support elements etc. and would be great to have them form surface / polysurface input.
Hi @Tomek_Wloga, Thanks for this detailed and useful wish/bug list report.
I can’t reproduce this behaviour. Remember to click on the “Apply” button or the Ok button to validate the changes. If problem persists, please send me that model to visualarq@asuni.com. If you just mean the text of the flight “stair flight”, this is just an initial given name that you can change manually, if you also change the flight type.
That’s in our wish list. So I hope we can work on it soon. As a workaround you can create a stair a wider width and then use the vaSubtractSolids command to trim out some parts of the stair.
That’s how it works now. An depending on the object Plan visibility settings (in the Properties panel > Display) you can decide when the 2D representation should appear according to the object location regarding the cutting plane inside the level where it is inserted.
Please send me the .3dm of this case to visualarq@asuni.com and we will check it out.
You can control the cutting line width of objects from each Component attributes tab, in the corresponding object styles dialog.
That’s in the wish list: the option to assign a solid as a cutting volume for doors and windows.
Multiple selection of control points only work for the “stretching” control points, but not for the extension arrows. Multiple selection of vertical extension is technically difficult to implement, since we should avoid situations such as selecting a vertical control arrow and a stretch control point at the same time, which do different things. We will study it
That might happen if the Rhino where you export / paste these objects doesn’t have VisualARQ installed. Then the objects are read as block instances.
Yes, annotations can only be inserted in World XY plane. We need to do some changes to allow inserting them in other planes.
In VisualARQ 2 you can create roofs from Grasshopper definitions for these kind of structures. Roofs can be created from surfaces so you could you select a surface as input information.
3 - That’s how it works now. An depending on the object Plan visibility settings (in the Properties panel > Display) you can decide when the 2D representation should appear according to the object location regarding the cutting plane inside the level where it is inserted.
I still have problems with displaying objects above the cutting plane. Fe. beams, windows etc. Even though the object has the “above cut plane” option assigned. Do you have the same behavior?
I meant that the icon should, as I would expect, follow the settings, so it quickly informs which segments are actually flights and which are landings.
this solves the 3d but destroys 2d representation, so at the moment we probably must draw flights and landings as a separate objects, using slab tool.
that is great feature, so it gives us controll over section-lightweights of different objects, materials etc. But it has some limitations, which force me to do post-edit of every plan and section drawing, so I can’t benefit from their generative nature. The first point is that it allows us to achieve result like that:
while the one that we usually need is this:
So the wish would be to have not only the control over each object’s linewidth but also over overall form section’s linewidth. Something similar to CreateOutline command in Rhino. And that obviously could not be controlled from the object’s level.
The second point is that if you would like to change the width of section lines that appear on different 2d sections and plans, or just change it globally, it is impossible without having the control form the level of plan / section (style) properties.
I also found some kind of problem with stairs control points. I think that non all of them work correctly. It seems like only even points actually reacts when I move them.
I understand the confusion. Originally, in VisualARQ, stairs were created by flight and landings. A flight was a straight segment with steps, and a landing was the union of two flights. Then we added the option to have flights without steps and landings with steps, which as you can see, make parts names confusing. We should change the “flight” name to “segment” and “landing” name to “union” or “corner”, for example. What names do you propose? We should also change the icon, or make the icon dependent on the component settings.
But, we have plans to rewrite the stair object from zero, and allow stairs to be created from a path curve, supporting polyline, arcs and NURB curves, split segments, etc, so I don’t expect many improvement on the current implementation.
Well, then this is a bug. 2D representation should be aware of added and subtracted geometry.
I see your point. We should study ways to implement that. Do you have a sample model with an object, with a 2D block, covered by another object?
This is definitively a bug. Can you please send me this model?
I believe I found a bug. I already had this problem a couple of times, but never to this extent nor so graphically interesting.
Essentially the beam elements gets stretched to infinite boundaries.
I assume it is not supposed to happen.
For the moment I noticed it just with the beam elements, especially when they are joined at an angle and grouped:
@XDGA Can you send the mode to visualarq@asuni.com? We will take a look at the file and fix that. It looks like a beam join problem. Meanwhile make sure the two end points of these beams are not placed in the same position in order to avoid the join.
Hi @XDGA, got the file! I can see only one beam being extended wrongly. If you select all beams in the model (vaSelBeam) and update them (vaUpdate), the problem disappears.
No, the geometry is only update when the file is opened with a newer version of VisualARQ which may have changed how objects are represented. Updating geometry could take some times, several minutes in very large models, so updating all objects each time the file is opened is not possible.
What you’re experimenting is a bug. Maybe it is a bug in the model when it was saved. I’ll try to reproduce it again. What I can try is to detect if there are “wrong” beams when the model is opened, and update them automatically.
Request.
The new roof from surface command is quite wonderful. It would be even more excellent if the Edge Cut Types would work too. Seems like only ‘Square’ works.
@bcolaprete That’s technically difficult to implement and might not work on all cases. For example, imagine a roof created from a surface in a shape of a dome. The “square” and “flat” Edge Cut Type would look the same and it wouldn’t be possible to define a Plumb cut in that case.
We might allow that option in roofs created from “flat” surfaces, if that’s what you have in mind.
