Issue 1: I cannot perform solid subraction (needed for the last step of the stair).
Please check the two .gif files for the offending stairs. One of the two stairs has already substracted solid from an earlier time-point. It seems like from a time-point in the file stair solid substraction is not possible.
Issue2: Also I am not able to install VisualarqLabs (R8).
Issue3: If anybody can spend some short time explaining this: how can we control the documentation for the stairs as in the screenshots? Styling the arrows, numbering orientation, solid dot etc. Have we got such control via VA or not? I’ve never worked with this so far.
Can you provide more details? how are you doing it? You should just need to:
Extract the files from the zip file.
Drag and drop the .yak file into the Rhino interface.
If problem persists, go to Rhino Options > plugins > (plugins that do not ship with Rhino), and search for the VisualARQ Labs. Then do right click and select “Load plug-in”. Then restart Rhino.
There’s very little control of the stair symbology right now. You can just turn on or off the stair arrow or the step numbers (in the stair styles dialog), but you can’t change the arrow style, or the “break” symbology between two stairs in different levels. In the case of the text in the step numbers, it takes the parameters of the current Rhino Annotation style, and the size adapts to that annotation Model Space Scale. It can’t be overwritten to a different text size. I hope we can improve this in VisualARQ 4 version.
Indeed you picked a group of solids. I am not talkin about this obv. Please hide this and you will see that i have a stair too - in which i cannot perform the operation. You can test it in the straight (the other stair i showcased) stair too.
I showcased in the gifs two stairs that I cannot perform the va subtract solids.
Ah, ok. I didn’t notice the involved stairs were in hidden layers.
If you make the solid of subtraction slightly bigger than the stair step, the subtraction should work.
ok Fransesc. There are times, when exact size substraction geometry does the trick. It’s a bit unpredictable when it’s going to work in exact size and when slightly bigger size substraction going to work but not the exact size one.
Why is this happening? Is it about internal tolerance of the substraction mechanism?
There was quite some time that I was performing substractions with exact size and it was working 90%, and made me think that it became a stable solid substraction mechanism.
I’d prefer it personally to have a stable mechanism-logic, because otherwise we’ll have to go with trial and error and/or oversizing-overcomplexing substraction solids, making it slightly more difficult through .gh scripts (manipulating the calculated substraction solids, in xyz in a dump logic without reason).
It works for now, but if you think it’s doable in terms development, please note this down for future improvements if possible.
Hi Gabriel,
Behind the command to subtract or add solids to VisualARQ objects there are Rhino boolean operations going on. There are some cases where these operations are not predictable if each object has an overlapping face. It might be a problem of tolerances or boolean calculations. In any case, I recommend you to make the solid of subtraction bigger than object to subtract it from and ensure a better success.
Hi, Francesc,
I think this particular case may actually expose a more fundamental limitation of the Stair object, related to the same lack of control I mentioned in my U-shaped stair topic.
The flight should have an end condition that lets us control whether or not it ends with the last step, depending on how it connects to the landing/slab. Solid subtraction would be useful in general, of course, but it shouldn’t be necessary to obtain a correct stair connection.
This is the control I mean: both flight end conditions should be possible. The second option increases the flight length by one tread, which may not be acceptable in constrained spaces.
Hi @badileanu I add your vote for this request, which has been in our wish-list for a while. Using a boolean subtraction is the best workaround so far. We even created a command for that in the VisualARQ LABS: Labs - VisualARQ
Just something that might help for the type 1 (in the case you are not aware), is the Top and Bottom Slab Thickness parameters, in the stair object Properties dialog:
Thanks @fsalla. Yes, I’m aware that there are workarounds — boolean subtraction, or even replacing/customizing parts with a VA Element.
My point is that I don’t think this should require a workaround. The start/end condition is a fundamental property of a stair flight, so ideally it should be handled parametrically by the Stair object itself.
