Deleting all the texts that have gone bonkers should work. The difficulty is in identifying and selecting them for deletion.
Purge unused will not affect this problem, as texts are not something that can exist but be unused.
Yes, scene tab, sorry.
Scenes are pretty useless for me the way they are now. Perhaps when we get to the presentation stage they’ll be useful, but right now, they turn on all the layers resulting in basically an unusable model until I tediously turn them off again. It’s much quicker to manipulate a layer-restricted model.
I’m taking your advice to work on the floor for level 1 outside the main model. It’s much faster, as you said, and also there were major problems under the floor I couldn’t fix otherwise. I may have to do the same for level 0 which now has two levels of floor: F0 - floor and F0 - foundation floor Both of them are getting problems I can’t fix in situ.
I didn’t really think it would, but since I tried it first just having deleted the one (visible) text you said was rogue, I hoped…!
Or is the ‘rogue text’ you found and deleted just not showing anywhere now except ‘near infinity’?
If not, I’m still unclear how it can display itself in the right place, yet still cause a problem
Once you have one of the scenes set to your liking with only a few needed layers showing , R-click on the scene tab, then Update. That preserves the scene attributes you have selected - including, usually, camera position, layer settings, status of hidden objects, and a range of other properties of the scene.
Rename it appropriately - for example, Model F1, Model F2 etc.
But for things where you don’t need the surroundings from which to inference, work on them separately.
PS. These last few posts probably belong better in the PM thread. Use that to follow up on these otherwise ‘off-topic’ posts in this thread.
I think there were two texts with that same content, one ok and one gone rogue.
That would make sense. At least one text got somehow detached from its anchor point - probably when I deleted the line or rectangle it had been attached to. And I then moved some, and also changed the text by copying from one existing text label into another.
So fairly easy for SU to get messed up wondering where or whether a text label belongs.
Tried repeating that in a simpler model - deleting some geometry after placing leader text - but even after half a dozen tries, I couldn’t reproduce the rogue behaviour.
One further thought. If you can fix it, Steve, maybe a Feature Request should be made for this to be built in to the SU Model Info : Fix problems?
If they can’t find the bug that causes the problem, perhaps at least the SU team could set up a routine to Fix it?
1 Like
to me this seems to be a badly made model, compounded by the use of Parallel Projection…
i.e. there’s a Dims Layer without the dims and most the text is inside a component containing geometry, but the leaders point to geometry that aren’t…
john
I agree it isn’t one of the most elegant constructions I’ve made!
There were (and are) dimensions, but they might have been turned off with the ToggleTextAndDims plugin at the point when you looked at the model, but they are on the Dims layer, and appear/disappear when that layer is turned on/off, with the ToggleTextAndDims switch set to ‘View dimensions’.
And yes, it is inconsistent in where and in what layer I attached the text labels, and made it further inconsistent when I changed some of the text in existing labels. So yes, it didn’t start very clean.
It’s in Parallel Projection because it is only a plan view, designed as a (temporary) component to help locate a series of elevator shafts in a 3D model.
Aren’t what? In the same layer as the geometry? Or in the same level of component nesting as the edges they link to? Or…?
I’m not being sarky about your comment, I just want to know how better to make the connection between text and geometry in future, to avoid this problem, and don’t know quite what you meant here.
No argument that the model isn’t particularly well organized, but that doesn’t explain why or how it triggers the bug.
It’s become clear to me that Texts contain some beneath-the-surface properties and behavior that aren’t exposed by the Ruby API, and those are likely involved in the bug.
If you point a text at an Entity, it will move around on the screen with that Entity. You can verify via Ruby that the Text’s point property is being recalculated dynamically to track the Entity and its screen position is according adjusted. But the Ruby API provides no indication that a Text even associates with any other Entity.
If a Text isn’t pointed at any Entity (is “leaderless”), its point and vector attributes are nil yet SketchUp knows where to display the text on the view. So, obviously there are screen coordinates stored in the Text that are inaccessible via the Ruby API.
My hypothesis is that under some as yet undetermined conditions (e.g. direction of view, “pointed at” Entity erased, projection, …) the tracking goes haywire due to an untrapped divide by (almost) zero or equivalently an attempt to invert an (almost) singular Transformation. But I haven’t managed to find the right combination of conditions to create a reproducible trigger.
1 Like
This topic was automatically closed after 91 days. New replies are no longer allowed.