Nice surprise to go away into the Ontario wilderness for a week's canoeing, and come back to find a problem has been raised and resolved without my doing anything. Thx, all!

Hi Dave R,

My understanding from this exchange is that the problem was related to Victor Hugo's plugin folder, but is there anything I should do to make this plugin more robust?

I've updated the plugin to allow the creation of a diagrid lamella roof, where the lamellas are co-planar, following brookefox's suggestion, and to add some error-checking and spinners on input. Updates are located with the original post.

Under some circumstances the upper surface of the lamella is not created properly, for reasons I still don't understand. The cutting instructions are correct, regardless.

I've corrected the plugin to reflect the very helpful community comments, and fix some minor errors in the way curved surfaces were being generated. Both the revised plugin and documentation are embedded in the original post to make them easier to find.
I'm still puzzling over a couple of issues. First is the odd failure of the intersect_with method in at least one circumstance. (Posted elsewhere http://forums.sketchucation.com/viewtopic.php?f=180&t=46714). This wipes out a couple of faces in a lamella, but is rare, and easy to fix manually. Second, the geometry is off by a small (< 1mm) amount in terms of the components not lining up exactly. It doesn't feel like a rounding error, so my calculations may be incorrect. Practically this is not significant.

Thx all, and TIG and Thomthom especially, for your advice.

I've been using intersect_with to find the intersection of a cylinder (a group) and a prism (another group), where the prism is skewed relative to the prism. In some, but not all, instances the method drops an edge. Here's a pic:

The intersection breaks when you try it manually as well -- easy to fix, but rather undermines the idea of a plug-in! I'm attaching an abbreviated model.

Any ideas??

Intersect problem.skp

I reinstalled SU and the problem went away, so it looks like TIG was correct. I'll have to check my backups to see what version of SU was running (it would have been current, though). The profile info was obsolete.

@tig said:

BUT
face.edges doesn't return a face, it does return an array of edges.
face=Sketchup.active_model.selection[0] #<Sketchup::Face:0xef75e64> face.edges [#<Sketchup::Edge:0xf0a8b10>, #<Sketchup::Edge:0xef75e78>, #<Sketchup::Edge:0xf0a8c28>]
or
face.edges.each{|e|puts e} #<Sketchup::Edge:0xf0a8b10> #<Sketchup::Edge:0xef75e78> #<Sketchup::Edge:0xf0a8c28> [#<Sketchup::Edge:0xf0a8b10>, #<Sketchup::Edge:0xef75e78>, #<Sketchup::Edge:0xf0a8c28>]
Are you using the standard Ruby Console ?
Do you have any other tools that might ill-advisedly mess with the base-classes like Sketchup::Face ?
Your installation is most likely 'broken'
Have you considered reinstalling ?

Yes, it's the standard Ruby Console.
No, I have no other tools that mess with the base-class.
I'll re-install and see what happens.
Thx for the feedback.

I can't figure this one out. Here's the output from the Ruby Console:

back
#Sketchup::Face:0x1cbbfe74
back.edges.each{|e| puts e}
#Sketchup::Edge:0x1cbc1850
#Sketchup::Edge:0x1cbc1a1c
#Sketchup::Face:0x1cbcfc84
#Sketchup::Edge:0x1cbc0cc0
[#Sketchup::Edge:0x1cbc1850, #Sketchup::Edge:0x1cbc1a1c, #Sketchup::Face:0x1cbcfc84, #Sketchup::Edge:0x1cbc0cc0]

How can the .edges method return a Face?

@tig said:

A hand built component always has its axes at the bottom left of the component's bounding box.
You can of course change it at the time of creation or later on using the context-menu.
A group is similarly axis-ed but there is no adjustment to the axes manually later...
To use code to change e.g. a group's axes you need to work out the transformation needed to move the group back to the model-axes, oriented as desired, and then apply the same transformation.inverse to the group.entities so the contents are moved back to where they appeared in the model before, but of course the group#s axes [aka its insertion-point] might well be in a different place and/or the group itself might be rotated in 3d too...

Thx, Tig -- this is helpful. But what does "hand built" mean? The example I cited was a component built in code. Contrast this example:

` ents = model.entities

Build a parallelogram centred on the origin

a = ents.add_line([-75,-25,0],[25,-25,0])
b = ents.add_line([25,-25,0],[75,25,0])
c = ents.add_line([75,25,0],[-25,25,0])
d = ents.add_line([-25,25,0],[-75,-25,0])
d.find_faces
shape = ents.add_group(d.all_connected)
shape_as_component = shape.to_component
shapedef = shape_as_component.definition
dummy = Geom::Transformation.new()
ents.add_instance(shapedef,dummy)`

Here the new instance is located with its corner at the origin, not overlaying the original. Hence my confusion.

I was hoping this discussion might resolve an issue I've been wrestling with. I created a group at some odd angle and position in a model, and then turned it into a component (group.to_component). When I created a new instance using an identity transformation it showed up in the same place (which is what I wanted).

brace = brace.to_component
braces = ents.add_group()
dummy = Geom::Transformation.new()
braces.entities.add_instance(brace.definition,dummy)

In this case the component instance and the component definition seem to be in the same place

brace.bounds.corner(0)
Point3d(-94.3149, -12.7862, -48.5601)
brace.definition.bounds.corner(0)
Point3d(-94.3149, -12.7862, -48.5601)

But in another example I have a component created the same way, but the component origin (i.e., the corner of the boundingbox is relocated to [0,0,0]. In this case a new instance is created at the origin, using an identity transformation. How does SU decide, when it creates a component, where to place the origin of the component definition?