Posts made by slbaumgartner

Thanks @faust07, I hadn't bothered to check for an update! @HornOxx, you can try the newer version to see whether it helps. If my theory is correct about what is happening, it will still fail the same way. I noticed in the comments on the new version the author says he created it for use when importing into Lumion, but as of Lumion 3 it isn't needed any more.

CFileException 0 is SketchUp's way of saying "something just went wrong with a file operation but I have no clue what it was". In many cases, and this likely includes yours, it seems to be caused by other agents such as remote file synchronizers or antivirus scanners that lock a file at the same time as SketchUp is trying to save to it.

I prefer to let authors fix their own plugins rather than usurp their ownership, so I'll wait until you cannot find him before posting any code here. I will just say that I can't reproduce the error @HornOxx saw on my computer, but I can see some dubious aspects of the plugin that might be responsible.

I took a quick look at the extension code. There is a single error handler (rescue clause) for the entire sequence of processing. The message box you showed is posted by this handler. The text up to "Original error message:" is hard-coded, evidently on the assumption that a bad folder path is the only thing that can possibly go wrong (!). The text after that is the actual message from the exception that occurred. In your example it is saying that some (unstated) material name was a duplicate, which is not allowed. I would guess that there is a bug in the processing that attempts to create "safe" names to assign to the materials, causing it to create a duplicate.

If you manage to contact the original author, he should be able to diagnose the issue. But if you can't find him, let me know and I'll help.

Your snippet is missing some key contextual info from the surrounding code: where was edg created and what does it refer to? Lacking that, it is impossible to guess what face=edg.faces[0] returns, hence what pushpull is acting on.

Well, yeah it's possible. The current selection is an enumerator of Entities. Use its #grep method to extract the Entities of interest: Sketchup::Edge, Sketchup::Group, Sketchup::ComponentInstance. For loose Edges, you can immediately apply the material. For Groups or ComponentInstances, proceed recursively using that same process applied to the Group or ComponentInstance's ComponentDefinition's Entities collection instead of the active selection. The one thing you should be aware of is that for ComponentInstances, you can't color the Edges in one without also affecting them in all other instances regardless of where or how the others are nested. Similarly, if you have copied a Group, altering anything in one will make it unique from the others and will not affect them.

Actually, #close_active exits the current edit context, aka active_entities, (belonging to a group or component) and returns to its parent (an enclosing group, component, or the model). Since the selection can contain entities from only one context at a time, all of the currently selected entities have to be in the active context and have to be cleared when you close it.

I agree with @baz, with the caveat that it depends on whether your goal is aesthetic or precision. Sometimes the precise answer looks awful, but might still be the correct answer to the problem at hand. Also, despite the myths about famous artists drawing a perfect circle by eye, the more likely explanation is that their circles are actually imperfect but close enough that the eye doesn't care.

I forgot to mention the preferences are cached by the system so just deleting or editing the plist file will have no effect until you cause the preferences to flush. Logging off and then back in is probably the simplest way to flush the cache.

I think the relevant SketchUp 8 plist was kept at

~/Library/Preferences/com.google.sketchuppro8.plist

(Maybe without the pro in the name if you had only the free version). It contains sizes and locations of the various inspector windows.

If a component has geometry that is very large or is positioned far from the model origin, it will aggravate clipping issues. Always try a component in an empty file to see whether it has such issues (and also if it is excessively detailed for your needs, as that will bloat the model and hurt performance) before importing it into your real model.

There are some known limitations of follow me. Probably the best known is the consequence of SketchUp's small edges (in)tolerance, which can lead to holes in the extrusion from loss of small faces. The workaround is to enlarge the geometry before doing the operation.

But there are also issues when the profile is too large compared to the radius of curves in the path. In such cases follow me may create spurious "wings" jutting from of the extrusion at the curves. Evidently the algorithm can't figure out how to clean them up to form a tidy miter. One workaround that often works is to make sure that the profile is positioned to the outside of all tight curves, as the follow me algorithm has less trouble pivoting the profile around that way (though, again, it can produce small edges at the inside of the curved extrusion).

I don't know whether such an extension exists, though it sounds technically feasible.

Regarding your second question, you can assign a keyboard shortcut for anything that is wired into SketchUp's menu system. The preferences pane for shortcuts has a search field to find a specific command. For example, I found Thrupaint at Tools/Fredo Tools/ThruPaint

When I opened your file on my Mac, SketchUp wanted to fix issues with a lot of invalid object ids. But regardless of whether I let it fix them or not, the only cases in which triple-click did not select all was when the component contents consisted only of nested components. In that case the third click would select the nested component at the location of the click. Is that what you were referring to? Having outliner open vs closed made no difference for me.

@khai said:

@slbaumgartner said:

@c3dx said:

I hope they could become multi core or use the graphic card more so it can react a way much faster with big scene

The multi-core idea has been discussed lots of times before, with technical explanations of why it is not feasible. So, don't hold your breath!

same for 64bi.....hold on a minute!!!!

A wholly different issue. 64-bit was always possible, just for some reason they avoided it for a long time. Despite years of trying, nobody has been able to implement any interactive geometry editor that is multi-core capable (subsidiary tasks can be spun off to another core, but the heart of the editor can't).

@c3dx said:

I hope they could become multi core or use the graphic card more so it can react a way much faster with big scene

The multi-core idea has been discussed lots of times before, with technical explanations of why it is not feasible. So, don't hold your breath!

This won't be of much immediate help, but the back of my mind is saying that I've seen someone report that peculiar error message before. I think it indeed had to do with a problem in an extension that made the Ruby interpreter fail before even getting to the point of processing line numbers or source code. I'd resort to the tried and true method of turning off half of the extensions at a time until the problem goes away (or resurfaces if it went away with the previous binary splits).

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.

That item causes SketchUp to scan the model's geometry database looking for conditions that violate the database's integrity rules. That is, data that should not have happened yet somehow did, and that affect the engine's ability to traverse the database - such as an illegal object id. As in any other database, allowing such violations to persist runs the risk of causing more violations and eventually causing SketchUp to crash. So far as I know they have never documented the rules (just as they have never documented the database schema itself).

My own experience is that most of the time the fixups involve internal issues that mean very little to the end user. And, most of the time the fix has no detectable effect on the model. On rare occasions however the fix can destroy geometry that was entangled in the violations. I don't know whether your disconnected dimensions would be considered an integrity violation or not.

As usual, Dave is correct. Probing with Ruby in the console I see that all three of the dimensions that appear to relate to the rack have lost their connection to geometry in the model. I don't know how that happened, but they should be deleted and recreated.