Stair Annotation Issue and a couple more stair questions

I ran into this issue again. I think it’s on the list already? Or it might have been fixed and came back with the latest update?
The Tread numbers are way out of scale verses the plan title:

Model Space Scaling is checked as you can see:

image

And:

image

We can do something with the annotation style(s):

image

But…

image

Anyways… This helps me lead into my next question:

I’m thinking about building my own VARQ stair style in Grasshopper. I currently have a non-VARQ GH definition I used for monolithic concrete stairs (no slabs for treads and risers):

I think I can get the geometry I want from these into a VARQ style, but I’m worried about how it will be treated in my vaPlanViews. That is to say, Can I either include custom linework in the definition? Or just turn it off completely? I had a look at all the stair components. I just don’t want to build the definition only to realize it won’t work for me (creating the stairs manually, or ‘automatically’ with my clunky definition isn’t that bad, but a VA definition would be just a bit better).

I realize that this might be more of a VA3 question.

Hi @keithscadservices,

I tried to reproduce it but I couldn’t. Please could you send me your file?

What do you mean by “custom linework”? What do you want get in the plan view?

The file I’ve attached contains a collection of the various issues. This issue was previously brought up.

There are many different potential approaches we can take, but due to all the little quirks, a flaw or bug always pops up. I’ve been full-circle trying to figure these little things out. I usually just forgo using certain features… but I don’t think that was ever the intent.
I think priority with VA3 would be to get more consistent behavior out of all existing features.

Possible work-arounds are to not use model space scaling. One work-around was to just create a style for every plan view/section object for each scale you intend to use. But that proved to be a TON of work and really cluttered up the drawing.

As it stands I think a lot of users are actually spending time turning features off (turning the riser numbering off for example). Many things do work great but there seems to be wrenches thrown in the gears here and there. Figuring out what to use and what to avoid seems to be key… but I don’t think that’s ideal.

Annotations that work better with native Rhino features would be a very welcome addition!

I’ve played around with Grasshopper a little more since I first posted. I’ve seen what’s available for stairs, and deconstructing the stairs, but it’s somewhat limiting.
What I mean is that if a user could create their own stair style via grasshopper, and with that custom definition also dictate how the linework for that stair shows up on a vaPlanView (it might be possible but I don’t have the time).
An approach I was trying was to try and extract the linework from the stair and edit it. I was hoping I could get to it via the “Deconstruct Stair” but that doesn’t give me much output. I also don’t think I can explode the stairs? For a straight stair section I could use the stair options to figure out the linework quite easily but for stairs with bends… good luck. If I even had access to the stairs solid geometry I could get the linework from that.

Edit: Uploaded updated file
VARQ Plan Demo (2).3dm (4.3 MB)

And while I’m here I’ll go over some of the issues (two of the issues were brought up by other users).

First, straight out of the box behavior:

The stair tread number’s text is slightly larger than my current annotation style.

Setting the Dimension Style/Annotation Style (I think the term “Dimension Style” is either from RhinoCommon and/or legacy?) creates all sorts of issues. I think this needs to be fixed for VA3 for ALL objects:

Another user pointed out this issue. I re-created it by rotating the vaPlanView but it will also do the same thing if the CPlane is rotated as well:
image

When I take a plan view of Level 2 I’m given this:

It looks more like the stairs are actually located on level 2

I guess the take home here is that if it doesn’t work, at least give us the ability to make it work. Maybe via grasshopper?

Hi @keithscadservices,

If you need is to create the 2D representation of that stair, you can do it with Grasshopper. You just need to generate the geometry as one more style component and then define it as 2D while you are creating the style:

You can do it using the VisualARQ explode component:

image

Anyway, please, take into account VisualARQ will automatically calculare the 2D representation for you if you don’t provide one.

The numbers on a stair uses a fixed text size of 12 cm / 5 inches (depending if the document is metric or imperial). This is by design until we allow changing the text style of elements decorations. I will let you know when this is possible.

I have reported all the issues to find a solution. I will keep you updated about it.

1 Like

Thanks! I’d never saw that!

I can get to the Breps, which for my purposes will be good enough. I have no idea how to use the other input and output however. I don’t necessary need it but it might be a shortcut for what I eventually want to do.

image

Hi @keithscadservices,

You can use the “Components” input to obtain only the style components you need, for example, a window frame:

The “Recursive” input can be set to True to completely explode de object in case it is composed of nested blocks.

As for the outputs, you have all these outputs because objects can be made of Breps, but also of meshes, curves…

1 Like

Hi @keithscadservices this is to inform you we fixed some of the issues you reported in this Topic an in the 3dm you provided about the way stair step numbers are generated in 2D plan views.
That’s available since the 3.2 RC1 version. But there is a newer RC: VisualARQ 3 - Version 3.2 RC3 released