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.
Thanks for sharing Japhy! I was just about to create some grid line bubble logic creation myself. This timing is lovely!
I hope this thread does in fact become a sandbox/playground as there really are some awesome things becoming possible with R8 and I’m excited to see what other users have been coming up with.
I’ll be sure to share some of my explorations as I come across one that’s interesting.
You could use the Value List to feed the name of the annotation style into the “Name” input of the Query Annotation Styles component and it would return only that style for you.
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 think he is wanting a value list to auto-populate with the possible annotation styles in the document when it gets connected to the component Name input.
These are invaluable as well & would solve the issue (+Query Annotation Style then the picker). Something similar to the Item Selector (human) or Value Picker (Rhino.Inside.Revit)
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.
And a new build is available that bakes my trimmed (holed) surface. Do I get a prize for reporting a “blocker bug”? Or was that one too obvious?
The ‘Auto Cplane’ problem returned with the new build but this time I know what to do about it. It really is a mistake to have that feature enabled by default, for two reasons:
When running Grasshopper, it is customary to allocate half the screen to Rhino and the other half to GH. When that is done, the ‘Auto Cplane’ toggle at the bottom is invisible, off the screen.
There is no obvious indication that mode is active, giving some clue about what is happening and where to look to turn it off.
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.
-wim
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.
Hi @Japhy
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.
A fun one. Here we are creating blocks in grasshopper and export to a file location. The .ghdata file is created with a list of the block file locations to import into a different instance of Rhino.
- thanks for the explanation 
