I’m using Dimension components in Grasshopper, and baking them into Rhino.
I understand that the Rhino dimensions will look a bit different from the preview from Grasshopper.
However, sometimes when I bake dimensions, the dimension moves to a different location (?!).
For example, when I bake the dimensions of one of the lines, it stays on the line.
However, when baking the dimensions of the other line, it falls away from the line, into the XY-plane.
Am I doing something wrong?
(Screenshot, Rhino and Grasshopper files attached below.)
This is not a bug. However, it is a limitation. Let me try to explain. Grasshopper has had a simplified set of dimension components for a long time. David R wrote these components before we had wrapped up any of the AnnotationStyle classes that exist in Rhino. To make this work, he wrote his own drawing code to display the dimensions so they are close to what you would see when you bake the dimension. However, what actually happens when you bake it is that it creates a new linear dimension (in this instance) and assigns the current annotation style in the document to that dimension. This is why the text may look different when you bake it. It’s getting the current annotation style assigned to it, rather than whatever simplified settings are exposed in that component.
Now, in Rhino 8 we have recently wrapped up the native annotation styles as well as all of the other native annotation types like linear dimension, angular dimension, radial dimension, leaders, text entities, etc… So, if you use these newer components, you can assign a specific annotation style from the document (or create your own in GH) and the annotation should be displayed exactly as it does when it’s baked. You can read more about these new components here: Rhino 8 Feature: Annotations and Hatches in GH1
I’m not too concerned about the annotation-style being different when baked; I understand that it will not be the same.
I’m mostly wondering about the position of the baked dimension. The position of the baked dimension is not always consistent; sometimes it attached to the line, and other times it moves-away from the line. Which is not intuitive.
(Whether the font, color, text-size, and/or orientation of the dimension is different isn’t what I’m asking about (I assume these things are AnnotationStyle). I wouldn’t expect those things to change the xyz position of the dimension by an arbitrarily large amount. In the example file, you can translate the line to any Z-coordinate you wish (say, 10,000+) and the baked dimension will fall into the xy-plane which would be 10,000+ units away from the line. The dimension would be so far away form the line, it wouldn’t be clear what geometry it is measuring.)
Here are some screen-shots illustrating what I mean.
I see. Ok, this might be a bug. I’ll try to take a deeper look. For what its worth, the Rhino 8 version of the dimension components also has a plane input parameter that you can set in case the default plane is not satisfactory. For example, if I baked this component without specifying the plane, the dimension gets set on the XY Plane. But, if I connect a point to the Plane input, it creates a default XY plane whose origin is located at that point, and so the dimension gets baked using that plane instead… ultimately making the dimension appear where you intended. But as I said… I’ll try to dig a little deeper.
Ok. After some internal discussion we decided that it might not make the most sense to change the existing dimension components since these have been out in the wild for quite a while and making a significant change to the underlying code would cause definitions that were made previously to not function as they had before. However, I have updated the new Aligned Dimension component in Rhino 8 WIP so that it now tries to find the best fit plane between the two points so that it “should” try to give you the most appropriate linear dimension when you first create it. And of course, when baking, the dimension is baked exactly at that planar orientation (rather than being projected back to an existing CPlane). This should be available in the next Rhino WIP release.
That was very helpful.
