Hey Guys,
I’ve got an issue with roof overhead lines not displaying. I’ve got the roofs setup to show as projection with overhead and when I make an entirely new building layer, it’ll sort of show up, but the layers start to flip out.
Any hints on how to fix this issue?
Thanks!
Hi Clayton,
Could you share a screenshot or file so we can better figure out what’s happening?
Keep in mind that the overhead representation only appears in plan view for the objects that are located within the level that has the cut plane activated. If the roof is beyond that level, it won’t show up the plan view representation of that level.
Ah, I see, your response has helped me find the answer.
So here’s what’s going on. Hidden overhead roof lines are programmed to only display if they are between the current floor and the floor above it. I use “levels” as a register of not just floors, but also head heights, plate heights, grade, etc.
The problem is that it only shows any roofs between the level we’re on, and the level above it, which in my case is the finished floor to the first floor typical head height. If I delete all those cuts and only leave the actual subfloor/finish floors, it all works just fine.
I suppose the real issue is that I’m using the Levels feature to act as a datum that visualarq can’t otherwise keep.
Edit: I think I remember seeing this in the planned feature list, but does VA3 have parametric elevation marks planned? That’s the actual long term solve for this question.
Hi Clayton,
In VisualARQ 3 there will be the option to add sub-levels in the level manager. They will be used to have different construction planes within a level, and they won’t affect the overhead representation of objects in a plan view. For example, if you have an object located between Level A and Level B, (being Level A the lowest), no matter how many sub-levels are in between, the object will be displayed in overhead representation on the plan view of Level A.
There is no news about it in VisualARQ 3. With the Grasshopper styles, you can already create custom elevation marks. Like this one, that maybe suits you: Level Reference Elevation mark | Food4Rhino
Sublevels would be perfect. That’s great to hear, and a clever fix.
I’ve played with that Elevation mark definition before. The workflow to manually input and place them in a 2D sectionview takes less time and is more stable than getting it to work as a dynamic object in 3D, unfortunately. I’m still doing all my elevations and sections with 2D section views because of some of these shortcomings.
Some issues with that annotation object, for example: I haven’t been able to consistently edit the text size and how it scales to layout space yet. It isn’t possible to move the position of the elevation marker if it’s overlapping something else. I can’t find a way to have the marker extend past the grade without clipping both out of the section, etc.
Using a regular block provides the flexibility to make sure the object is reading clearly by making small adjustments. The challenge with simple blocks is that I have to manually make sure all the labels and positions are correct every times something in the model moves, which is manageable.
The point where it’d be worth the effort to use a va annotation object (and develop a GH script for one) would be if the definition for the elevation had that flexibility, and also was possible to target with other VA objects as a datum in the model, (i.e. all windows snap to a specific sub level/head height etc) like I think gridlines will in act VA3.
Is there maybe a tutorial on how to create VA annotation objects that I could take a look at somewhere? That might allow me to work on some of these workflows I’m looking for. Trust me, I’d love to use the parametric tools for these functions, but I can’t do it if it compromises the legibility or stability of the drawings.
Hi Clayton,
In this case that elevation object is not going to help you so much. I can also see you are working in Imperial units, and that annotation style is designed for metric documents.
Text sizes in annotation objects are a bit tricky, and something we need to improve. That particular annotation style has a “Text Size” parameter to control the text size. However, it won’t behave as a regular Rhino text, and won’t scale in page layouts if you enable the layout space scaling.
Have you tried to run the BringToFront command with that object? that should work…
I’m not sure to understand this one.
Well, grid lines and level constraints in VisualARQ 3 will help you on that. We have also plans to support VA Objects as input parameters for Grasshopper styles, but that will be on future versions.
Here: Annotations - VisualARQ
In that example, there is no parameter to control the text size. You may add it to the definition:
Yes, and with that tutorial you sent in your message I can create an annotation object that’ll work for me in imperial units, problem solved!
Yes, definitely. It’s often unclear which setting governs text size and style across many different VA functions. It would be ideal if it was tied to an annotation style, that would give some real power to it, but you guys are the professionals, I’m sure you’ve got some sort of fix in mind already.
Of course! Why didn’t I think of that… Thanks for the reminder!
Sorry, that wasn’t a great explanation. It’s a couple things that are interrelated and not terribly obvious. Let me try that again.
Elevation markers are clearest if they stand out to the side of the drawing, clear of any object. This is difficult to achieve with a VA Annotation object, because if they are part of a “live” 3d section they will be clipped along with the 3D grade object (shown as the hatch below the building), and obscured.
Check out the below screenshot, which is a 2D section view with 2D model space annotation blocks. This is the ideal condition.
Additionally, in the case of the two elevations SFL-2 and PL-1.2, (the sub floor for the second floor and the plate height for a second, taller space in the same structure) they are so close to each other that their elevation markers would overlap, which makes that small dog leg in the datum line necessary to make sure the elevation symbol and text don’t overlap each other.
I’m not sure exactly how to accomplish that with a VA annotation object. This is not isolated to elevation markers, there are other situations where it’s handy to make adjustments to the exact location of an annotative symbol.
I think it’s possible there’s a solution through the use of VA Objects as input parameters for GH styles. That way you could separate the elevation datum from the symbol that holds information on it somehow. Similar to how an window tag can float around and display information on a window wherever you place it.
Grid lines and level constraints will be incredibly useful. VA3 sounds like a huge leap forward. Looking forward to putting it to use.
As always, thanks for your help Francesc! You guys are the best, and that’s no exaggeration.
Hi Clayton, thanks for your kind words!
Yes, theoretically, the annotation object takes the text attributes based on a Rhino “Dimension style”, but it doesn’t work properly for “Grasshopper styles”. We are studying how to fix this issue.
I understand now better the request with Elevation markers. The jogs for the marker line could be defined as parameters within the Grasshopper style, and that way, avoid that overlapping situation when they are close to each other. But of course, that would be a custom workaround. Ideally, these separations would be calculated automatically based on the size and scale of the view. Or we could provide a system annotation object for that elevation mark, with all these features. But this would take time to implement.
That explains it, I’ve had it work occasionally but not consistently.
A fully parametric GH solution would be great. I’ll say, when VA GH definitions start getting a ton of buttons, they become cumbersome. The system annotation object would maybe be more ideal, since it is adjustable based off of how the drawing looks. The solution would ideally involve the position of the elevation line be dictated by the level constraint, but the position and design of the elevation marker be adjustable.
Thanks again!
Hi Clayton! You’re drawings are looking pretty awesome!!
A while back I was working on a very similar thing to your elevation marks. I created one solution that was very ignorant to any possible movement.
In AutoCAD, I used something called ‘event driven programming’ to automatically update a ‘tag’, just like Revit (actually better than Revit because the ‘tag’ was just text and I could rotate/move each tag individually as needed).
Since I’m relatively new to both the Rhino API and C# I haven’t used any event driven programming in Rhino yet. So an interim solution was going to be a database sweep where the code/command looks at every block and tries to establish if it was in fact moved or not.
For either method to work I would have to have some sort of anchor point… which could literally just be a point. I might be able to make this work using a group (an object group) which in many cases could mimic the functionality of a Dynamic block.
For reference this is my solution in ACAD:
*Note that the ACAD block uses a field which is why I need that pink symbol (which is located at the block’s base point). I could achieve a similar effect if I use a point inside a group. A user would have to CTRL + Shift to adjust the block’s linework (but without moving the reference point).
Exactly, I’d say this is the best setup. This combined with some BIM functions.
I’ve never done any C# or work in the Rhino API, only GH work, but event driven programming sounds super handy.
I am wondering if you could set something up with Rhino’s text fields. There might be a units formatting issue though, but maybe something to look into.
I think the units formatting issue is what got me when I tried this. It would have been super easy otherwise. Edit: I should mention that my CAD solution also has a units issue when I’m using Metric mm units. For some reason, the scaling factor is disabled and I can’t show the units, in this case, as meters instead of mm.
I’ve updated a new version of the “Level Reference Elevation Marks” annotation styles and added a couple of parameters to add break points along the elevation lines:
Fantastic! That looks perfect.
I’ll be getting back into some elevations next week and I’ll take this out for a test drive. Thanks for putting this together, Francesc!
