Annotation bounding box bug

Hello McNeel developers,

I suspect that there is a bug that makes annotations create incorrect bounding boxes in Grasshopper

Few SR’s ago (pictures below from 8.27) I remember that BBox was working fine for annotation text, whereas there have been problems with dimensions for instance - bounding box was made larger, with the expected size basically multiplied by Model space scale

Now (8.30) there are issues with Texts as well. They are proportionally smaller, as if the model space scale was not applied to the BBox - expected size divided by model space scale. Dimensions are still wrong, but in a different way - length is now correct, but the texts and arrows are not included. I tested with 8.31 with the same result.

I believe that this is not intended. It would be perfect if we could apply bounding boxes or bounding rectangles on annotations without having to explode them, which is not viable option for larger volumes of annotations.

Please, if possible, take a look at it.

EDIT: I expect that it’s not a problem of BBox component itself - we are actually using Bounding Rectangle from Pufferfish but they behave the same.

Thank you!

AnnotationsBBox.gh (46.2 KB)

Hi Antonin,

What problem are you trying to solve?

I do see inconsistencies, particularly vs actual Rhino dimensions and the bounding box command and its grasshopper counterparts.

RH-96024 Annotation bounding boxes produce incorrect results in Grasshopper vs. Rhino — model space scale not applied consistently

Hi Japhy,

thanks for recording the issue.

Sorry if my description is unclear. The ultimate goal is to have all annotation features in a state when they produce accurate bounding boxes, including all the building elements of each annotation (line, arrows, texts).

If your question is about my particular problem and not the general intent, it is hard to explain and does not help you much, but anyway:

We are using annotation text bounding boxes to position even more texts relative to that in a script that creates custom ordinate dimensions, since the native dims are not sufficient for our case. With newer version of the script, text bounding boxes do not match anymore, texts collapse and so do the drawing projections during nesting, because nesting uses bboxes as well.

Exploding annotations, as mentioned, is not the way to go, since it nukes data tree (which I could fix) but most importantly the computation time. There are hundreds of annotations, I really do not want to explode them :slight_smile:

So we either have new version of Rhino that fixes other important problems, like this one, or valid drawings. Tough choice to make.

Hi @Ukrutony,

Unfortunately computing a true annotation bounding box is not possible without knowing the view you use to display it.
Even exploding the annotation will not give you a reliable bounding box.

See video below.

I will push a change in 8.33 to improve plain texts but texts on annotations is not possible without a new component that also takes a view.

This is now 8.33.

How about using capsules or rectangular frames on the annotation text?

@martinsiegrist,

Do you mean as a workaround?
The issue is the text may display above or below the annotation depending on the point of view and the component does not know the point of view.

The blue rectangle is the BoundingBox Rhino gives you when you run the command on the Perspective view.

This annotation has different bounding boxes per view.
I can’t give you several, maybe the Union of all, but I’m not sure this will help @Ukrutony .

Yes as a workaround but it seems the annotation still would have to be exploded. Maybe a light explode :slight_smile: would help… it could extract just the text as text and the rest as lines or points :slight_smile:

Hi Kike,

Thank you very much for looking into this.

I understand the problem with annotation text inside dimensions - they flip based on the active view direction. However, even plain annotation text can behave dependent on a view once you use annotation style with “Horizontal to view” setting. How did you achieve to handle it? Are you somehow skipping this case?

We could theoretically define two cases when it comes to dimension settings/view/bbox relation.

1st case is when you as a user want to have the annotation text in dimension readable and therefore oriented by the view. Or you want view oriented plain annotation text. For this case though I can’t straight away recall a reason for which I would utilize BBox. Maybe some viewport draw foreground witchcraft but we are not doing that.

2nd case is ours, and that is when you need accurate bounding box of annotation because you need to use it eg. for positioning stuff around it, or nesting overlapping dimensions. That in our case implies that your context is a plane in which the dimension exists and that is the information that is known for most annotation objects IRRC. If there is not Plane input directly, then the plane can be at least determined from other inputs. And that object defining plane is exactly the plane in which we search for the element bounding box. I guess it is carried along with each element since it can be also read using the annotation components, and BBox component has it as an input too.

How to deal with the logic around “Horizontal to view” I don’t know. Now I’ll be thinking aloud:

Could default behavior be that bounding box is always considered for the object’s defining plane? If the “Horizontal to view” invalidates such approach in some cases, could annotation element using annotation style with “Horiontal to view” setting ON be skipped?

What I don’t know is, if each annotation object carries information about its bounding box and BBox component just reads it, or if it actually computes it from annotation geometry and objects defined against view are omitted?

All in all I want to say, that even the fix you made will probably be sufficient for my case, because I have all annotation texts in one common plane and NOT “Horizontal to view”. Script is working from the top view and all annotations are in world XY. Also for dimensions the accurate length is better than the wrong value we had previously.

Ideal case remains the same though. If it’s too hard to reach it or it is too difficult and niche to be prioritized, we have to accept it.

@Ukrutony,

Currently when the text is Horizontal to View returns a singular box that is just the point were it is inserted.

Extracting the true accurate bounding box will take more time and I see this as something to fix in v9.

I see your point about using some convention about the view plane. It may become a bit obscure but definitely doable.

Most of the efforts right now are put on releasing v9 and my priority here is giving you something in v8 that you can work with.

RH-96024 is fixed in Rhino 8 Service Release 33 Release Candidate

Hi Kike,

I think we are aligned here. Provided you fixed the bounding box for plain annotation texts in 8.33, our particular problem should be solved.

If you manage to improve general function for v9, even better for everyone.

In any case thank you for your time!