We are 3X in V7, so many years of development and we still are dealing with the most absurd problem of Rhino not displaying text in certain positions:
I think this is by design. When the text plane is perpendicular to the View plane, it will not display those texts. You can see this when using _RotateView in any of the orthogonal views that doesnât show those texts. If what I describe is different from what you are referring to, pls explain with a sample file.
By design? What is the benefit of it? Can you describe the situation when you need the text facing viewer except side views? Can it be hacked?
Iâm not a heavy text in viewport user, so difficult to tell, but a use case I can imagine is that you have texts associated with front, right and top, and that you donât want to see the texts in all views at the same time as that would most likely create overlapping text.
From the screenshot it is hard for me to tell how you are using it.
I have a monster script that builds all kind of bathroom interiors, fully automatic.
The whole model along with the quasi-leaders is one-click made. On top of it, it generates the full visual report where no extra work is needed except the ******** text.
If this was working Horizontal to view at every view, this job would have been complete.
By any of the side views, do you mean top/front/right?
Can you explain your steps to replicate?
When I create a text block in each of the Top, Front, and Right views I see intuitive, consistent results when I check and uncheck Horizontal to View.
As expected, something I created in the Top view is 2 dimensional (and therefore invisible, I didnât zoom to see if I get lines) in Front and Right. Likewise for text blocks I create in Front or Right.
The checkbox seems to affect only the perspective view: whether the text is re-oriented to be perpendicular to the viewer.
Iâm not sure how you specify which basic view is the ânativeâ one for a new Text Block in a script. In the GUI, it seems to be whichever I drag it into after creation.
(behavior seems the same in V7 and V8 but the menu item is Dimension in 7 and Drafting in 8)
On:
Off:
Hi Nathan
As i wrote, everything is created by baking from GH script into model space.
Insering the associated text to each view, in my scenario, would take lots of precious time and could be prone to mistakes.
There must be solution without any manual labour.
OkâŚ
In general, Iâve seen the devs who work with the scripting and RhinoCommon API be quite receptive to specific suggestions if someone says:
âHereâs my step by step workflow. Iâm having a problem because there doesnât seem to be a scripting equivalent of step #7. Can someone take a look at this with me?â
It might be as simple as a missing but easy to add parameter to whatever youâre using to create the text block now. Or, someone might have a quick copy/paste Grasshopper script component workaround.
" Even, if the style set to Horizontal to view , it is still not displayed in any of the side views." is a pretty vague problem statement with no replication steps, simple grasshopper script which replicates the problem, or resulting .3dm file.
hi @Piotr from your description and screenshots it is still not very clear to me what you expect. Are those squared numbers supposed to be visible in all 4 views?
A solution could be to place all text 45 degrees rotated on all axis, so that is isnât parallel to any view.
There is no need to create any more description than that I wrote.
Any GH baked text is not seen in a side views. How to fix it?
Text blocks, leaders and dimensions are planar objects based on a construction plane. That plane is actually part of how they are defined. By default, they are not designed to auto-rotate to match the view. Since they have no thickness, they are invisible in any edge-on view of them.
That being said, the âHorizontal to viewâ setting is not completely correctly implemented. If you check this, in any view that is even slightly off-axis, they will show up as horizontal to the view. However, if an ortho view is axis-aligned, edge-on they disappear.
Hereâs baked text from Grasshopper in a side view (right view).
Mitch:
I agree with you that there is a flaw in implementation. If rotating by, 30, 45, 70, 85, 89 degree does not change the appearance, why 90 deg does?
Annotation dots works this way.
Nathan:
I know this method, but it requires constructing individual plane for each, and there is no remote baking.
The thing about this âfeatureâ that is a bug to you, is that Iâm quite sure there are customers relying on it, so we can not simply change this behavior. Textdots are texts that only carry a position, and are screen space objects.
Maybe a âshow in perpendicular viewsâ override needs to be added. I do wonder if the workaround I suggested can help you out.
I agree. Some people may have their workflow built around this feature but for me, for almost 20 years of using Rhino, from graphic design, architecture, product design or masterplanning never found this useful.
In the contrary, I found the lack of display consistency very annoying.
If this can be fixed by some extra box to tick you have my two thumbnails up.
Yes, perhaps. It does seem odd to me that the âHorizontal to viewâ setting specifically excludes edge-on ortho views, but allows them in ones just slightly off axis.
I have bypassed the problem by using Annotation Dots instead of texts and Iâm going stick to it.
