@johnwmcc said:

Sorry I didn't make myself clearer. I'm coding in Ruby. I use the InputPoint.pick method and when I click on a face, it reports via the InputPoint.face method (@ip1.face in the code sample in the onLButtonClick method) whether it has clicked on a face, and if so, which face. But it doesn't say whether it is a 'loose geometry' face, inside a group, or inside a component.

And the reported face.normal differs between a face in a component, and one thas is in a group or loose.

The thing I found (and still find) very confusing is that the reported normal for a face in a rotated component is not the normal to the geometrical face. What is is reported by the .normal method seems by experiment to be the normal to where the face was in World coordinates in the original ComponentDefinition for an un-rotated component. But I suppose on reflection that it is the normal (the Y-axis) in the ComponentInstance's own coordinate system. But I didn't originally see it that way.

I have now worked out how deal with it, by first detecting if the face.parent object is a ComponentDefinition (which equally applies to a Component or a Group), then checking if face.parent.group? is true to see if it is a group, and so not a ComponentInstance) but it seemed originally more complicated and confused me for several hours while I figured out where I needed either the reported World Coordinate normal vector, or the component instance coordinate normal vector.

I believe that what has confused you is that a ComponentInstance does not actually own any entities. Instead, they are all owned by its ComponentDefinition. The things you see in the model view are transformed representations of those entities, not separate objects. That's why when you edit a ComponentInstance the change is instantly repeated in all the other instances of the same ComponentDefinition no matter where they are placed or how they are rotated.

So, when your InputPoint pick finds a Face within a ComponentInstance, the object it returns is actually the original in the associated ComponentDefinition, and the normal to that Face is the normal in the ComponentDefinition's coordinates, not in global model coordinates. You need to transform it back to global coordinates to get the version corresponding to the ComponentInstance you clicked. That is why InputPoint also has a #transformation method to retrieve the transformation associated with whatever it found. This Transformation is an identity if the object is free geometry or in a Group, and is the ComponentInstance's transformation if the object is from one.

So, no offense intended, but the only bug was in your understanding

@johnwmcc said:

Thanks for the pointer. I'll look in a day or two - too late tonight/this morning, it's Christmas Day.

I know I'm just using the Face.normal method on a picked face which is in a (closed) component. I guess Chris probably is too.

Oddly, I don't get the same behaviour when the face is in a group - his tool works as I'd expect on a face that's in a group.

I could see how to correct for this, but can't quite work out how to tell if the face is 'loose geometry', in a group, or in a component. I'll get there soon, I think, with some combination of
if face.parent.is_a? Sketchup::ComponentDefinition, and if not face.parent.group?, and error trapping

Question: how do you pick a face inside a closed component (I know how to find things inside closed components using Ruby, but you seem to imply you are doing that via the GUI)? A click on that component should select the component, not a face, regardless of how the component and is axes are oriented. I must be missing something in your description of what you are doing...

On the other hand, if you are doing this all via Ruby, I think that sdmitch has posted the fix in the developer's forum thread you reference. There is no bug - you (and possibly Chris also) simply overlooked the need to transform the normal back to the model's global coordinates.

Steve

@pgarmyn said:

@driven said:

what does it return if you add an additional /

puts File.writable? ENV["HOME"]+"/Documents/"

both variants return true on a mac...

Both false on my Win 8.1

My experience is that 'Documents' is the exception on Windows.
For other folders, the value is consistenly.

Could this be related to the "shims" that recent versions of Windows use to fake some folders?

I agree that it sounds like your installation is somehow broken. But I'd go the other direction and try upgrading to SU 2015 unless you either can't stand Yosemite or require Pro and can't afford the SU upgrade. SU versions before 2015 are not supported on Yosemite (there are some known issues with fonts that cause crashes). Also, SketchUp on Mac has always come with its own Ruby framework embedded inside the app bundle - I don't think it cares what the system has installed.

@driven said:

@slbaumgartner said:

...I hesitate to present it here because it involves modifying files within the SketchUp app bundle.

I'm less hesitant, as I believe that you can modify your own copy to make it 'fit for use'...

I agree. I am hesitant because I don't want to be responsible for people who don't quite know what they are doing ending up trashing their installation of SketchUp. This is the newbie forum after all

@jonatangc said:

Yes, I have the retina 5k display.
I'll look it up, thanks!

This is an ongoing problem with all high-dpi monitors, including not just Macs but some high-end Windows boxes (note: the issue is when there are a lot of pixels per inch, not just when there are a lot of pixels across the screen). Trimble is aware of it, but at this time there is no setting and no built-in mechanism to do anything about it.

A few of us are experimenting with a workaround on Mac, but I hesitate to present it here because it involves modifying files within the SketchUp app bundle. At this time there is no known workaround on Windows.

Sorry...

The core issue here is to realize that there is a difference between the ordering in which items are stored in a Ruby container as they are added (which may be seemingly random - e.g. in a hash - or may be based on some optimization of the internal structure) vs the order in which they are presented by some UI or processed by code. If the order matters for the latter purposes, you should create an Array using #to_a and then sort the Array using whatever ordering rule you like.

@tt_su said:

Why do you need to rename all the other components to place a new component?

I'd bet that the numeric prefix has external ordering significance (like number 053 has some relation to 054) so the existing higher numbered parts have to be pushed up when a new one is inserted into the list.

I find it interesting that model#save includes an argument to tell SketchUp what format to use when saving a model, but like @glro I can find no method to determine either the format that was in effect when the file was opened nor the format used the last time it was saved. Obviously, the data needs to be in the correct form for the running version of SketchUp while in memory, but if it can be converted on load and save, shouldn't the API remember these things?

I seriously doubt you could add a column that is not already supported by the operating system, any more than you can add your own ad-hoc column in the Windows Explorer.

Also, there are various plugins available on the SCF store that will fix a model by moving all the raw geometry back to layer 0.

@massimo said:

Raw geometry means everything not in a group or component.

To further clarify, putting geometry into a group or component does not change the need to keep the geometry on layer 0. It is the group or component as a container/parent/context that you can put on another layer. Its contents stay on layer 0. If you open the group or component for edit, you must still draw all new geometry on layer 0.

@john2 said:

@box said:

Do you realise that is thousands of meters across, full of hidden layers, and has raw geometry on layers other than Layer0? Had me confused as the model units are set to mm and 0 precision.

raw geometry on other layers is dangerous?

Absolutely! The sure road to confusion and frustration. Put components and groups on other layers, but never never draw or move raw geometry anywhere but layer 0. This can be a problem with models imported from other CAD programs, where layers have a different meaning than in SketchUp.

You need to read up on how geometry attaches to other geometry unless you create components or groups. SketchUp can't figure out how to move that face because it is attached to other surfaces.

@driven said:

have you looked for UTM data import ruby's?
I think at least one already does what you ask...
may be this one...
http://sketchucation.com/forums/viewtopic.php?f=323%26amp;t=1533
john

I took a look at this ruby and couldn't see anything that would directly facilitate drawing far away from the origin while using UTM coordinates. The references I found all talked about pre-processing a file of UTM by subtracting the coordinates of a "site origin" before importing values into SketchUp via the Cloud plugin.

It's not hard to set the model origin in UTM via Ruby:

    utm=Geom;;UTM.new(zone_number, zone_letter, x, y)
    latlong = utm.to_latlong
    shadow_info = Sketchup.active_model.shadow_info
    shadow_info["Latitude"] = latlong.latitude
    shadow_info["Longitude"]= latlong.longitude

note: zone_letter is actually a single-character string
another note: Most of the shadow info is automatically recalculated when you set the latitude and longitude, but shadow_info["City"] defaults to "Boulder (CO)" and shadow_info["Country"] to "USA", so if you set the origin you probably want to set those also!

once the origin is set, you can get individual point locations in model coordinates from UTM via

model = Sketchup.active_model
 utm = Geom;;UTM.new(zone_number, zone_letter, x, y)
 point = model.utm_to_point(utm)

then use those points to draw whatever you wish

A model with similar peculiarities was discussed not long ago somewhere (dang old age, I can't remember where...). Component Definitions had become detached from the model's collection yet still existed. Weird jumps occurred when the instances were opened for edit. Lots of people could get the problem if they opened the file, but could not create another example. There is a hole somewhere, but as Dave says, those who step in it usually can't recall how they got there!

See this topic for some discussion of what can go wrong at the opposite extreme of values larger than SketchUp was designed to handle:

http://sketchucation.com/forums/viewtopic.php?f=79%26amp;t=60229

On re-reading your post, I think I see the problem. SketchUp was designed for architectural-sized drawing, not for UTM zone-sized geography. So, when you draw using the UTM coordinates, you are drawing relative to the origin of that zone, which can be very far away from the objects you are drawing. Using SketchUp's geolocation capabilities (look in the knowledge base or tutorials) you can put the drawing origin of your model at any place on the earth. Then you draw relative to that reference location instead of relative to the UTM origin.

Not denying that there may be a limit of precision thing going on, but there seems to be some confusion here too. If you haven't geolocated your model, the "origin" is an abstract drawing location with no real world significance. It is not, for example, your own physical location. So, offsetting from it by some real-world distance isn't meaningful. What do you think the coordinates (0,0,0) correspond to?

On the other hand, if you have geolocated your model, why did you place the origin so far away from where you want to draw? Are you planning to fill the entire space between with drawings?

Definitely a matter of how the system renders the given Unicode character using the available font.