@thomthom said:

No - I wondered if it preserved it.
I wanted to only move and rotate the object to a new plane. I wondered if this method would be an option as oppose to combining a translation and two rotation transformations.

Well, first you have to determine which axis gets priority (because the angles between the axes in the original transformation may not be the same as the angles between the axes the user picked) then measure the angles between the prioritized axis and the other two, and apply the angles to the user axes (including face normal).

I'm pretty sure that doesn't make sense but I can't think of how else to describe it.
If you have any specific questions, I might be able to help a bit more.

Do you want the transformation to have the same properties as the original(skew, scale, etc.) in the final result, or are you asking how to prevent skewing?

If you don't care about scale, this should work fine, although it may flip the car upside down if the expected z axis does not correspond with the input axes:
instance.transformation = Geom::Transformation.new(newOrigin,newXAxis,newYaxis)

I would suggest using something like this (untested):

trans = instance.transformation
scales = [trans.xaxis.length,trans.yaxis.length,trans.zaxis.length]
inputX.normalize!
inputY.normalize!
inputX = inputX * scales[0]
inputY = inputY * scales[1]
newTrans = Geom;;Transformation.axes(newOrigin,inputX,inputY,face.normal * scales[2])
instance.transformation = newTrans

I'm pretty sure it is the same as .axes, but it crosses the Z axis automatically.

Can you tell us what you are trying to do in particular, or are you just curious?

@dan rathbun said:

If you attempt to use Ruby's system(), IO.popen or shell %x(*command string*) (ie, the Kernel 'dot' backquote method,) .. Ruby cannot continue until the call returns, because they create subprocesses.

For at least IO.popen, ruby will continue until you start reading on the pipe, although I have a feeling I took your statement out of context.

there is also a "ShowOnStartup" key under the WelcomeDialog folder in the registry.
EDIT: Nevermind, I should have read the full post.

As far as I've seen, the order of selection is the same as the order in the entities list (order of creation).

@unknownuser said:

I have tested it on SU Pro 7.1.6860 Win without a single plugin and it gives INT.
Same in SU6 Free Win.
Why our results are different?

That's weird. When I just put the face in edit mode, I get a result consistent with Tomasz's, but when I explode the 2 components, I get the same result as TIG.

EDIT: I should also note that the face renders smoothed when I just put it in edit mode, but renders normally when I explode it.

I haven't worked with Dynamic components much, and only have the free version, but wouldn't something like this work?
=smallest(largest(LenX,LenY),largest(LenY,LenZ),largest(LenX,LenZ))

I'm not sure if you need this anymore, but here is a method that should only return the intersected bounds:

def intersect(boundingBox1,boundingBox2)
	newBoundingBox = Geom;;BoundingBox.new
	bounds1 = [boundingBox1.min.to_a,boundingBox1.max.to_a]
	bounds2 = [boundingBox2.min.to_a,boundingBox2.max.to_a]
	intersectBounds = [[0,0,0],[0,0,0]]
	
	validBounds = true
	(0...3).each do |index|
		if(bounds1[1][index] <= bounds2[1][index])
			intersectBounds[1][index] = bounds1[1][index]
		else
			intersectBounds[1][index] = bounds2[1][index]
		end
		
		if(bounds1[0][index] >= bounds2[0][index])
			intersectBounds[0][index] = bounds1[0][index]
		else
			intersectBounds[0][index] = bounds2[0][index]
		end
		
		if(intersectBounds[0][index] > intersectBounds[1][index])
			validBounds = false
		end
	end
	
	if(validBounds)
		newBoundingBox.add(intersectBounds)
	end
	return newBoundingBox
end

It doesn't have any error checking, so you might want to modify it if you use it.

EDIT: Fixed

@tig said:

OR any single ' entities' set - e.g. definition.entities.add_group(entities_already_in_the_definition_entities)

but then you have to explode it right away (at least that's what it sounded like). If you only use active_entities, you can create it without having to worry about exploding it or bug-splatting SketchUp.

@tig said:

@thomthom said:

I thought adding existing geometry to groups made SU go rampage and bugsplat?

It does, BUT NOT if you make, copy and explode the group immediately - many of my tools use this method without issues. It will Bugsplat if you try and do too much with these grouping, and especially if you try and group entities across sets - try and see -it won't splat...

PS: The advantage of this method is that the face's material[s], layer and attributes are kept automatically.

.add_group(entities) should work fine as long as the entities are from model.active_entities.

if you have the group to model transformation, you can create a new bounding box, then add the face's vertices to it.

something like this:(untested)

bbox = Geom;;BoundingBox.new
points = face.vertices.collect{|vertex| vertex.position.transform(toModelTransformation)}
points.each{|point| bbox.add(point)}

This will still give a bounding box larger than the face if you don't have the face perfectly aligned with the global axes, though.

I'm not sure if you noticed this, but 2540 squared equals 6451600. That might explain the result.
I don't know why it omitted the last two zeros, though.

@tig said:

There seems to be no [working] method for '==' for comparing Colors: but c1.to_s==c2.to_s does return true if they have the same rgb values...

c1.to_a == c2.to_a works too.

if you have x and y vectors:
model2plane = Geom::Transformation.axes(point,x,y,normal).inverse (untested)

otherwise you can either use vector.cross if you have one vector, or vector.axes if you have neither.

I wonder what the insertion_point= is for.

EDIT:

@thomthom said:

@cjthompson said:

I wonder what the insertion_point= is for.

Was this intended for another thread: http://forums.sketchucation.com/viewtopic.php?f=180&t=28450

Yeah, I think I had multiple tabs open and responded to the wrong one. sorry about that.

it's basically the where the origin is at in the context of the definition.

normally it will always be [0,0,0], but will change to the edit_transform.origin if one of it's instances is in edit mode.

EDIT: it is the last point the user grabbed, not the origin. (see below)

@chris fullmer said:

Its not quite clear to me what the 3rd step is. I can't follow the progression from 2 to three I guess.

To add on to Chris's post, what is the purpose of the Call class?

if possible, could you do a fairly simple psuedo-code of your current algorithm?

@dan rathbun said:

@aidus said:

I need 64 bit support

This topic is about using Ruby "Green" threads, not native OS threads (which can run on several CPU cores.)

Ruby ver 2.0 "may" have native thread support, but current estimates of the work to be done, has 2.0 needing 17 years more work.

I thought 1.9 had basic support for native threads, but Sketchup can't connect to its hooks.