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.

I believe what you are seeing is a consequence of the way SketchUp exports true circular arcs to a 3D dxf whereas the edge in the SketchUp model intersects one of the arc segments away from the true circle. This happens when the point of intersection is not an endpoint of one of the original (equal-length) edges that SketchUp uses to represent an arc or circle because only those endpoint vertices are on the true circle. You could try my Circle Intersect extension to show guide points where edges or other arcs intersect true mathematical circles vs SketchUp's segmented representation.

Often this is due to a misbehaving extension. Try turning off all your extensions in the Extension Manager and see if the problem continues. If not, start enabling them half at a time until the issue reappears to isolate the offender.

We've been trying to get 3DConnexion to acknowledge and fix this issue for years, but so far no luck! It doesn't happen to everyone and doesn't happen every time. There's been a topic on the Trimble SketchUp forum where simoncbevans found that if he disabled the MacOS firewall while installing the driver and then turned it back on afterward that his device started to behave. I tried that, and for me the results are still erratic: many times SketchUp will work just fine, and then suddenly for no obvious reason the memory blows up again.

@m_mortenttt said:

with command "qlmanage -m plugins | grep skp" or "qlmanage -m plugins | grep Sketch" not reset icon to show quicklook. Just with command "qlmanage -r" can reset and show correctly quicklook, but it's for a moment.

It's ok. Thanks for try to help
I hope someone else can help me, or new MacOS Mojave can fix the problem. Thanks

No, those commands won't fix or reset anything, they can just help diagnose what is going on.

That's the right quicklook handler. Was it displaying correctly when you ran that command? If so, try again when it has failed. Could be something is stealing the URI from SketchUp's handler.

Here's another command to try, that looks a bit wider:

qlmanage -m plugins | grep Sketch

That should return a bunch of URI's that the handler is set for. If any of them point elsewhere than what you got above, that could be the problem.

Beyond that, I have no idea what is happening. Sorry!

There have been numerous bug fixes and improvements between SketchUp 8 and SketchUp Make 2017. Among these are changes in the Ruby API that may cause some plugins/extensions to fail. But any plugin author who is still active will have updated their code to handle the changes, so it is not usual to be unable to find a plugin revision that will work in 2017. In fact, it is becoming more common to find extensions that the authors no longer support SU 8 due to these changes!

Most strange! I've never seen that myself. I wonder if there are multiple quicklook handlers registered against the skp file extension?

For starters, you should use 'qlmanage -r cache' to force rebuilding of the quicklook cache. Just 'qlmanage -r' rebuilds the list of generators, but I'm not sure whether it flushes the cache too. You might also try 'qmanage -m plugins | grep skp' so see what is registered to handle skp.

I'm not sure if I understand your request correctly, but you should be aware that internally SketchUp always stores all measurements in inches, even if your visible units from model_info->units are metric. The units setting just determines how SketchUp formats the measurements for display (and input) in the GUI.

The heavy lines at the right in your image look like profiles. I'd start by looking carefully around there for gaps, non-coplanar, and similar issues. Drawing diagonals between corners is a good way to zero in on problems because a triangle always forms a face (three points are always coplanar), so failure means there is something wrong in the boundary that should have formed a triangle.

@pilou said:

Now you can attack the Circle quadrature!

Nah, that would be too easy

I have just posted a new extension (SB Trilateration) to solve both 2D and 3D trilateration problems in SketchUp using precise (true) math of circles and spheres and without requiring the user to first draw circles or spheres in the model.

That sort of thing is done with a Transformation. Look up Transformation in the SketchUp Ruby API documentation.

Also please clarify which two faces you are referring to.

You can convert png or jpg to svg or pdf, but since the content is a raster image it most likely won't look good when scaled. The contents need to be vector to scale cleanly.

@pixero said:

Question. Does the svg/PDF icons need to be made in a special size? (I know they are scaleable just wondering if the dokument size should be anything special.)

You can draw the icon artwork at whatever size you wish. The view of the contents will be scaled to fit the available space in the toolbar button, so the physical size you drew is irrelevant. But you do need to verify that you haven't put details into the artwork that won't be visible when scaled to a typical toolbar button on a particular size display. Since you probably don't have a lot of different displays available to test, the best practice is to keep your icons fairly simple.

One precaution though: Whatever size you draw, you should keep the drawing canvas square. Otherwise SketchUp will scale it based on the larger dimension and it won't fill the full button in the other direction.

@bob james said:

Thank you, slbaumgartner
Would you tell me how to use this for each plugin extension?

If you're not familiar with Ruby API programming for SketchUp, you might be in over your head as the code needs to be adapted to each specific extension, there is no universal drop-in-place form.

You need to create the appropriate icon files (svg, pdf, and png) for the extension and put them in the extension's folder. Then you need to find where in the extension's code it creates and populates its toolbar and integrate my snippet with whatever the original code does there, which will almost surely vary from case to case.