You can see what I mean about the Parallels icon.

@jeff hammond said:

hey Steve
fwiw, the icons always look the same to me regardless of being created on mac or windows.
but then again, i don't have parallels installed (assuming you do?)

Hi Jeff,

Yes, I have Windows 7 installed under Parallels on my Mac, and I have SketchUp Make 2015 installed on Parallels. I use this to test whether plugins I write will work on both platforms. So that's where Mac OS got the icon from. What's weird is that Finder displays a Windows-originated skp with the Parallels version of the icon even if Parallels is not currently running, and double-click a skp from any source launches Mac SketchUp, not Parallels. Of course, I regard this as a Mac OS issue, not SketchUp.

Steve

@driven said:

the reason the two icons are different is Finder is trying to guess what the files are...
both contain binary and text
for the windows file it is being seen as a binary file
for the mac the text will have mac line endings and is being seen as a unknown text file

john

John, you may have enlightened me about a strange effect I have noticed on my Mac: when I download a skp that someone created on Windows, it displays with the SketchUp via Parallels icon instead of the native Mac icon - despite the fact that I have set Open With to use the Mac SketchUp and double-clicking it will open it natively on the Mac! Finder and open appear to have independent ideas!

Steve

LIke Dave, I'd do the end assemblies first, then the back assembly (separately), then add the front-to-back strut and front rail to the back assembly and finally attach the back+front rail to the ends.

Dominos are pretty precise, but I'd still test flat and square as Dave suggests to allow for any "user error". That can be a problem when attaching subassemblies since Dominos aren't all that tolerant of misalignment.

An assembly with a lot of Dominos that need to go home at the same time can be a real nuisance. It's tricky getting all of them into the slots at the same time, and frequently the fit is so tight that it won't push home without clamps. To ease things a bit, I do a couple of things. First, I make sure that the Dominos themselves are true thickness, either by drying them in a oven or by sanding/planing. Second, I shave off the little ridges on the edges, which makes them enter the slots more easily. Finally, I bevel the outward ends of the Dominos, which helps guide them into the slots.

First off, for reasons known only to Trimble, SketchUp on the Mac does not generate or display per-file custom icons. There have been some workarounds discussed on these forums, for instance

http://sketchucation.com/forums/viewtopic.php?t=16015

@driven also has an unpublished plugin to generate icons. You could PM him and request a copy for testing.

However, there may also be something off-kilter in your system. While there are not per-file icons, a .skp file should display in finder with the SketchUp app icon, not a blank page. You might try opening the Get Info panel and seeing what is set for "Open with".

Not knowing how you saved the Windows file, I can not hazard a guess at why it is showing that icon.

Out of curiosity, did you try showing hidden geometry to see whether that face was split by a non-visible line already?

@box said:

@jeff hammond said:

has an unsolved shape in which all the things which need to be known are known.. so,

There could be hidden unknowns or maybe known unknowns, perhaps even unknown unknowns that we either do or don't, may or may not, have known about whether we know about not knowing about them or not.

I don't know about that...

@jeff hammond said:

@slbaumgartner said:

For shapes with an odd number of corners more info is necessary, as there is no innate definition of "opposite corner".

right- once you've come up with a method, more info would be needed in the case of odd or multi numbered corners.. though i think the initial problem boils down to 'fit a rectangle between two angles".. the number of sides is irrelevant..

[attachment=0:qfxswsu7]<!-- ia0 -->Untitled.jpg<!-- ia0 -->[/attachment:qfxswsu7]

Right, but when you eliminate the full shape you have to provide more info to pin down the problem. You can move and rotate either corner without changing its angle!

For shapes with an odd number of corners more info is necessary, as there is no innate definition of "opposite corner".

Yes Frenchy, in general. But I took Jeff's challenge to mean that all sides and angles of the quadrilateral were fixed and known. I think you can get from here to there using the cosine rule and some algebra, but banging my head against the possibility of a purely geometric, non-trig solution first.

The old standby RUBY_PLATFORM won't work?

This looks like you need to update the plugin to a version compatible with Ruby 2.0.

@tig said:

BUT the whole idea is that it always returns 'nil' if it's not set.
Doesn't [] === nil
so then that's as expected ?
When you 'get_' an attribute you should always default it to be the base level result: nil, 0, 0.0, "", [], false and so on...
Then test for the 'class' of what's returned...
If you don't, then how do you know what's been returned ?

I believe in defensive programming, so don't get me wrong: you should always verify and/or default the return from get_.

nil is what is returned by get_ if you never assigned a value to a particular key and provided no default, but it should not be returned when SketchUp couldn't handle the value you happened to set! Transmuting [] into nil is wrong for multiple reasons. No, []===nil is false. Performing a test such as #empty? in case the Array wasn't populated will throw an Exception because nil is not an instance of the Array class.

Instead of converting [] into nil (or converting any other unsupported class instance to nil) the dictionary should raise an exception when you try to set the illegal value.

@eneroth3 said:

@tig said:

@eneroth3 said:

I just discovered empty arrays cannot be saved as attributes between sessions in SU 6-2015 (tested on windows 7). However it works just as expected within sessions o.0. Bug report has been submitted.
But of course your code can simply sidestep that with:
...get_attribute(dict, key, **[]**)
which will either return any array which the key has as its value, OR with your own [] as its default, e.g. when it is not setup OR empty, and you get nil otherwise...

Yea, it's really easy to work around it once you know about it.

I had run into the empty array problem earlier and I agree 100% with eneroth3. It is not hard to allow for this once you know about it, but there is no documentation anywhere that tells you that you need to. I wonder how many others have independently discovered this...

@jeff hammond said:

@slbaumgartner said:

However, it seems to me that this fixup should not be necessary. I think this could be considered a bug in follow me.

heh, careful about going down that rabbit hole
if you do, you'll realize sketchup as a whole is flawed and this 'bug' presents itself in many tools/scenarios.
[/attachment]

Agreed! There are some unavoidable or at least very difficult problems when everything is ultimately straight line segments and planar faces.

In this specific case the reason I view it is a bug is that a routine "intersect with" finds all of the missing edges quite readily. It seems like follow me quit while there was geometry remaining that it does know how to handle.

@pout said:

does anyone know if any of the remarks here will be taken into consideration in a new version?

The SketchUp development team are famous for marching to their own inscrutable set of priorities, so only they know for sure. But this topic was started by a member of the team, so it is at least as good a place as any for sketchUcation members to post suggestions.

If this issue is specific to that extruder, have you PM'd eneroth about it? The extension author should have a much clearer understanding of how it works than the rest of us!

@djh said:

@slbaumgartner said:

Your picture suggests that you have nested groups. Have you enabled receive shadows on all the levels of nesting? A nested object will not receive shadows if its containing group does not.

Sorry, I don't know what nesting is. All objects are on Layer0. I exploded all of the objects, but the shadows still don't appear on the objects.

As Dave has pointed out, it is possible that the file is corrupted. The following is meant to be tutorial, in reply to your statement that you don't know what nesting is, since if you don't understand that concept it is still possible it is the cause of your issue. For example, if you don't get the idea, "exploded all of the objects" might actually have left something intact.

"Nesting" is when you place or create a Group or ComponentInstance inside another Group or ComponentInstance. In your "still doesn't receive shadows" jpg, I see two different bounding boxes surrounding the selected Face, one around the corner panels and one around the rectangular group of corners (a room?). Due to the style I am not certain whether the panel on which the Face lies is also a Group. So, there could potentially be a Face nested in a panel Group nested in a corner Group nested in a room Group.

The importance in this particular case is that the settings on containers and the things they contain interact. Specifically, shadows won't be cast on the Face unless the flag is set correctly on each of those levels of nesting.

[edited to change "layers" to levels in the last sentence - poor choice of words since "layers" are a different thing]

@soldatino said:

thanks, this is not a model of mine, who did it drew partly in one way and partly in another. I was looking for a test of my format converters, but I think that if I wont to do a perfect job I also need to search the SU API that gives me information about the "normals" of the faces drawn that I must translate...

The confusion starts from the fact that I see contradictions, it is not easy to explain.
I isolated the glass and I'm sure.

• face.back_material.alpha - declare a value of low opacity for the "back" of the face, and it is exact because the face is designed relatively to this side, but has vertices in reverse order if we look at the truck from the outside.

But the same face on the window of colors of SU is shown with the back color on the left, as if it were the primary side of the face, that instead is completely opaque.

As you draw a Face, the ordering of the vertices ordinarily determines the orientation of the normal vector, hence the directions of "front" and "back". However, SketchUp sometimes flips the normal during its cleanup operations. For example, it will determinedly force the normal to point downward if you draw something on the z=0 plane. It will also flip normals to match where two Faces intersect. It will usually cause the normals to all point outward when you create a "solid". So, it always pays to check what you got and fix up any reversals, especially before doing things like applying translucent materials that can confuse the issue!

In ruby code it is not uncommon to have to test whether a normal came out the way you assumed. For example, a positive push-pull value goes in the direction of the normal vector. If SU set it opposite to what you assumed, your operation will also go opposite.

In the case of your converter, it seems to me that you can't make assumptions about what the creator of the original model intended. If they modeled a particular way, maybe that is what they meant!

@driven said:

@Steve, have you ever ran this on SU? https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Testing/Testing.html#//apple_ref/doc/uid/TP40012302-CH6-SW1
john

john,

I messed some with the Quartz debugging tool back when Fredo's view.draw_text was discovered to be too tiny on retina, but a) found no way to change what SU does in that method, and b) never thought it had anything to do with flaky cursors so didn't dig deep into that. The annoying thing is that the cursor issues though not infrequent are not consistently repeatable. Sometimes they happen, sometimes not...I've never detected a specific trigger.

Steve