This thread is to open up wider discussion on potential workflows, questions & concerns with the Rhino tab components.
As different topics and workflows are presented I’ll try to keep it coherent by breaking out threads into individual topics.
To keep the forum cleaner I’m going to prefix any definition I post with Rhino 8 specific components a RH8-* for clarity. This isn’t rule, just be considerate of Rhino 7 and below users when posting, similar to how its polite to note any additional Plug-ins required in opening a definition.
Or… Maybe I’m misunderstanding the issue. If you leave the name “blank” then it will return all of the available annotation styles in the document. From there you could use a List Item to retrieve a specific style that you want to use. Does that help?
I’ve been testing the new Rhino tab and couple of things come to mind:
One of the key things I would like to see happening is getting for example DWG-references working in a lightweight manner. At the moment, if I Insert DWG files to Rhino, they might have 300 different layers and will mess up my Rhino layering completely. As a workaround, I was wondering if the new Import Model and Import Content components will help and they seem to work just fine. For a larger DWG it might still take 10-20 seconds to import and the Grasshopper preview’s are really slow possible due to lots of nested blocks in the DWG files. Nevertheless, using these components I can for example get all the curves and texts from the DWG’s imported without messing up my Rhino layers so all good.
However, if I would like to Bake the necessary geometry to certain Rhino layers, I did not find any way to do this. My question is, is there a feature for this already implemented or not? If not, I strongly ask for that to be considered.
For example, I could create a layer in Rhino called “Imported DWG” and then would like to Bake the necessary geometry to it or its sublayers with a click of Button.
Thanks for your feedback, Joseph.
We turned on new features in the WIP and Beta phases to make sure that new features were actually being tested. So far, while you are welcome to disagree, we see more positive feedback than negative feedback concerning this feature.
This is generally true of several settings and something that we will continue looking into making more obvious.
I was totally baffled by having the Cplane tilt when I touched my baked geometry (a curved surface).
I strongly disagree that making average users feel completely helpless is good for anyone. Sure, I can see the value of the feature and would appreciate it if it were presented as part of a solution instead of an obstacle. But forcing people to use features (with a serious downside) they don’t need or want, just to show off, is a recipe for frustration and distrust.
I was blindsided by the auto cplane feature. I thought something is broken, had to search the forum and only then found out about it. of course I immediatley turned it off. having it enabled by default was definately the wrong choice imo.
It’s great to see these additional types make it in to GH, along with point clouds.
Taking “Text Entity” as a base for these comments:
I find the reference inputs to the components some what restrictive; such as a “Text Entity” component taking in a text entity as an input. I can understand how this is a simple way to assign the many parameters of styles and I can see how it could be useful in some (documentation) workflows, but it also means that the GH definition becomes dependent on the Rhino definition. In turn, this makes it more difficult to share the definition, and also means some fields (i.e. size in this case) can not be parametrically assigned.
As such, I would love to see components for “Construct Text Entity” and equivalent that do not have a Rhino document dependency - even if it means exposing a ton of parameters. One of our plugins does this in a simple way and it works well.
That said, having a GH_TextEntity type will make it much easier for third parties to add these components.
Alternatively, just adding some additional inputs to the components could help a lot - so that the most important ones can be parametrically overridden. Mostly this just refers to a text size override for text entities and dimensions!
Unless I am misunderstanding you, I believe what you are asking for is already possible and you don’t need Rhino Doc dependencies.
If you Shift+Double Click on the component or Right Click → Show All Parameters you will see a Text Settings input show up. Here you can connect an Annotation Text Settings component that allows you to set text size, orientation, mask style, margins, etc.
I’ve been using the annotation components to set all of my text, annotations, dimensions, etc. from within GH without any Rhino dependencies just fine in R8 with these new components.