Taking another look, there is a deeper issue in addition to the Gatekeeper quarantine: the extension's code is attempting to load a Ruby 2.0.0 library from the Frameworks distributed with SketchUp, but SketchUp 2018 does not contain such a library, it has Ruby 2.2.0. So even if you figure out the quarantine thing, this extension isn't going to work under SU 2018!

A slow plugin is certainly a possibility. Do you have the same suite loaded on both machines? Any differences would be the place to start looking.

SketchUp itself does not provide any log of extension load times, so unless the author has programmed something (as Fredo6 does) there is nothing to help you other than trial and error.

Please see your other post on the same subject.

After you opened the grass for edit, did you select its surfaces? Intersect Faces With has to have a set of Faces to intersect!

Your dropbox files are gone, so I can't comment on them. Did you submit the BugSplats having filled in the fields for info about yourself? If so, someone at Trimble will take a look and let you know if this is a known bug or, for example, an issue with some extension. Be patient - they get enough splat reports that sometimes a reply takes a while.

Not clear from your post: did you remove the quarantine on the installer, or on the SketchUp app after installing it? You need to do the latter. A fresh reinstall may just set the flag on SketchUp.app again!

That is the attribute that remembers the quarantine, so yes, that is one of the ways to fix it.

You are falling victim to a Gatekeeper security feature (application translocation) that was added in macOS Sierra. It happens when an app is quarantined by Gatekeeper because it is was downloaded from the internet. Some people had problems with this shortly after Sierra came out, but the installer dmg for SketchUp 2018 should be ok. How did you obtain and install SU 2018? You might try deleting the app and reinstalling from a fresh download of the dmg. That will not lose extensions/plugins etc that you have now.

@hornoxx said:

@box said:

...you have hit control while orbiting which has tilted your workspace...
an other D'oh! moment for me didn't know this tilting is even possible so

This feature is often overlooked. SketchUp by default implements a notion of "gravity" that keeps the horizon level across the width of your view - even if sky and ground visibility are turned off so there is no horizon literally visible. Especially with architectural models, this avoids strange and confusing off-level motion. But by pressing control (option on mac) you can temporarily suspend gravity to get a free rotation during orbit.

@bagtoshop said:

ok but when i click on the left arrow to aligan it to the green axes this is what
looks like. do you think its parallel to the green one ? i dont think so

Yes, it is parallel to the green axis. It looks that way in the view because you have the horizon visible (as proved by visibility of the "end" of the green axis) and perspective camera. In perspective, parallel lines appear to converge toward the horizon. Orbit so that you are looking down at the red-green plane and you will see that the line is actually parallel to green axis. You may have to click on the below to see the animation.

I don't think there is a one-size-fits-all answer, as there are many ways a dwf file can need fixup after import. Extensions such as CleanUp3 work using various criteria to decide, for example, whether two lines that don't quite meet should have met, or if a collection of line segments really should have been one longer line, etc. You can try various choices of these parameters and see whether you can find ones that produce better results. For instance, deleting everything suggests that all the edges in the model are shorter than what is considered too small.

You may need to backtrack all the way to the PDF and look for ways to tidy and/or simplify things there. You might be able to break it into pieces and work on them separately in SketchUp.

Then take a look at PDF Grabber to see whether it has parameters you can set to control its output (I don't use it, I have no idea...).

Expanding on what Dave wrote:

SketchUp displays lengths according to the units you have set in the model info window. If your choice does not have enough precision to present a particular length perfectly, SketchUp displays the closest value allowed by your choice and prefixes it with "~" to let you know that the value shown is an approximation of the true value. It is important to realize this is an aspect of presenting values on the GUI, it does not mean the value isn't stored correctly inside SketchUp. Also, it is a one-way street: you can't enter a "~" prefix when you type a value.

For example, if you set units to decimal meters with 0.0 precision, the value 0.123m can't be fully displayed even if that is the exact length of the entity in the SketchUp model. It will be "~ 0.1m" even though SketchUp internally has the correct 0.123m value. Similarly, if you set fractional inches with 1/2 inch precision, 3/8 inch will display as "~ 1/2" because that's the closest value that can be displayed.

I think @alpro likely has the answer. If the camera is perspective, rays of view diverge into the model, and this can cause the sides of objects to be visible except exactly along the center of the view.

The error message is saying that the interpreter parsed the text "for count1 in 0..5" and didn't find a line ending that it could understand. It wanted "do", ";", or "\n" (LF) and got something else. The fact that it works in 2015 suggests to me that this is an issue with the Ruby version embedded in SketchUp. Before SketchUp 2014 it was a variant of Ruby 1.8. As of 2014 it changed to Ruby 1.9 and since to successive versions of Ruby 2.x. One of the most important parts of the change was to require unicode character encoding. At least one of your screens suggests your computer locale is Russia? If so, your computer may be feeding unicode line endings that the older Ruby versions don't understand.

@rombout said:

Not sure whats happening, but removed all other. put them back restart and now it seems to work again... weird stuff

Recent versions of OS X cache both plists and the qlmanage settings. You often need to force them to refresh their caches to get things to "stick", especially if an affected app is open at the time. To force refresh of the preferences cache you can either log off and back on, reboot, or issue "killall cfprefsd" in the Terminal. To force refresh of the quick looks, do "qlmanage -r".

@rombout said:

Heavy models do take super long to save, is that due to jpg creation?

Heavy models can take a long time to save even without the jpg generation, but yes it will slow the save even more. You could get a sense of the impact by exporting the model as a 800x600 2D jpeg image, which is essentially what the plugin does.

@rombout said:

I got it working by changing the plist file

I looked some more, and it seems that SketchUp's own plist files affect what CFBundleDocumentTypes are initially registered for skp files. At some point they went from just com.sketchup to com.sketchup.skp, which necessitates the change you made in my plist.

I don't know why it stopped working. It is possible that Apple changed something in releases of OS X since I wrote my qlgenerator or that subsequent versions of SketchUp associate the skp files with a different system id. There was so little interest expressed at the time that I haven't bothered to maintain it. I've since moved on to macOS 10.13.2, which might also behave differently than your OS. Plus, SketchUp 2018 comes with its own new qlgenerator, which eliminates the need for mine going forward. That said, you could try the ideas below to investigate.

You are using the wrong pattern in grep to search the return from qlmanage. Try qlmanage -m | grep Ske instead and you should see what is handling SketchUp files. If my qlgenerator is correctly installed, you should see entries for dyn.ah62d4rv4ge81g45u and com.sketchup. I had to use these because at the time SketchUp itself wasn't registering anything. The icons will take effect only after you save a file while the plugin is installed, as the plugin is what creates the image used by the icon.

It's been long enough I may have forgotten, but I don't think qlgenerators can be run standalone from the Terminal. They hook into a calling chain where they are fed a file and return an image handle, which doesn't make sense standalone.

You might also check for a folder named .QL_SketchUp in your home folder (things starting with . are hidden by default - in terminal you need to use ls -a to see them). It should exist, be writable, and should contain an image for each skp you have saved since the plugin was installed.

Check your system's log files to see whether you can find anything about quick look errors. Because OS X creates vast numbers of log messages about things that will mean nothing to you, this is somewhat like looking for a needle in a haystack but if you find something it might provide a clue about why it is no longer working.

I downloaded the GroupByLayer.rb from Smustard and looked at the code. It would actually be quite easy to modify it to apply the layer name to each of the groups it creates (and also to bring it in line with modern coding practices which it badly violates - it hasn't been updated since 2006!), but the Smustard general EULA expressly forbids altering any downloaded files and the extension's source code does not provide a more lenient license. I don't know how to contact the author, Rick Wilson, as he doesn't provide any info in the source. But if you can reach him, he might be able/willing to make this simple change or to grant permission for someone else to make it.

I started playing with this question as an exercise of Ruby API programming. On the surface, it is pretty easy to do. But when you look closer, the question is an excellent illustration of why the standard advice is to leave all edges and faces referencing Layer0. In this model, none of the edges and faces do so, and this causes issues in the attempt to convert geometry into groups or components! I realize the abuse is a result of the way the model was constructed in CAD before import, but nonetheless it shows the kind of things that happen.

To be more specific, an edge or face can reference only one layer. When, as in your model, the layers have been employed to identify objects, wherever two such objects touch their shared edges and faces can reference only the layer for one or the other object. So, if you turn off visibility for all except one layer, you get strange effects as shown in the attached images, where edges are missing from the faces they border and faces are missing from what should be a continuous surface. The geometry that references a particular layer does not form a SketchUp solid! This happens because the associated edge or face references a different layer than the one for the rest of the object.

In this specific context, it means that it is much more complex for a conversion tool to find and fix these defects while creating groups or components from the geometry that references a particular layer. Every object will have missing edges and/or faces as illustrated (because they all touch at least one other object), and the tool would have to understand this to find and collect copies of the missing parts into the assembly for each object.