Custom Page Layout Annotations in Display Conduit

Hi All,
I’m really confused and could use some help about the various transformations used in display conduits for moving between model (detail) spaces and paper spaces. I haven’t seen a comprehensive overview of those transformations, and it’s quite unclear to me which would apply. (These past discussions don’t seem to tell the whole story: Annotation on a Layout, CRhinoPageView & CRhinoDetailViewObject, RhinoCommon Printing)

I’m trying to use my display conduit to overlay some annotations on various detail viewports in a paper space, as shown in the mockup below:
image

Simply, each viewport gets a black background (e.Display.Draw2dRectangle - size derived from e.Display.Measure2dText) and white text (e.Display.Draw2dText) in each corner.

If I just use the Draw2d[Rectangle | Text] as they are, they do not scale with the paper, and remain fixed based on the size of the viewport on screen.

How do I get 12 point (for example) text to render as 12 point in relation to the paper drawn on the screen, rather than simply 12 points on the screen?

Is it drawn in the detail viewport (i.e. e.Viewport.ViewportType == ViewportType.DetailViewport) or in the page viewport (i.e. e.Viewport.ViewportType == ViewportType == PageViewMainViewport and cycling through the GetDetailViews() to get the locations of the detail viewports)?

Thanks
Dan

Hi Dan,

i had a similar problem. I solved it by applying a transformation to the viewport with SetModelXform like i discussed here Get Model -> Paper scale within conduit’s ExecConduit

Hi Wolfgang,
Thanks for pointing out the other link. I hadn’t seen that. But, I’m working in C# (not C++), and GetModelLength doesn’t seem to have been moved into the RhinoCommon (v6) libraries, unless it is DetailView.PageToModel and that’s just used in CRhinoDetailViewObject::GetModelLength.

If I’ve understood your other posts, you’re drawing objects in the world/model space, and translating them so that they are in the right spot in the detail/page space. Does this seem to be a better strategy than using Draw2dText or Draw2dRectangle?

Hi

i don’t know the differences between c++ and c#. i assumed you are using c++ because you referenced my problems. But anyhow, i think the main behavior is the same on both languages.
For what i understood if you are using a conduit you are adding additional drawing commands to the pipeline and this is always in what you call world/model space. How it is displayed depends on the view and on the view transformation. Of course the text is something special because you have a 2D font size drawing in a 3D world.
To answer your question: yes i use a transformation/rotation/scale with SetModelXform and in DrawString i use for the insert point (0, 0, 0)

There is fortunately a lot of overlap between C++/C#, so prior insight can be used regardless of the platform, even if sometimes the translation is not obvious.

At least for C#, there are a few 2d drawing commands that don’t necessarily draw in the 3d world space (e.g. Draw2dText Draw2dRectangle Draw2dLine) - these have options to draw in the screen viewport space (using the values returned from Viewport.GetScreenPort).

In this case, it turned out to be a combination of scales (similar to other examples where a combination of transforms is used), to draw text of a specific point size on a page:

UnitSystem pageunitsystem = e.RhinoDoc.PageUnitSystem;
e.Viewport.GetWorldToScreenScale(Point3d.Origin, out double scale); // View must be orthagonal, and 
                                                      //must be the paper space. Detail view may not return the same value since its world space is the model.
double pointToPixel = scale / RhinoMath.UnitScale(pageunitsystem, UnitSystem.PrinterPoints);
int TextSize = 12; // Text Size in Points
e.Display.Draw2dText(text, color, new Point2d(leftcnr, topcnr), false, (int)(TextSize * pointToPixel), fontName);

Quite fortunately, this also scales correctly when printing, rather than outputting screen dpi (96 for an older screen) it uses the anticipated printer dpi. (Additional math not shown here is required to make sure placement of the items remains as anticipated.)