[Plugin] Center of Gravity

driven

Same error when v1.4 + debabelizer are the only rubies installed

Dave R

TIG,

It's not all Macs that have problems, though. It works just fine on mine. Could it be another plugin or something?

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