@TIG This looks like a problem already encountered by a few users about the persistence of menu structures in the API on Windows. As I was not able to reproduce it, I never understood the root cause and I never found a fix for that. Just detect the issue (hence the Ruby console message). For information, this is anyway fixed in SU2023 and above, because Sketchup changed the way it handles menus in Windows.

Sometimes, just by articulating the question you find the solution yourself: I created a small texture 50x50 pixels with a solid colour and now it displays correctly. But do I have to do this every time I want a solid colour to display correctly in parallel? [image: wQqC_1.jpg]

Ok, my bad! thanks! (and thanks for the reply!)

Hi, I hope you don't mind deleting my bundles too! I have like 30 and it's very hard to look for the right one. (I only need the last one) Thanks

This fixed it for me, this has been an intermittent headache forever.

thanks guys! s4u looks a lot better as they remain solids. (of course there is this 20 dollar price hm hm...) any ideas for roof tile plugins?

@aris said: actually skipping one sleep, 'render night' opportunity to brush up my Layout skills in the waiting times Very good. Efficient use of your time. @aris said: P.S. I owe you one mousaka for your help Do you have 4 feet of snow on the ground and 64 KPH winds? If not, I'm headed for the airport. Maybe one day I will get to Greece and eat mousaka with you.

I replied in your thread about shadows not showing when you update the scene in SketchUp. It is exactly your workflow that causes that sort of thing. If you would actually create scenes that have the properties, including styles, and camera positions that you want to show in your LayOut viewports and you avoiding doing things in LayOut that result in the scenes showing as modified, you wouldn't have any problems.

[image: KujN_1.jpg]

Yeah, there's been discussion that since recent versions of SketchUp all have a 3DWarehouse window it should not be also merged into the Components browser. So far, no change, though.

Good enough.

Contact Barry Milliken of 2DXY Site Survey (on EW), he might be able to assist.

There's nothing wrong. There's nothing to fix. It isn't painting the back faces when you paint the component/group container. You shouldn't be painting the component/group container. You should be painting the faces. If you do, all of the container will show the material. Also, if you paint the container you won't have the option to adjust the orientation of the material. You must paint the faces to have that ability.

@aris said: No, the point is that you want to keep the initial components interlinked so as to keep working on them.What I want is to unlink the "children-components" from their perspective "parent components while keeping them in place If it's about one parent component with a child component, 'Cut' and 'Pasted in Place' or the 'Outliner' would suffice. But to get the child out of all parent instances and keep them all in place you also need the 'Component' browser and its option to replace a selection of components by another component. Copy the parent =(A with child C) to the side. Make it unique =(B with child C) > Get C out of parent B's environment > Componentize (B) + (C) into component D =((B)+(C)) Select all instances (A with child C) and via the 'Component' browser replace the selected components (A with child C) by component (D) > then explode (D) to get all instances (A) with all the respective instances (C) in place. It's quite fast, even with hundreds of instances (A with child C)

I've not used it, but I built my own somewhat similar system that uses lights to read commands from my head movement. While I and most use it for simulators it could be used for a myriad of systems. http://www.free-track.net/english/