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.
