Is there any specific reason why VaElement, VaAnnotation or at least VaTag cannot be used on Layouts?
I’ve developed several Grasshopper styles for complex linetypes (such as zig-zag patterns) that aren’t supported by native Rhino linetypes. My goal is to convert these Grasshopper scripts into VisualARQ GH styles to allow for easier fine-tuning later. However, none of the VaCategories seem to work on Layouts, and I’m also unable to run my GH scripts directly in Layout space.
Currently, I have to run the script in model space, bake the resulting polylines, and then use the ChangeSpace command to move them into Layouts. It would be much more efficient if VaElement, VaAnnotation, VaTag (or another Va category dedicated just to 2D symbols and geometry) could support this use case directly within Layouts.
Thanks a lot - any suggestions would be appreciated!
I think that your question is a part of a bigger subject of Rhino/VA workflow; in which space annotation should be made? Layout or Model?
Making annotations on Model space: it messes up the model. 3d elements are placed on the same workspace as 2d elements, and you have to be very organised to keep them clean and neat.
Making annotations on Layout space: in my opinion, it is bad because your annotations won’t appear in DWG model space after exporting to DWG. It is common practice to put dimensions/annotations in DWG model space, not on the layout. Rhino Layout should only be used to arrange views on the sheet.
Solution? To separate annotating from modeling and from layout as well. I would suggest creating an additional “VA annotation space” or “VA viewport” dedicated only to 2d elements/tags/dimensions/hatches, etc.
3d modeling > 2d annotating > layout composition
Something like “Vectorworks Viewport Annotations” or “Revit Views”.
Hi @MichalKrizo we can consider the option to insert Tags and Annotation objects directly in page layouts. They are actually features in the wish list that were asked before. We can also consider that option for Elements, but perhaps only those created from 2D geometry.
(You can actually create 3D objects in the Layout space, but I’m not sure if it makes much sense, since they can be displayed only in 2D).
Hi @user1499 , thanks for your interesting contribution to this discussion.
Would you still prefer a “VA Annotation space” if you could tag objects and add annotations in the Rhino Layout space?
I guess you are talking about the vaExportToDWG command here, right? The option to export everything that lays in the page layout + the geometry inside the Detail views to the DWG model space is something that we are considering, as an option, for future versions, assuming you would lose the scale of the 2d drawings in the model scale. In this post there are more details about this discussion.
Do you think an “VA Annotation space” would change that? I mean, that people would not annotate in the model space anymore, and would do it in that space instead?, in a similar way as they can already do it now on page layouts (with the mentioned limitations)?
yes, yes and yes - a implementation of these points and thus creating “new” workflows would be awesome, it’s all about giving options and those would help working on 2d documentation a lot.
I think that this would be a good direction for further VA development; to create one “VA Annotation space” where we would use all 2d tools like elevation marks, rooms, tags, etc, as well as dimensions. It is hard to say where this annotation space should be; on the model side, layout, or pop-up in between - it requires further investigation of other BIM programs/solutions.
Crucial is consistency - all 2d tools should be in one place.
Exactly.
Are you familiar with how Archicad (or similarly, Revit) works? No offense, but you sometimes sound like you never really looked into those apps.
If not, check out some tutorials on Youtube, like maybe this one (It’s enough to quickly scrub though it).
There you can work either in 3D (1) or in a pure 2D floorplan/section view (2), it doesn’t matter. Create/move some part in a 2D view, and it moves in 3D, and the other way around. So, 2D views are a ‘live’ derivative of the 3D view, like section tools in Rhino or your vaPlan/SectionView, but synchronized to 3D.
Those 2D views store a scale parameter, plus loads of other things like layer states, level of detail, graphical overrides, constructon phase, etc. - everything that defines the final look and ‘level of information’ of the 2D drawing, including annotations!
The last step is then to put these 2D views into a Layout (3), do some border clipping and add some title blocks or text, and output the whole thing to PDF or DWG(!!). There’s also a mechanism to output a collection of layouts in one go (Rhino 8 has something similar now in the print dialog).
Annotations cannot be added in 3D views in Archicad, neither can imported 2D plans (DWGs etc.), for good or bad. Annotation makes only sense in these dedicated 2D views, where they also will remain associative to the parts you annotate. Text/annotation styles are defined in mm, and their size will automatically update should the scale parameter of the 2D view change.
Now compare this to the complications that Rhino lets you run into regarding drafting.
What can be done? Is it technically even possible for plugin-developers to add a separate 2D space like the one discussed? I have a feeling that this runs very deep into Rhino’s intestines, and would require some serious effort from McNeel. Not to mention the many users who are used to the status quo workflow and who might have a strong opinion against such a change.
But yes, should such a workflow exist - it would indeed be helpful for any industry, not just architecture.
Should this be unrealistic - are there any other ways in Rhino to simplify the 3D->2D->print workflow? I can only think of ‘live’ vaPlan/SectionViews (blocks) that can be put into layout space, and that somehow can be annotated associatively.
I’m well aware you want Detail views to function as such, but this leads to the known contradiction: packing annotations on top of Details in layout space just isn’t reliable enough, and annotating in model space clutters the scene.
Don’t worry! I’m not an ArchiCAD or a Revit user, but I have a fair idea how these programs handle that. Sometimes I just try to ask questions in the most naïve way possible to get the most information from users.
The point here is to achieve a similar workflow in the Rhino environment, but adapting as much as possible to the flexibility that Rhino gives you to to draw or annotate anything where and how you want (as you said, for good or for bad).
I’m a bit skeptical about implementing a solution that involves a new workspace, for several reasons:
Adding a new workspace would introduce an additional learning curve when documenting a project compared to the existing tools (model/layout space).
I find it challenging to “educate” users who have always used layout or model space to document a project to switch to this new workspace.
Even though it wouldn’t be exactly the same, this new workspace would be very similar to Rhino’s layout space, and we don’t want to duplicate existing functionality.
We are discussing this internally, and one possible solution/improvement could be to use the layout space to handle this workspace, but with some additional features:
We could implement the Level of Detail, attribute overrides, reference texts linked to view names, etc… in the Detail objects. Some other features are already available (layer states, scale…)
The annotation objects (dimensions, tags, texs, etc) could get their visibility linked to a specific Detail viewport. This way, you could either insert them in the page layout or in the model space. But in the page layout those annotation objects would be just visible in the indicated Details.
We would need to revise, with the help of McNeel, all these issues, of course.
I like the fact that Rhino has the flexibility to freely mix 2D and 3D, very much. That’s where Archicad and the likes actually suck.
But on the other hand, there should be a simple way to keep 2D and 3D separate, if needed - which is the topic here.
Actually, I concur. There has to be a clever way, a Rhino way.
Yes, absolutely.
Something I proposed some time ago is to expose Snapshots as a Detail parameter. They include pretty much everything that makes up the ‘look’ of a viewport.
Snapshots exist for a long time already, but they should be able to auto-update! Meaning: change a snapshot, and all details that use it change with it. (Same goes for layer states, which are part of snapshots).
Some UI thoughts: there should be some fold/unfold arrow next to the snapshop parameter, since there’s a lot inside. Also, there needs to be some ‘Save changes’ and ‘Revert’ functionality, should the user change things in the detail view.
Snapshots should then also include your new ‘Level States’!
(Btw., is there a reason why there are no ‘Section States’?)
With all this in place, a new detail view could be set up very quickly by simply choosing it’s snapshot.
Interesting idea. You mean, if I enter a Detail view, create some annotations there, they will only be visible in this Detail?
Ok, how then could an object in model space be ‘marked’ that it belongs to a certain Detail? Must be some ‘Detail’ parameter, right?
It would look quite similar to the existing parameter that tells clipping planes which view they affect:
(Btw. I would include any object, not just 2D stuff.)
Of course, if you create something inside a detail, this parameter could be set automatically, because the detail is obvious, but should the user prefer to create the object in model space (not in a detail), it would be necessary to set it by hand.
That ‘visible in detail’ parameter would complement layers. It could be emulated by using layers, but the poor things are overfreighted with use cases anyway, so the idea is to NOT use them in this case.
I quickly tried dimensions on top of a detail again, and actually, it seems that the associativity has improved - on regular geometry. They stick, even when switching the camera in the Detail from ortho to perspective!
So far so good, but a big remaining problem is: associativity does not work with blocks, and thus not with VA objects.
And of course, as a reminder: we need a better 3D->2D engine! One that includes everything, including object colors as hatches, even materials as textures, not just clipping colors. Sketchup can do this.
Export a layout to DWG or PDF, and details auto-convert their content to 2D. That’s how it should be.
hey @fsalla, I am very glad that you revie this topic - maybe there are better workflows than archicad and even some that could be achieved in rhino, with minor tweaks.
but right now, at least for me, the documentation part of rhino as well as getting the documentation out of the program (dwg, pdf) and having more and better control to use rhino as a light graphic editor (to get all the work done in ONE program) is the biggest shortcoming of the program.
every work that leans toward solving or improving these points, I am very very fond of and I guess could catch new people that don’t use rhino their main software.
Hi Francesc,
Think about it this way: for architects, 2D documentation is a product we are paid for. The design is better or worse, handing over an IFC model to the client is a novelty and only a form of support for cost estimation and construction.
In the contract we have specified packages of drawings and details to do; in the right scale, dimensioned and properly described.
So if we are paid to do the documentation, we will gladly pay for the best program that makes it the easiest for us.
That sounds a good idea! But I believe this is something McNeel should implement. We will study what can we do from our side, or if we can integrate the VisualARQ stuff (i.e Level states) in there.
The section manager is quite simple in terms of section configuration. Just enables one section or another (it is not possible to activate multiple sections at the same time). So it doesn’t make much sense to save section states, and the truth is that nobody asked for it before.
Correct! The annotations that you insert inside the detail view, would get linked to that detail, and also those created on top of it, in the layout space. Also, if you work directly in the model space, you could tell an object to be linked to one detail or another, from a list of layouts.
Exactly! that’s the first idea we are considering to handle that.
This could lead to some problems. We would start with 2D/annotation objects and later on consider if it is feasible also with 3D objects. The Layer visibility per detail view can always handle that for 3D geometry in any case.
We are very concerned about this issue, which we aim to make it work for VisualARQ objects in VisualARQ 4.
I forgot that only one section can be active at any time. So, never mind.
However, should snapshots ever happen to be exposed as a detail parameter, the active vaSection should not just be part of it.
The idea, again, is to make all of a detail’s settings transferrable to other details, as simply as possible, and auto-updateable.
True, of course, but there’s the danger that drafting gets even more cryptic. 2D object can be assigned to details by this new parameter, but 3D not… Where is decided which object is 2D and 3D? Think of VA custom grasshopper driven objects.
Also, what if 3D and 2D objects are selected together? Will this detail assignment parameter be displayed in the properties panel or not?
In fact, would all object (2D and 3D) show such a parameter, it would just reflect what is already there - the object’s per-viewport-visibility, including model space and detail space. So actually, it would only be a UI exposure of something existing. A logical extension, I would say.
Annotation associativity works for normal Rhino blocks. Hope there’s not missing too much to make it work for VA blocks, too.
VA Annotations are meant to be used for 2D geometry only, while VA Elements are more generic, and can be used either for 3D or 2D parametric objects.
It’s still soon to determine whether 3D objects will be able to get that per Detail visibility attribute or not, so we will see how this evolves. In the case they can’t, assigning that “Detail visibility” attribute to a a selection of 2D and 3D objects would only affect the 2D objects.
Best would be a solution from the McNeel side, otherwise the whole visibility topic gets even more cryptic than it already is.
Hide/show per layer or per object, HideInDetail, ShowSelectedInDetail, Layer On in this Detail only - All Layouts… makes your head swim.
I think the whole visibility topic needs a rework with simplicity in mind.
Anyway, an interesting problem will be: how and where does the user define if the next created object will be visible in this detail only, or in all?
My best idea so far: a new (floating/docked) panel for object visibility that displays this ‘view tree’.
If something is selected, it shows the visibility status of these objects, of course.
If nothing is selected, setting the checkboxes will define what will happen with the next created objects - for example checking only the active detail, the objects will be visible only there.
I’m not an ArchiCAD or a Revit user, but I have a fair idea how these programs handle that. Sometimes I just try to ask questions in the most naïve way possible to get the most information from users.
