That would be it. I expect I went right by it when I looked there. My would say, "you were looking like a guy." And then she'd Thanks.

Thanks now it works. I'd forgot to put the icon in.

@darth hideous said: :thumb: Do you have a Warehouse account? I'd love to see some models...Hey, I cant use the ossciator or the magnet joints. Search for "SketchyPhysics" on 3d warehouse. There are tons of models. Oscillator joint was replaced by a setting in piston. Magnet doesn't work yet. Chris

@gata said: Nudge was the first script that used the arrow keys to nudge all sorts of stuff http://www.smustard.com/script/Nudge. The Move Wizard in RpTools/Space Design also moves everything http://forums.renderplus.com/wiki/index.php?title=RpTools#Move_Wizard but works in PCs only. I'm planning on trying a new move-like Tool that is keyboard only. I don't care for the dialog myself. I think with a well written instructions, intuitive functions, and using only keyboard with modifiers; a new mover could be a efficient tool. I think I'll go try Jan's jsMoveTool now...

TIG, Thank you so much.

Didier, Thanks. It seems to work as you described. Appreciated the PDF instructions as well. John

Here (New Board) http://www.sketchucation.com/forums/scf/index.php

more images [image: image.jpg] [image: 2dproject5.jpg] [image: 2dproject4.jpg]

Hi Rick, Thanks for your feedback and other help. I agree, the menu would be neater within a submenu especially when using many different plugins. We've just released an updated beta version of Demeter that does this. The overall folder structure has been improved and the plugin should now be compatible with your Organizer plugin. It is also now compatible with the Mac OS X version of Sketchup and has had various other improvements. The new version can be downloaded at:http://greenspaceresearch.com/demeter.html Thanks, Malcolm Murray

Well done Didier. A relatively painless way to give any cutting component some attributes so that it will punch a hole of the desired shape through a twin skinned wall - but only if you want it to... I see that you have ### disabled the observers (CuttingWindowWatch) till you get your head around them. They will need to be convoluted. To get the observers to work you'll need to attach themselves to each of the component instances as they cut the hole, AND also auto-load them in later sessions at startup to get them to continue to 'report' on those components as they change... Note how you need to add an observer to each instance [NOT the component's definition] for them to be useful later... You also need to add similar observers to all of the faces forming the reveal of the hole that the instance cuts. The hole's faces AND the matching instance all need to have a unique random-number attribute ID to tie them together - set at the moment the hole is cut. Later on, if an observer spots that the instance is moving it reads the transformation (you might need to remember the 'at rest' transformation when these attribs are first set and save that as an attribute too ?) The initial 'at rest' attrib can be read and updated to suit. A dialog could then ask if you want to keep this window and its hole linked together. If 'No' then their linking attributes and observers can be deleted: if 'Yes' then the associated faces with the same ID move by the same amount. Also these faces' transformations are also storable and can be updated to suit. This way you can choose to keep them linked and move together. You would also need an observer to spot them being copied so that the linking attribute IDs are either eased from the copies OR replaced with new unique IDs. If any one of the linked faces or the window instance are deleted then all of the remaining observers and attributes also need clearing from what's remaining - perhaps with a warning messing ? Scaling of the window should alos be reflected in rescaled reveal faces when the link is kept ? If a face of the hole moves then the other faces and the associated window should move with it IF they are to be kept linked... This linking by attributes and observers is like a weak grouping that lets you change some things that affect others as you work...

Unfortunately the biggest drawback of all these match/group (by)layer/material- they don't work with the complex hierarchy (components nested in components)

@jim said: One does not exist, but it could be done. Each Arc is made of line segments, and each arc has its own radius point. The line segments of any one of the Arcs should all have the same length. Therefore it is possible to find the lines that make up each arc, get the end points, center point, and radius; and finally re-create the arc. Would be very interesting if it will be developed. Personally I have very low practice with ruby scripting, but I think for the experts here in this forum wouldn't be a matter. Replying to Dave R, I already know weld.rb but the problem with that is the curves you joined together aren't editable like arcs (if you pick the middle point on an arc you can stretch it and change his shape)

Thank you... i use this - 28.08.07: Edited by D. Bur: v 1.1, added lights support, save/load parameters. So i change string2string by Akelpad/i modify too, add some mats-syntax(old version of this forum had some my tests) No way - SkipyMan - renderman connection...i prefer free solution like sf or aqsis..

My use of SU rather specialised and not representative, but I have greatly benefited from pipe along path & extrude along path points cloud put on layer My thanks to the respective authors. I have also used curve stitcher and angular dimension to good effect. And I love the go 2 school training videos!

And I did not get you anything for Christmas TIG... thank you.

TIG, Thanks for pointing me in the direction of yet another of your fantastic scripts (ExtrudeAlongPath.rb) Works perfectly. I've never seen this one before. ... Thanks once again Regards Howard Leslie

Yes, four scripts, plus two supports classes. No real reason why they couldn't all be in one Ruby but it makes the code too big for my tastes. I've been rushed off my feet the last couple of days (hence the lateness in replying) but I'll see if I can get then posted on here ASAP.

Oh oh, TIG this time you have been 2 hours long before posting the new script ! That's too much ! Next time you are pleased to do it quicker. A quarter of an hour should be enough, no ?

Very nice. Thank you, Glenn

@unknownuser said: TIG, Would it also be possible to add the following... ??? ... If the user had the option to choose either Horizontal or Vertical Volume slices it would make the Volume Calculator more accurate. Not sure if its possible but would be brilliant. (See attached file which illustrates the problem). ... To Calculate Volume on a Selection of Several Groups / Components at once... eg User selects 12 Groups or Components... Volume Calculator then loops thru each Group / Component in the selection in turn calculating volumes for each individual group / component that was selected based upon the users settings in the Volume Dialog box eg Layer for Volume Slices / Hide Edges / (Vertical or Horizontal Slices) etc ... Hope this all makes sense. Anything you can do hugely appreciated. ... Regards Howard Leslie Edit 1 / Ideas Thoughts: Script could actually make true Vertical Slices (or any angle) or Temporarily rotate geometry in the background hidden from user and then turn it back again ??? or Produce both Horizontal & Vertical Slices for each Group / Component and Delete the lowest Value ??? (might be slow) Edit 2 / Ideas Thoughts: Vertical slices may be a problem - how would the script know the best orientation to draw them in ??? ie Vertical slices can be drawn to be parallel to either the red or the green axis - how would any script choose the best way to draw them ??? Poss Solution - Draw Volume Slices Parallel to all 3 Axes !!! Delete lowest Volume that was computed for each Group / Component (Could be VERY slow). Edit 3 / Ideas Thoughts: Best Solution may be to forget Vertical slices altogether ??? Working out Individual Volumes in Turn (Looping) for Several selected Groups / Components would be good though. That way, for any "problem" Groups (eg similar to attached file), the accuracy could be turned up to say 1% - the Script could then be left to run eg over a lunch break or over night if required. AdamB has just fired a broadside through the current ideas behind Volume Calculator with an ingenious method the calculate volumes from faces... I wrote my volume calculator based on totting up areas of slices - somewhat like calculus - which was a few years ago after TBD said it couldn't be done... It's taken till now for someone (AdamB) to come up with a method that does it properly 'mathematically' - his '.dot' method was the answer. Adam's way returns a more accurate result very quickly, but the downsides of his method are that it gives no 'solid' artifact of the volume - although it could have a text-tag made with a volume attribute so that csv making was eased: a copy' group of the entities could be made coloured as desired too. Also his gives unexpected answers for volumes with missing faces, whereas mine only fills up to the top level and then overflows so to speak - like a tilted glass; and I not sure how his method copes with having some faces reversed as it uses face normals during the maths - I need to test that... I intend putting a a new version 'to the vote' and if there's sufficient demand and Adam agrees I'll look at v2.0 using his methods, but adjusted to suit whatever the 'users' want of it - clearly it'd need alternate volume options, csv listing etc... His method would allow multiple selections and I can contrive it so that you get much of what you do now but more accurately and faster... Watch this space...