[Plugin] Center of Gravity

TIG

As I suspected
I'll sleep on it... and see how I can devise a work around in my sleep...
PC works fine - come on Mac's what's up with you !!!
Is it a particular version of Mac OS and the Ruby version that they have ???

driven

well, mine are
both running SU 7.1
both running OSX 10.5.8
both running Ruby version 1.8.6
MacBookPro is a fresh SU instal with just v1.4 bits
iMac is littered with rubies but very few clashes are left roaming free, it is also running rubygems, but that doesn't seem to effect any thing else in SU

both give same error

john

Dave R

Must be something wrong with my Mac, then.

driven

@dave r said:

Must be something wrong with my Mac, then.

yeh, you sure it's not a PC....

Dave R

Very funny. I have both and I know the difference.

Here's proof that it works on my Mac.

wind-borne

works ok on my Mac but TIG Tools folder replaced existing one so extrusion toolbar icons disappeared. I see missing icons on Dave's screenshot also.

C of G.png

chrisjk

Most mysterious. I have tried with no other plugins or tools in the respective folders and using CofG version 1.4 I still get:-

Error; #<NoMethodError; undefined method `db' for CofGravity;Class>
/Library/Application Support/Google SketchUp 7/SketchUp/Plugins/CofGravity.rb;156;in `do_calculation'
/Library/Application Support/Google SketchUp 7/SketchUp/Plugins/CofGravity.rb;816
/Library/Application Support/Google SketchUp 7/SketchUp/Plugins/CofGravity.rb;156;in `call'
/Library/Application Support/Google SketchUp 7/SketchUp/Plugins/CofGravity.rb;156

TIG

@wind-borne said:

works ok on my Mac but TIG Tools folder replaced existing one so extrusion toolbar icons disappeared. I see missing icons on Dave's screenshot also.

"Merge" the folders so that the other existing files are kept - just overwrite any files for that specific tool...

Dave R

Thanks for noticing that Wind-Borne and thank you TIG for the fix.

pedromarmol

I have translated the plugin to Spanish language, bottom i put de link for download. I see that other Mac's users have the plugin working fine, to me no works, i use Sketchup 7.1 in Mac OSX Snow Leopard 10.6.2 and the last version of the plugin CofG_1.4, i have tried run sketchup with CofG in the plugins folder only, and don't works, SU read the plugin, i see the plugin (in spanish) in plugins Menu but don't works.

When i run the plugin this message appears in Ruby Console:
Error: #<NoMethodError: undefined method db' for CofGravity:Class> /Users/Oxer/Library/Application Support/Google SketchUp 7/SketchUp/Plugins/CofGravity.rb:156:in do_calculation'
/Users/Oxer/Library/Application Support/Google SketchUp 7/SketchUp/Plugins/CofGravity.rb:816
/Users/Oxer/Library/Application Support/Google SketchUp 7/SketchUp/Plugins/CofGravity.rb:156:in `call'
/Users/Oxer/Library/Application Support/Google SketchUp 7/SketchUp/Plugins/CofGravity.rb:156

EDIT: Script Removed. SketchUcation forum policy does not permit people to post scripts they did not write. Please obtain permission from the author first, thanks!

TIG

Pedro

We have been PMing about this - the Mac db glitch is known and driven and I are trying to track it down.

Please PM me the CofG ES lingvo file and I'll publish it with acknowledgment of your input - hopefully with a fix for this Mac/Ruby glitch...

TIG

Here's 1.5
I've reworked the code to suit all Macs as well as PC.
A ES lingvo file has been added - by Oxer.

http://forums.sketchucation.com/viewtopic.php?p=229401#p229401

chrisjk

Congratulations TIG! It does indeed wor=k on my machine now - what was the issue?

I don't wish to sound as if I am complaining but it seems rather slow to come to a result even for a very simple block shape.

driven

Yes, for the iMac....

driven

and also a yes for the Mac book...

TIG

@chrisjk said:

Congratulations TIG! It does indeed work on my machine now - what was the issue?
I don't wish to sound as if I am complaining but it seems rather slow to come to a result even for a very simple block shape.

SketchUp is not a solid-modeler so I had to devise a psuedo-integration trick...
It is somewhat slow as it always makes 200 slices through the form, and gets the centroid of each slice and then amalgamates these to get the final CoFG. I choose 0.5% as I felt it more than covered most likely forms. If the shape has lots of convoluted edges or internal voids/holes the centroid calculation gets even more complicated as these must sometimes be deducted from the sub-total as we go etc... If you want a less accurate result you can change the @percent variable in the script to say =0.1 (1%). Unless there are lots of very small comb-like horizontal ribs the answer might be accurate enough at an even lower percentage... The time taken to do a simple block is little different to a complex form as the 'slicing' and calculations are the same...
I originally wrote it for someone making very detailed stone carving for restoration, and these need to be lifted into place very carefully so accurate axial Suspension-Points are vital - these come from the CofG... Waiting a few seconds to get a good answer seems appropriate in the circumstances as weeks of work could be lost in placing the item should it not be balanced properly...

TIG

I'm unclear as to what the problem with some Macs really was - It involved a method loaded inside a class::method not being recognized - it worked fine OK on some Macs and all PCs, but not the few Macs you lot had...
I had been a bit lazy in defining the several times 'db()' within the several class::methods anyway so I rewrote the whole code !!! It fixed it by not causing the problem - whatever that was ???
I now have it with all of its methods inside a single class [there are no nested methods this time] and then I call the two 'versions' ['Find CofG' and 'Composite CofG'] with variables CofGravity.new(1) etc in the menu code, so that on def initialize(typo=1) it has a case test and runs appropriate methods to suit...

billwheaton

I like that a lot. I am making a telescope (12.5" mirror) and balance is very important. The last thing I want to do is add weight to it in order to balance it, because it's already almost too heavy to be portable.

This is exactly what I have been looking for I think. I just don't know how to program Ruby well enough, and I'm really unclear on the sketchup API object model. This rocks my whole world and maybe now I can finish that telescope.

Previously I was copying a face, then rotating it to horizontal, then using Centroid.rb to find the centroid, then rotating the centroid and face back the other way and pasting the face back where it came from. Then I placed my centroid component there and moved it half way down the target component.

Then, in a separate spreadsheet, I put the area of the face times the height of the part times the density of the material to get its weight. Using the 'query tool' I got the xyz coordinates for the spreadsheet.

I did this for every part and used the resulting moments to find the composite Center of Mass. Let me tell you, it was a pain in the butt and very slow (days). And always with the dread of moving something out of place or adding a new part.

I think using this will be a lot easier. After all the nested composite Centers of Mass are trickled up to the top component's COG, then all I have to do is to query it to find its XYZ coords.

A couple of ideas:
Make the resulting CofG component a Dynamic Component that reports its xyz position, mass, volume etc.
Is there a way to regen the COG when I modify a component's shape?
Recursively regen nested composite CoGs when a shape is modified, or when the spacial relationship or density of components changes?
Create a report of all of them?

Thinking out loud, I understand that the code takes a while to run, and why. I wonder if there is some sort of mathematical integration trick that wouldn't require slicing it up like that. Polar slices? Integration certainly will work on a cube or a sphere, but that's the hard way of course. But how would you know ahead of time so as to change the method.

I'm afraid its been too many years out of college to remember any of that.

EDITED TO ADD THIS:
But, I have been thinking about the cog of a random solid...
For every non collinear vertex, if you add a constant weight, and then picking one random vertex calculate vectors to each other vertex. Then average them all. The CofG will lie on a vector's line from the starting vertex. Then pick a second random vertex and do it again. I think that the two lines will actually meet (not be skewed), and the intersection of the two lines should be the centroid of the solid. For a simple convex hull object I think it works, and others like donut or hollow sphere topology I think. But I am way out of my league at this point.

-billwheaton decaturgausa

billwheaton

@unknownuser said:

This is exactly what I have been looking for I think. I just don't know how to program Ruby well enough, and I'm really unclear on the sketchup API object model. This rocks my whole world and maybe now I can finish that telescope.

I had such high hopes, but here there are a couple things that make it not work for me as is.

Here is a very simply example to illustrate the problem, and I am sure that woodworkers would be familiar. I corral parts into assemblies of sub parts and create components from them.
A side and a rail become a 'side assembly'.
Two side assemblies, a front, a back, and a bottom and a knob become a 'drawer'.
Three drawers become a 'drawer set'.
Two drawer sets, side by side go into a desk carcass.

Drilling down into a 'side assembly' and selecting the rail part I run CoG.
Then I select the side part and run its CoG.
Then I select both CoGs and run their composite CoG, to get CoG of the 'side assembly' system as a whole.
Because the side assembly is mirrored on the other side of the drawer, it too gets a composite CoG in it.
But the COG for it is physically on the other side of the drawer.
Going up a level in the assembly hierarchy is the 'drawer' component I'd like to get the CoG of it. It is the composite of the individual drawer parts.

the COG of the back
the COG of the front
the COG of the bottom
the COG of the knob
the COG of the left side (problem here)
the COG of the right side (problem here too)

The problem is, the left and right side assemblies don't have their CoG exposed at the same level as the other 4 parts.
If I use the outliner to drag the left one out of the one instance to the containing instance (the first drawer for example)then it has the correct position for the left side, but then its not part of the component anymore. Opening the right side assembly reveals that it is indeed gone. So before moving anything to the containing instance, I must first make a copy of it for each instance it exists in. Then, I visit each of those instances, select one of them in outliner and move it up a level. That works pretty good. Everything then being at the same level, (drawer) a composite COG for the drawer can be made. But again, once made, if you use more than one drawer (the 'drawer set') then you have to copy the CompCOG object for as many drawers as you have and visit each drawer with outliner and move those up a level in order to make a second level 'drawer set' CompCOG. And likewise for the desk carcass which consists of two of those 'drawer sets'. As you can see, its pretty darned cumbersome, but it works, and its potentially better than I had before with spreadsheets.

Of course, finding the CoG of a desk with drawers is trivial because who cares. It's on four legs and it sits stationary in an office. But a telescope is required to be balanced. There are mirror cells, draw tubes, eyepieces, bearings, gimbals, finder rings, finders, prisms, dew heaters, tracking motors, cameras and every imaginable part.

A warning when you pull something in from a saved component that has one of these CoG elements in it. Sometimes the embedded "CoG" crosshairs get renamed to "CoG#1" and "CoG#2" etc. The code, as it stands ignores them. To make them work, you need to replace them with "CoG" after you reload the saved component... which negates the whole reason for saving components in my estimation... I haven't gotten the hang of all that, especially when it comes to replacing complex components for simplified proxy components to speed up rendering.

The thing is, I really like Sketchup. It's intuitive, accurate enough for actually building things. I understand how it works out of the box. And every time I go back to TurboCad I feel like I want to take a shower. The learning curve on Autocad and SolidWorks (as if I could ever afford that) is so far beyond my capability If it were my job it would be a different story, but I'm not an architect or mechanical engineer.

When I have $400 - $4000 to kill, I spend it on tools for my woodshop. I think a lot of other Sketchup users are the same way. Spending $10-#20 on a great script is not a problem though. I drop that kind of dough in a heartbeat down at the home improvement store every week.

So TIG, if you can figure out my ramblings (sorry, I am like that) I would be willing to donate $20 or more and I would urge others to contribute to make it worth your while too.

TIG

Bill
Sorry not to reply before - somehow I missed your post.
Could you explain why you want to find the CoGs of your joinery items and how you perhaps need to combine them, and ultimately how you'll use them all to help you.
Don't get hung up on what the current tool does - just say what some new 'wonder-tool' would do for you - a step-by-step explanation of how you might use it [without worrying about technicalities, grouping, sub-componenting etc too much...] would be good...
Then I can have a think about how I might help you further...