Most intriguing! I don't have an answer, but here's some more discussion for thought...

At least to the precision you printed out, points 4 and 13 are identical, as are points 8 and 12, yet these vertices have not been merged. That is probably the cause of the behavior: the sequence of vertices looks like an ordinary outer loop to SketchUp. But why are they separate? And why did SketchUp gather them into a Face? Possibilities that come to mind:

• they differ in decimal places beyond what you printed but still larger than the merge vertices threshold of 0.001". I don't know what units you used, so can't tell. At full precision, there might be a tiny gap between these points.
• the merge vertices and geometry cleanup operation misfired (which would be a bug!)
• the intersect operation explicitly built these Faces that way (which would also be a bug!)

Regarding the randomness, do you get different results if you undo the operation and then redo it with the identical geometry? If this produces the same results but moving or changing the geometry in any way causes different results, it sounds like a computer arithmetic problem that varies depending on the exact values encountered (not that this observation gives you a clue what to do about it .

One trick I've had work in some situations is to nest everything one extra level deep in a Group, do the work, and then explode that temporary Group when completed. This seems to trigger another round of geometry cleanup which may repair the flaws.

What technique are you using to identify the red faces? They look pretty regularly sized, so I am confused about what the floor grid looked like...were its cells of varying size?

I've not seen that effect, but it looks like it is sensitive to the exact geometry involved and its location in model coordinates. Maybe there are "leaks", i.e. Faces not quite closed because of where the intersection points were placed? That could be a consequence of finite computer arithmetic during the intersection. Those look like roof planes, and if so this is probably not the infamous nearby vertices behavior. Maybe you could examine a sample closely to see?

On Mac, there is a bug (which I reported and filed some time ago) in the handling of things created using the various view#draw_xxx methods within a Tool. The items from the currently active_model's view are drawn to all views. As soon as you select a different model/view, it's selected Tool activates and its draw affects all the views. So, ultimately it is only a cosmetic bug because the only Tool active is the one for the active_model, but it is visually quite annoying.

There are also various "purge" and "clean up" plugins available on the sketchUcation store that delete not only unused component definitions, but also other items such as materials (which can seriously bloat a model), empty layers, etc..

I see the same. Evidently Sketchup does not promise to order the elements of the Selection based on the order in which you picked them on the GUI or Outliner. This may be a result of the data structure SketchUp uses to store the selection set (some structures optimized for search don't preserve order). You may need to give the entities names first so that you can test which one is which (this is a good idea anyway).

@sdmitch said:

The red faces are faces that consist of two or more grid "cells".

I'm not sure what you mean by this. Do you mean that the intersection produces duplicate Faces?

@driven said:

my thinking was based on taking actual images of my stock timber [sheet, butterfly veneers or planks] with grain always running in the same camera direction...

John,
So, basically, you would overcome my second issue by forcing all your textures to follow an orientation convention. That will work as long as you create all your textures from your own photos...but what about photos and materials created by others?

By the way, this is similar to the way Dave Richards and some others create wood materials: they take a photo of an actual board, import it onto a rectangular Face the same size in SketchUp, then make a texture out of it. I don't know how the UV gets aligned when you do this...does it matter which way the Face was oriented?

@driven, I've thought some about this in the past. There are two problems that seem to require manual input from the user:

First, there is no way to automatically infer grain direction from the shape of the board. One would naively associate "along grain" with the longest dimension of the face and "across grain" with the shortest dimension of the face. But I can show real examples in which this logic fails, that is, the "along grain" direction is the shorter dimension of the face. Cutlist doesn't even try to address this question; it ignores grain. Cutlist Bridge 3 uses entity attributes to label which way the grain is intended to go, and a common complaint is that it is tedious to set all these attributes.

Second, is it likewise incorrect to infer grain direction from the shape of a texture. It is tempting to assume that the grain must run along the "long" dimension of the texture's image, but again this doesn't have to be true.

Normally SketchUp shades surfaces as if the light source is at the camera. It does not cause shadows to be cast, regardless of settings. The "use sun for shading" instead shades surfaces as if the only light source is at the sun position. When shadows are displayed, this can produce a more realistic look because you don't have shading from one light source and shadows from a different one.

Give the following a try and let me know if there are problems. This version combines the nested logic requested previously with this change to the default new layer naming. To avoid confusion, it appends " dims" to the name of the current scene. If there are no scenes or the current scene is not named, it will revert to the previous default of "DIM_TEXT".

One issue I know about is that the UI.inputbox may truncate the strings it displays - they are correct but the dialog doesn't expand to show them. This is a known bug in inputbox that I can't fix except with a rewrite to use a different input technique.

[edit] The rbz I uploaded earlier was somehow damaged. Please use the one in my later post.

Not sure what I did wrong before, but this new one works on my system:

dimension_utilities.rbz

I may have botched the zip! Will look into it and get back shortly. Sorry about that...

Open the Shadows window and check the box "On Faces".

Those errors indicate that the files for SketchUp Pro's in-distribution extensions are damaged. I suggest you download a clean copy and try the install again. Your post suggests that you got the download from an unofficial source, and this could be the cause.

Have a look at the Cutlist plugin (available from the Trimble Extension Warehouse) or Cutlist Bridge 3 from Joe Zeh (no longer free, now sold via popular woodworking http://www.shopwoodworking.com/cutlist-bridge-extension-for-sketchup). There is also a cutlister extension on the sketchUcation plugins store, though I haven't tried it.

@krisidious said:

So this older program I have uses this command called +fullproc. It's supposed to make the program use all cores or threads. I wonder...

I doubt it. Programming to use multiple threads or cores effectively requires techniques to split up the workload into pieces that can proceed in parallel and to synchronize the results afterward. This is far from easy or automatic, and is not even possible for some kinds of tasks.

Yeah, it's a longstanding gripe among Mac users (I am one also). On Mac, the Materials Window interface is a kludge built clumsily atop the Mac Color Chooser. On my Mac the eyedropper down by the samples palette at the bottom brings up a magnifying glass cursor to sample the color at a single pixel, not to capture a material. Plus it causes the cursor to vanish when finished so that I have to activate another window (command-tab) and then come back to SketchUp to get a visible cursor again. The Windows version is far superior.

I don't think you can make a separate component automatically track a loose geometry face, but if you select the face you can easily move a copy aside to use as your parcel.

There are known issues with markers being too small to see on high-dpi displays such as mac retina, but I have never before heard it associated with an upgrade from Mavericks to Yosemite. Are you sure you didn't modify your display settings along the way? Check what is set on System Preferences->Display.

thank you!