Aye! If you are dealing with vertices, and you create a bug where you mix up your vertex references you might not notice it immediately as this method happily returns the first vertex in the edge which isn't the one pass in the argument. Garbage in - garbage out.

Glad it helped. I spend a loong time on that - I just couldn't warp my head around what was going on. The key was the quote from the Wiki article. Everything makes so much more sense now. Figured I'd post it here to remind myself.

<span class="syntaxdefault"><br />model </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> Sketchup</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">active_model<br /><br />modeltime </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> model</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">shadow_info</span><span class="syntaxkeyword">[</span><span class="syntaxstring">'ShadowTime'</span><span class="syntaxkeyword">]<br /></span><span class="syntaxdefault">unless modeltime</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">utc</span><span class="syntaxkeyword">?<br /></span><span class="syntaxdefault">  time </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> model</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">shadow_info</span><span class="syntaxkeyword">[</span><span class="syntaxstring">'ShadowTime'</span><span class="syntaxkeyword">].</span><span class="syntaxdefault">getutc<br />  tz_offset </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> model</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">shadow_info</span><span class="syntaxkeyword">[</span><span class="syntaxstring">'TZOffset'</span><span class="syntaxkeyword">]</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">*</span><span class="syntaxdefault"> 60 </span><span class="syntaxkeyword">*</span><span class="syntaxdefault"> 60&nbsp;</span><span class="syntaxkeyword">/&nbsp;-</span><span class="syntaxdefault">1<br />  modeltime </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> Time</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">at</span><span class="syntaxkeyword">(</span><span class="syntaxdefault"> time</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">to_i </span><span class="syntaxkeyword">+</span><span class="syntaxdefault"> tz_offset </span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">end<br /></span>

It worked for me after I moved it all to another place in the space, randomly , not specifically to any place . I thought it could give you a clue . Thanks for answering .

Coplanar things only intersect if "intersect selected" is chosen. You cannot (obviously) select all inside the group context AND outside of it. Try with this file (created in version 6 where "auto intersect" was not introduced). Select all and perform an intersect with model. Nothing happens. Now select all and intersect with selected: it will intersect the two rectangles. intersect.skp

Got sidetracked by another project. Undetermined yet.

@eneroth3 said: This seems like a documentation error. However when re-selecting a tool the deactivate and activate methods seems to be called right after each other so maybe comparing a timestamp can be used to detect when a tool is re-activated. That's what I do, including for simulating a double-click on icon. However, you cannot avoid the calls to activate() and deactivate(), just shortcut them. I just realize that, should Trimble fix this issue, there could be some regression in my scripts, because I only test status 0. Fredo

@thomthom said: [attachment=3:2l5lnglv]<!-- ia3 -->FrontDoor.png<!-- ia3 -->[/attachment:2l5lnglv] I'll bring home some tracing paper today and sketch out where I think the control loops will go. I've had a go at the mesh for the door indents, following something I saw last night. see Tileable Triangle Inset - http://imgur.com/a/dEWXP [image: irHcF.png] The indent on the door panel appears to be raised above the door panel itself slightly. Here is my try - following the above method. This is with SU16 Make. [image: 4kHb_doorindent-mesh.png] [image: apMO_doorindent1-subD.png] SU file ; SubD test

@chris fullmer said: Could have been part of the godaddy.com hacking. http://it.slashdot.org/story/12/09/11/1747225/go-daddy-network-issues-not-hacks-or-ddos-caused-downtime

@dan rathbun said: I remember trying this a long time ago.. but did not get it working. Maybe I used it wrong? I do have it working for a large project I'm working on. I set up some of the mixing modules and base classes to autoload. <span class="syntaxdefault"><br />&nbsp;&nbsp;</span><span class="syntaxcomment">#&nbsp;Ensure&nbsp;abstract&nbsp;classes&nbsp;are&nbsp;loaded&nbsp;and&nbsp;found&nbsp;when&nbsp;needed.<br />&nbsp;&nbsp;</span><span class="syntaxdefault">autoload</span><span class="syntaxkeyword">(&nbsp;;</span><span class="syntaxdefault">Observable</span><span class="syntaxkeyword">,&nbsp;&nbsp;&nbsp;</span><span class="syntaxdefault">File</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">join</span><span class="syntaxkeyword">(&nbsp;</span><span class="syntaxdefault">PATH</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxstring">'observable.rb'&nbsp;</span><span class="syntaxkeyword">)&nbsp;)<br />&nbsp;&nbsp;</span><span class="syntaxdefault">autoload</span><span class="syntaxkeyword">(&nbsp;;</span><span class="syntaxdefault">BezierEntity</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">File</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">join</span><span class="syntaxkeyword">(&nbsp;</span><span class="syntaxdefault">PATH</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxstring">'bezier_entity.rb'&nbsp;</span><span class="syntaxkeyword">)&nbsp;)<br />&nbsp;&nbsp;</span><span class="syntaxdefault">autoload</span><span class="syntaxkeyword">(&nbsp;;</span><span class="syntaxdefault">BezierPatch</span><span class="syntaxkeyword">,&nbsp;&nbsp;</span><span class="syntaxdefault">File</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">join</span><span class="syntaxkeyword">(&nbsp;</span><span class="syntaxdefault">PATH</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxstring">'bezier_patch.rb'&nbsp;</span><span class="syntaxkeyword">)&nbsp;)<br />&nbsp;</span><span class="syntaxdefault"></span>

I note there are 7 other settings that are positive, and begin with the prefix "Display".. and one positive that begins with the prefix "Show"... The lack of convention is annoying.

@thomthom said: @dan rathbun said: So mitcorb, no you can NOT edit them by accident when they are hidden (singly or globally.) All though they still update. Yes.. if associative and their anchor points are moved or changed. I'm not sure about styling fonts, etc. I suppose you can still access them via an entities collection... and I wonder if you could FORCE them into the selection set without crashing the application.

@thomthom said: That seem to work perfectly! Excellent! 4 trys is the charm. Man, I love Ruby's flexibility!

So there is none? I tried to reload an .rbs (I mean, why not) and the only way so far was to make a temp file and load that...

glad to see you interested in catmull-clark subdivision coding..

Another solution, IF the outer module does not contain instance methods, is to include it into the inner module: module TT_Test module Foo;;Biz include Foo def self.prod puts CHEESE end def self.q p Module.nesting end def self.other p Bar end end # Biz end # TT_Test I've seen weirder stuff in the standard Ruby Lib extensions, than that.

I wrote a tool that using 'slices' to find an object's [approx] center-of-gravity... You could project every vertex.position in the object down to the surface below as a raytest using Z_AXIS.reverse. The one with the shortest distance to raytest[1] gives the vector to move it down vertically, so it touches the surface as if it were dropped vertically. You really ought to make points along all edges in the object at minuscule centers and test these as a surface might well have a 'bump' that avoids vertices but which would affect the object. BUY another alternative might be to do the nearest vertex drop and do a temp grouped intersect between the two objects, if there's a result then there's a 'bump' that the object should have caught on and you can shunt the object up to suit that,,, Now you have an 'anchor' point of sorts. You know the vector from that 'first point of contact' and the CoG. If it's parallel with the Z_AXIS it's balancing on a pinpoint - but chances are it's not ! So... Rotate the object around the cross of Z-AXIS and that vector by small incrementing angles. Each time do a temp intersect with the surface. If there's a result back up in 1/10 increments until there's virtually none. The object is now on the surface and tilted downwards towards it CoG until it rests on the surface. If the CoG is not vertically on the vector from the 'first point of contact' to this 'second point of contact' then the object needs to rotate yet again - around this vector - again testing for intersections until a 'third point of contact is found'. Now the object is resting on the surface with three points of contact and the CoG is somewhere within that triangle of points - it is stable. If in any of the two points of contact steps the CoG of a vertically aligned with the vector you can choose for a 'dangerous stability' - balanced on a 'knife-edge' - or choose to tilt randomly in either direction until a 'hit' with an intersect give another point that is stable... It's actually very complex as the initial anchor might no longer be on the surface after the second or third tilt !

Nice links, thanks ThomThom regards