Text drawn by an overlay (or any text drawn using View#draw_text) floats in front of the model no matter what point in the model was used for reference and no matter how you orbit the model. This means that if you use a point that happens to be behind the model geometry in the current view, the text seems to “bleed through” and is always visible. It would be a great improvement if the text could have an anchor like is used for the text drawn using the Text tool and like that text, would disappear when the anchor entity is behind other entities in the view.
Note: one could grep for texts in the current context to find the new one and then modify it, but that is pretty clunky!
Edit: I think the best way to do this would be to expand the set of options that can be passed. That would avoid breaking existing code.
Because the overlay’s extents are a BoundingBox, I don’t think that would work the way I need. There would be no way to prevent texts from other overlaid objects from being clipped just because their anchors are outside the box, not because they are obscured by some model content in front of them.
First of all, I’m just musing / brainstormin’ here.
I’m not understanding what this has to do with view text as it’s in screen space, not model space. Ie, screen text can never be “in the current context”.
I suppose I was thinking that a single overlay would be controlling the text in question. But that would not be efficient.
I don’t think there is any built-in object or coordinate obscuration detection in the API. It has been asked for in the past.
Perhaps, @eneroth3 has done something with this already?
I think the 1st test would be if the point could possibly be within the field of view of the current camera.
Then maybe fire a ray at the point, and if it hits something before it gets beyond the point, then text could be occluded by some object in the foreground.
Yes, it would be nice if this could be done on the C-side for speed and built into the API.
I apologize if I came off as harsh - not my intent. I’m also just pondering how to achieve what I need and not finding a practical way in the API.
I have a working Overlay for face and edge slopes, and the bleed-through of texts creates clutter and confusion on the display. Unlike unattached screen text but like leader texts they move with the point they are attached to (passed as first argument to View#draw_text). But unlike leader Texts, they don’t vanish behind objects in front of them in the view. The only options currently provided on View#draw_text concern the font and centering, not this kind of behavior.
You are right. view#draw_text causes a text to be displayed on the screen without any actual Text object being placed in any context. So grepping a context would be of no use. My mistake.
They would need to be on View#draw_text because Overlay#draw is abstract. It draws text to the screen using View#draw_text. That method returns a reference to the view, not to the Text, so there is no way to influence its behavior after the fact.
Of course, at some level ray-testing is required for any such behavior. For things that aren’t outside the clipping frustum, that’s how SketchUp decides whether they can be seen. SketchUp manages it for leader texts, so beneath the covers there must be a way. Maybe it’s done via z-buffering in the GPU, but since the text drawn by the Overlay has a reference Point3d, shouldn’t it be able to be z-buffered too?
I thought of ray testing for visibility of the Point3d. I fear that using Ruby to ray-test each of the attachment points for edges and faces that are being monitored by the overlay would be a performance hit, as it would be done on every refresh of the view! There could realistically be hundreds of edges and faces monitored by the Overlay at the same time.
Well nothing prevents abstract methods from having arguments (static or optional.)
A better reason would be that Tool interfaces could also benefit.
I would first try to do it once when the model loads, cache the results.
Then attach a ViewObserver and only update the results (Hash or whatever) in #onViewChanged.
The overlay’s draw method would just use the cached results.