It won't inset if there aren't at least 2 edges common with an adjacent coplanar face. This is due to the algorithm used to find the inset face. If there's a different issue than what I described, let me know.

The main problems in creating an "automatic" script are 1) knowing which direction the texture runs (is it up-down or left-right), and 2) reading the user's mind to assign the correct orientation.

#1 is handled by making an assumption that all textures are up-down orientation
#2 could be handled by orienting along the longest edge, but that also assumes SketchUp applied the texture oriented to the short edge.

I can look at this and see if a script could work.

There's a strange ...something... in SU that adds all kinds of non-geometric stuff to the selection set. Todd and I requested it be "fixed" (at least changed), to only add geometric objects to the selection set. After all, who wants to filter out loops, materials, etc., when all we really need to deal with are edges, curves, and faces?

So far, no internal fixes, so we're left to filter objects.

My TextureHelper script was created after a similar request for an easy way to orient wood grain textures. It's not automatic, but it is quick - click a face to rotate the texture, or shift-click to scale the texture (ctrl-click will reverse rotate, and ctrl-shift-click will inverse scale).

I've exported/imported limited info via PageExIm. It can work, but takes some effort - especially when new SU file versions change the data available!

I have StylesExIm on my list of things to do. Should I move it up the list?

By way of update, after a family crisis and extended work schedules ("overtime"), I hope to get back to this soon. I just heard about a peripheral request that might be relevant to this plugin, so the scope might expand (either now or in a future version).

I wrote a ruby that converts 2D CAD imports to 3D models based on layer names, but never released it. It did fairly well at using header info to create the wall segments above doors/windows, but there were still cleanup issues involved. It also had hardcoded wall and header heights, so an interface would have to be added.

So, should I add this to my long list of things to do?

Going strictly on (sometimes faulty) memory, I think VCB input is only available to tools.

Glad you got it figured out. Happy repainting!

That is an old version of Repaint. Get the latest version from Smustard.

@unknownuser said:

(it' pretty much Copy/Paste operation when you have a script to build upon)

sure, other than those sticky copyright issues for the scripts where the author has reserved rights...

Still, other scripts are a good source of knowledge and application. Learn the principles, and you won't need to copy-paste so much.

Oops, sorry, I'm not used to looking at the user info for OS data - it clearly states "Vista" as your OS

That's a really strange situation. Contact me via Smustard and we'll go from there.

Even if we did want more clutter, it is currently not possible to add existing geometry to a nested G/C via ruby. This is a known bug, awaiting resolution.

I've noticed it, and I think it's an issue with ruby in SU - creating a lot of new geometry in an already dense model takes a LONG TIME. However, I'll check the code for Windowizer to see if there's something in it that might be a culprit.

Not sure what the problem could be. My version autoloads just fine. Are you on Mac or PC? It could possibly be a file location issue.

My first shot at a screen-capture video. This shows the actual plugin in action, with no editing gimmicks.

It sounds more like CloseOpens - closing up the tiny gap between segments that should touch.

Update
After some bug squishing, I have two feature items left to implement:

1. Scene and Group renaming
2. Group removal (single and global)

Another thing I'm considering is a SceneGroupReader. It would be a view-only interface (no drag/drop or organization tools) that would provide just the collapsible groups and click-to-select scenes. It would be offered with the organization set and as a free standalone. Thoughts?

I was also thinking about a text file export-import feature. I imagine it would work this way:

1. user exports (via the plugin) the scene names to a text file
2. user opens the text file and adds group headers before each group of pages (all pages under a group header will be added to the group)
3. user saves the text file, then imports it.

I think it might be faster in some cases than even drag/drop. See sample text files for before/after. Thoughts?

Thanks, all!

before-after.zip

Yes, I plan to add a renaming capability to the mix. It wouldn't be a global rename (pattern-matching) functionality, just a per-scene rename. The goal (though maybe I'm thinking too narrow) was simply to manage large quantities of scenes, and get them organized and easily visible. Renaming fits my scope (organization), and I suppose if enough people asked, I could possibly be persuaded that there's a case to be made for a pattern-matching rename function within this plugin. I didn't intend to duplicate Todd's functionality, but perhaps something could be worked out.

@John: I think it could be managed with PageExIm, and maybe also with a direct import (though not right now). Eventually, I could possibly also add the direct import capability into PageExIm's capabilities, and have an idea right now of how it might happen...

But first I'll get this thing rolling

@Dylan: thanks for the encouragement! I think a release is possible in a couple of weeks.