Just drag the file into the message box.
Ok, the yellow cube is now in the warehouse under the same name. Unlike the last time I did this (a few years back) there doesn’t appear to be any kind of ‘get the code to share’ mechanism?
Hmmm…just searched and I couldn’t find it. Did you make it public?
You must have a set of components hidden and saved in your template.
Purge the template and start again.
Make a clean Save as Template.
The Hide command is context sensitive after the first go, which often leads to confusion.
Layers are a better way to control visibility.
View > Component Edit > Hide Rest of Model and Hide Similar Components is easier still.
OK, found it.
As Box showed, there is a hidden Group (MGF 203UC Brace) nested inside your Yellow Cube Component. You can’t see or select it unless you have View->Hidden Geometry turned on. When hidden geometry is viewed, it shows up as dashed line wireframe. You also can’t delete it unless Yellow Cube is open for edit.
So, returning to your original question, are the mystery wire frameworks you are referring to from this Group?
I guess you downloaded within SU, the yellow cube’s not a group or component, just raw.
Ah, yes I did. So forget the part about nesting…just a consequence of importing directly into model. So that leaves the question of whether View->Hidden Geometry was on, hence the hidden geometry was shown as wireframe.
Yeah, that’s why I suspect he has it saved in his template. It’s made of a bunch of groups and components.
Just copy and paste the web address to the model.
As you can ‘work around’ the display issue, some of the tips on making SU faster may help you work around it better.
Try just disabling fast feedback in Window > Preferences > OpenGL. This is something that kicks in when models reach a large size to improve performance. But it may not work as designed with some cards/drivers.
Sorry, I’m confusing you guys. The pit props accompanying the yellow cube are supposed to be there! I took them out of the warehouse last night and just dumped them to save opening another file.
The residual ■■■■ that is causing all the problems is infecting a much larger model. If I get the time I will put that out for you.
I’ve just put a model in the warehouse. It’s called under sea tunnel entrance. If you turn off the sea bed layer you will see these lines all over the place! Another annoying thing SU does is fail to soften all lines on command. There is no reason for it to do this, as the lines can be sorted out individually after the event. BTW: I can still see no way of linking models directly from the warehouse to here. There is nothing intuitively placed on the warehouse page to allow you to do this. This used to be straightforward a few years back, so something has been changed here!
The strange lines in your model are profiles from hidden edges that were left behind on layer0 when you associated the Sea Bed layer with their corresponding surfaces. You can confirm this assertion by hiding the Sea Bed layer, then turning on View->Hidden Geometry. You will see lots of hidden edges from the surfaces to which you assigned the Sea Bed layer. You will see that the mystery lines are in places where SketchUp thinks a profile is needed. If you select the hidden edges, you will find that they still have layer0 associated with them. If you orbit the model, the places the profiles appear will change! You can further confirm all this by editing your style and turning off profiles.
The root of your problem is that you have associated the Sea Bed layer to a lot of ungrouped primitive geometry (edges, faces, and in particular, surfaces).
This specific case is something I have previously reported as an inconsistency bug: the edges defining a surface are softened and smoothed, making them hidden. If you select the surface by single-click, the hidden edges are not selected along with the surface (because you can’t select a hidden entity). When you then associate a new layer to the surface, the edges get left behind on the old layer. But because they are soft and smooth, they are not visible so you don’t know this happened. I regard this as a bug because it is inconsistent with what happens if you single-click the surface and then apply the move tool: the edges move along with the surface even though technically they are not selected! To get the edges as well as the faces, you have to triple-click or View->Hidden geometry and then select using a drag box instead of a click.
This is a prime example of why all the experts advise you never, never, never to assign anything besides layer0 to primitive geometry. Never, never, never make anything besides layer0 the active layer (exception: when all you will be doing is creating dimensions or text - but remember to set layer0 again afterward). Severely confusing visibility issues result when you violate these guidelines. When you want to hide geometry using layers, create a Group or Component first and hide that container, leaving the primitives on layer0.
And if the thought crosses your mind “gee that seems like a terrible design”, you are not alone 
I understand exactly what you mean about the inconsistencies thrown up by this yes or no inclusion of boundary lines. BTW: I note I got a four block telling off for my use of a good old Anglo Saxon classic. Yet Catamountain gets to call stuff ‘crappy’ and nowt happens!Rank, and ‘Sageness’ clearly attract their privileges!
“Crappy” isn’t 4 letters long 
This Layer issue is a good reason why people also recommend modeling with the Entity Info window open - you can keep an eye on Layer assignment while modeling, among other things…
If fixing your Layer assignments fixes your display issue, then don’t update your graphics driver. What you have is working well, although fast feedback may need to be disabled. AMD OpenGL driver support has been a bit iffy over the years. Lately such support has been deficient.
The “block telling off” is an automatic feature of the Discourse software used by the forum, it is not done manually by the moderators. It seems to have inscrutable rules about what to allow and what not. What you could write vs what catamountain could write is a result of the specific choice of words, not privilege or rank! There was an amusing off-line discussion among the Sages a while ago in which people tried all sorts of combinations to explore what can and cannot be written here.
Aside from the errant use of Layers, housekeeping is by far the greatest issue.
Neatness counts.
Working among hundreds of stray and lonely edges only leads to more problems.
Leaving tiny odd components scattered about adds to the clutter and confusion, not to mention, the file size.
Those were hidden and accounted for >3 MB of the 3.81 MB original file.
Here’s a cleaned up copy of the model:
Under sea tunnel entrance_ Fixed.skp (491.4 KB)
The collection of tiny odd components found hidden in the model space:
Stuff.skp 3.27 MB
https://drive.google.com/file/d/0B6R273kvdPGOZHloc0dneFF3Vms/view?usp=sharing
Thanks; you didn’t need to do all that for me! I knew these lines were there, BTW. It’s the ghostly ‘wire framework’ that persists on turning off the layer that bugs (sic).
I understand exactly what you’re saying about the extra workload the PC needs undertake to process all my extraneous junk. BUT, what happened to that tool which used to delete unused lines automatically? I can no longer find it, thus I just delete some - or the worst of - the rubbish and rather shamefacedly leave the PC to cope with the remainder! It is this approach that accounts for all the stray lines flopping about in the breeze; they’re just too much of a hassle to pick out one by one.
So, yeah, can that tool still be found? Granted, it didn’t work 100% of the time. But it was better than nowt.