Have you ever needed to add dimensions, leaders, or text entities to your model to clarify an issue or enhance your documentation workflow? Moreover, have you ever needed greater control over the hatches you use in your models and/or drawings to really make them pop?
Grasshopper 1 – in the Rhino 8 WIP – now has many new components which let you control annotations and hatches with ease.
With the inclusion of so many new components, it is difficult to describe each one individually. Instead, I felt it would be best to include some annotated examples which show how these new features work.
Feel free to download these examples and give them a try. As usual, please post questions or comments if you need further clarification.
Once you get the hang of how these components work; you too will be able to create dynamic, eye-popping, and fully annotated models like this one. Try them out today!
Another thing that could improve AEC workflows in GH could be some components for custom table creation. It would make creating schedule tables via GH much easier, without the need to use 3rd parties or additional scripting, that is not so trivial
Andy, can you post the GH def for the video? I am having a challenging time with the Center Mark Component, since in Rhino we have three posibilites, 1) None, 2) Mark and 3) Mark and Lines…
@RhinoFabStudio Unfortunately, no. It’s rather big and would likely just be confusing for people. Instead, let’s look at the problem you’re trying to solve. So, it sounds like you want to have control over the Centermark Type. This is handled in the Annotation Style that you use for your annotation to control how it looks… More specifically, these settings are stored in the Annotation Dimension Settings component.
This component has input parameters which let you specify the size and type of centermark that you want to use. But, now that you’ve set the Dimension Style Settings, you now have to somehow assign those to the Centermark that you make with the Centermark component. So, you have two options:
Per instance overrides. With this method, you are basically assigning some settings to the annotation object itself. Any settings you applied here will override any style settings that you might apply globally using the Assign Style component. However, for simplicity sake, we decided it would be best to sorta hide these settings by default. All annotation components have additional input/output parameters which can be unhidden to be able set the per instance style settings for that object. To get these to show up, right-click on the Centermark component and select “Show All Parameters”. You should see an additional Dimension Settings input parameter show up. If you connect the Dimension Settings component shown above to this input, you will then apply these settings to that annotation instance.
Set the Annotation Style globally. You can assign any valid Annotation Style to any annotation object (ie. linear dimension, leader, centermark, etc.) by using the Assign Annotation Style component. This component accepts any annotation object and any annotation style. Remember, that if you set the style on an individual instance, those settings will override the style set using the Assign Annotation Style component.
PS. A little tip. That component on the left of the image above is the Dimension Settings component. It takes up quite a bit of screen real estate just to access two input parameters. A nice trick on these components is to right-click on the middle of them and select “Hide unconnected parameters”. This will make the component much smaller and only show you the parameters that you are currently using.
Is there any reason to stop most of these components not ending up in a Rhino 7 GH service release?
The main reason for asking is that we are implementing similar functionality into plugins, which then results in lots of duplication/compatibility issues for the user when it comes time to update from R7 to R8 in future.
Slightly unrelated to annotation, but another “core” type missing from GH is PointClouds - which results in a large amount of plugins re-implementing the same base functionality. Just saw Rhino 8 Feature: GH1 Is Now More Than Just Geometry! - #92 by AndyPayne - point cloud support is great too.
Thanks @jnavarro1 for bringing this to our attention. We had made some changes to the Hatch and Annotation components which is why the existing definitions weren’t working properly. I’ve fixed the example files and replaced them in the original link. I did find a bug in the Query Model Annotation Styles component which I have fixed… but that means the fix won’t be available until the next WIP goes out (next Tuesday 3/7/2023). So, I’ll update the conference room example when that fix gets released publicly. Still, I believe the example you posted an image of should now be fixed. Let us know if you have any questions. Cheers.
Thank you, @AndyPayne, great to see hatches being progressed. Will there be any documentation/tutorials on using the components, particularly Hatch Line and Model Hatch Pattern?
This is great @AndyPayne, thanks for pushing this forward!
Question - I’m interested in using some of these features in a resthopper/rhino.compute environment. Is it possible, or does it rely on a GUI-based document to be present?
For instance, let’s say I would like to generate some hatches, linear dimensions and leaders in a grasshopper definition that runs on compute. I would like to have these objects to be part of the compute output (not through Hops though). What would be the best approach to get this to work? Is it possible to “explode” thsese objects into curve/mesh geometry?
I don’t know the answer to the compute question but there is a GH component in R8 called “Explode” that allows recursive explosion of model objects, elements, blocks etc. down to its base geometry.
It even works with text entities if I recall correctly.
Right now, many of the new data types that were added to GH 1 for Rhino 8 aren’t supported yet on Rhino.Compute. It is on our roadmap so we will be working towards getting these working as soon as possible.
Ok, thanks for the info! Can you please elaborate a bit more @AndyPayne? Do you mean that they are not supported in Hops? If so, that’s totally fine. I’m primarily interested in extracting the geometry from these objects (like hatches or linear dimensions) and convert them to other formats (such as gltf/glb). Is there a method on these objects in RhinoCommon that would allow me to do that?
That seems to be a different thing than what Andy is working on. For generating things like gltf files on the fly in a headless environment, we now have an SDK in RhinoCommon to control this.
To do that I would need to extract the geometric information from the annotation object. My question is: is there functionality available in RhinoCommon to do this? Or does it rely on an active Rhino doc?
Perhaps I should do some experiments in R8 and return with some concrete questions. My gut feeling is that it’s doable using the explode component @michaelvollrath suggested
