@thomthom said: Do you have any sample code to demonstrate? I will try to get sample code up here - just busy at the moment... Thanks guys.

Rotation and Scaling are inexorably linked in a transformation - hence the weirdness... Can I suggest another approach... You are trying to align two objects they both have obj.transformation.axes and you can transform in steps... Therefore you can move the objects together using [ tm=Geom::Transformation.translation(vector_from_point_to_point)] and then rotate one to align with [ tr=Geom::Transformation.rotation(point, axis, angle)] you can 'combine' transformations thus t=tm*tr and then use obj.transform!(t) in one step... but note that the 'order' is important in a matrix * and the order of the transformations it will do is always taken as right-to-left... i.e. the move then the rotation - unlike normal numerical multiplication it's not commutative for matrices! Moving and then rotating will not necessarily give the same result as rotating and then moving - depending on the relativity of points etc... PS: Put your code inside a [ code ]...[ /code ] block as it's easier to read. You are using a $ variable - dangerous as it's exposed to all other tools and such a common name may well clash with other authors' unwrapped code too... Use @ or @@ variables that span methods within your own module/class only... Parenthesize your arguments as method(1, 2, 3) rather than method 1, 2, 3 - although both work upcoming versions of Ruby may well deprecate unparenthesized arguments and even the most recent update caused some problems - I know th API guidance and many example scripts do it the 'wrong way' but it's a good habit to get now, before your code gets out of date unnecessarily...

OK, here is the solution for anyone who needs it in the future: # accepts either one or two arguments. The first is always the group or component where the axes needs to be corrected # the second can be a parent group or component (something that has a transformation). If nothing is passed in, the global # model x,y, and z axes will be used. The parent attribute should be used any time there is a nested component. def change_axes_to_parent(*args) if args.length == 1 g = args[0] p_t = Geom;;Transformation.new else g = args[0] p_t = args[1].transformation end t = g.transformation #p_t = parent.transformation if t.xaxis != p_t.xaxis || t.yaxis != p_t.yaxis || t.zaxis != p_t.zaxis o = t.origin # different axes, require that all components inside be rotated tran = Geom;;Transformation.axes o, t.xaxis,t.yaxis,t.zaxis t_o = Geom;;Transformation.new o if g.is_a? Sketchup;;Group ents = g.entities elsif g.is_a? Sketchup;;ComponentInstance ents = g.definition.entities end ents.transform_entities tran, ents.to_a ents.transform_entities t_o.inverse, ents.to_a g.transform! tran.inverse g.transform! o end end

As my code does: ENV['HOME']=ENV['USERPROFILE'] unless ENV['HOME'] ENV['USER']=ENV['USERNAME'] unless ENV['USER'] # now set a global; $HOME = ENV['HOME'] # .. or use the tilde shortcut within pathstrings. BTW.. the " ~*user*" feature does not work on Windows. Likely because of Security issues.

The diagram (previous post,) was prompted by yet another argument over what was a Tool, and what was a Utility, whether they were Plugins or Extensions, or both. My argument is that everything loaded into Ruby (except the Core,) is an Extension. Then 3 main types: Plugin, Library and Service. Although I show 3 "kinds" of Plugins, in reality there is often overlap. A given plugin may have several, (if not all,) subtypes as features.

@morisdov said: @jim said: Please add your own "Do and Don't" recommendations for writing SketchUp Ruby code. DO wrap your plugin in a module (namespace) to avoid clashes. DON'T use another person's registry keys, namespaces, or attribute_dictionaries. The problem is you dont know who might have used what "name" , there are far too many other people out there for one to research their obvious common sence choices of keywords. NO .. it's actually easy. If you stay in YOUR namespace, you can have your Plugin module(s) be any name and they will not clash. Then.. use the namespace nesting to construct a unique registry key: module Author module Widget # Construct a registry key to save the plugin options under; # @@opt_key = "Plugin_#{Module.nesting[0].name.gsub(/(;+)/,"_")}" # Remove whitespace and non-word chars (just in case.) @@opt_key = @@opt_key.gsub(/\s+/,"_").gsub(/\W+/,"") # the key will be; "Plugin_Author_Widget" end end Then you can use the registry key also as a prefix for any AttributeDictionary objects that this plugin uses: module Author;;Widget @@dictFlags = "#{@@opt_key}_Flags" # create the dictionary @dict = ent1.attribute_dictionary( @@dictFlags , true ) # the dictionary will be; "Plugin_Author_Widget_Flags" end #module Obviously,.. you replace the word "Author" with your own namespace identifier, and choose the name of your own plugin sub-modules, and their dictionary names.

Look in dir: source\sketchup\skpwriter\sapi at file: ientity.h

Working on a viewing/walk though/demo plugin. It will allow to create a walk through path and several other options. One of the options is an orbit path. If the center of the orbit is not specified I want it to do whatever sketchUp does.

Thank you very much. The code worked and will be uploading soon... And I am learning ruby for sketchup from basics now..

Dan, I stand corrected - clearly the skethcup.rb's 'inputbox' is to be preferred to the UI. version...

@tig said: Every group or component-instance has a complex transformation giving 3d location, rotation, scaling and so on... You can use that insertion_point = instance.transformation.origin I had a feeling you'd be the one to answer TIG, and Thank you, thank you, thank you. Works perfectly. I spent hours pulling hair on this. Don't know why I didn't think of that.

@tig said: If you want to know the orientation of a face relative to its edge, then use this http://code.google.com/apis/sketchup/docs/ourdoc/edge.html#reversed_in? You can then compare the three faces sharing a common edge and if one is 'backwards' used face.reverse! OR use face.normal.reverse in the testing ??? This could be exactly what I need,have to test first. Thanks.

@voljanko said: @dan rathbun said: group.local_bounds() Yes,it is working,I have test it....BUT,it is only available for groups,not components. This is because .definition() is exposed to ComponentInstance objects, so: def get_local_bounds(obj) case obj when Sketchup;;Group obj.local_bounds() when Sketchup;;ComponentInstance obj.definition.bounds() else obj.bounds() end end

If a vertex has four edges you trap that each edge only has one face [a taken]. If you get the vertex_normal and use a plane through the vertex.position to flatten [project] the vectors onto for the 4 edges being tested, can we ever get a zero length vector ? I think not, because the dot processing will never make a plane that's 'square' to a given vector - as there must always be some of the 4 edges spring off at angles...

@kyyu said: Try this: thanks I will give it a try!

So I was wrong in everything I said Yes it was part of some longer piece, I copy and pasted it wrong, sorry.

My idea of using a temporary group means that the faces in the group are all that's needed to consider for reversing - so it very quick; if you are making lists of all entities before and after a pushpull then there might be thousands of them to sift through, twice! ... So why not make a group, add a circular face, pushpull it, reverse the faces in the group, re-add a circular face to the group and erase it, then add a circular face to the main-face and erase it to leave a hole over the grouped 'recess', and finally explode the group? It will be much quicker in most circumstances... and 'safer' too...

@dan rathbun said: But I think his intention, is to do batch mode export to dae for a whole dir of skp files. So manual drag-n-drop is out of picture. He can use a shell script, no doubt,... ... but he could also do batch export, from within SU Ruby. You can drop multiple files onto a MAC command file or an 'applet', they are processed in turn, so the code could in turn make txt>>rb, open each SKP dropped; the rb file doing the SKP export, renaming itself txt and closing the SKP for each one. A much simpler way to export a folder of SKPs as .dae is to have a permanently loaded Ruby tool - I quickly wrote this as an example... http://forums.sketchucation.com/viewtopic.php?p=347277#p347277

I fixed a few things and realized I could call the instances I added to the global component by different names. It does run slow but I still haven't looked into optimising scripts so hopefully I can speed it up some though I don't mind it though, it's faster then creating a cabinet from scratch. Next on the to do/ to learn list is... Creating door and drawer fronts, creating drawers... shouldn't be a problem. Add a user defined number of shelves and insert them evenly spaced in the cabinet... I can do this manually/individually but the math involved in doing them automatically should be fun to figure out! Same thing for door and drawer fronts. And give a choice of creating an upper or lower cabinet since the building of these is different... I could use 2 different scripts like I did when moding the cab.rb script but I think it would be slick having it all-in-one. Add grain direction And eventually learning how to export the to a csv file so that I can populate an existing excel spreadsheet that I use... yes I know there are already some cut sheet/list scripts but this is more of a hobby/learning experience and I'd like to see what I can do. That should be it but I'm already happy with the progress I've made in just 3 or 4 days or learning this stuff. Again thanks for all the help I really appreciate your teach how to fish approach. Frank Test.rb