@jolran said:

There is no way to do Matrice calculations that affect tapering in Sketchup ?

I don't know the API so well, but mathematically, the matrices would only be able to do what are known as "affine transformations", which have the property that lines which start out parallel with each other always remain parallel - so tapering would not be possible.

Thanks Dan, I'll go check that out.

Thanks for the code tips, TIG, I was about to ask someone how to make a collection of entities intersect with themselves using that method.
So far, I have it working using a nested group which I later explode, which seems to work well enough - is there any advantage using 'intersect_with' compared to group.explode in this case? (i.e. a single collection of entities that must all intersect each other).

@box said:

I only ask because it surprised me and also made me think would it affect inferencing or measurements if the lines aren't all at 0, which they may well be.

Aha - well, this is one thing that I did actually test properly!
If you use the query tool on the interection inferences, the lines do indeed all intersect on the ground plane - but you're right, they don't actually break each other into segments.
IIRC, in older versions of SU, that was the default behaviour, you had to do an explicit intersect to segment the lines - unlike now, where lines made by the tools break up automatically.
As I understand it, when adding geometry from Ruby, the lines won't break apart unless you program them to. But in this case, as the lines are intended only as a reference for inferencing, I kept things simple - so long as you don't add extra geometry inside the grid's group, it makes no difference, and keeps the amount of geometry smaller when a grid is made with a large number of 'cells'.
I think I will look into that as an option though, and possibly a guidelines option too - it is all good Ruby practice, and those other ways of doing it might be a useful alternative for some users.

@box said:

this is the error I get if you want it

Thanks - yes, that would have told me just what I needed to know, if only I had had the good sense enough to ask!
Fixed version now popped backed into the original thread, with thankyou's all round!

Hi mal,

The tips you've been shown so far are well worth knowing and practicing - but your post caught me just as I was looking for an experiment to test out some of the lovely Ruby things that I've learned from the guys here.
So, as long as you don't mind being a 'guinea pig' for my first go at creating Ruby geometry, here's a little plugin to do the basics of what you want...
EDIT: Download updated.
v1.0.1 - to fix the bug reported in the posts below. Apologies to the folks that had already downloaded v1.0.0.

Just drop the file into your Plugins folder, and it will add a new item to the 'Draw' menu, called "Tile Grid".
You then get a dialogue asking you for the tile and grout sizes, and how many tiles you want.
It's pretty crude - the grid is always drawn on the ground at the origin, pointing along the red and green axes. Measurements are in your chosen model units, and you can get a simple grid of squares by simply putting in zero for the grout width.
The grid is built as a group, so it acts as a single unit, but won't clutter your component browser - and the group is named "Tile Grid" with the sizes, so that you can find it easily.
It will also undo all in one go with CTRL-Z, if it ends up a mess.

I've followed the 'safety' guidelines of the Ruby 'gurus' as best I know, and it works reliably here - but as with any new plugin, take precautions! And don't hesitate to give me some grief if it is buggy!

With many thanks to ThomThom and sdmitch, the trouble should now be fixed - also with better handling of invalid input values (thanks D.Rathburn)...

Seems I was using a Ruby method that looked like a genuine API one, but was actually added by one of the plugins I have installed (RTFM!!!).

The download is available again in the original post above (to keep it with the instructions)

And thanks again, Box - your speedy bug reporting is much appreciated.

PS) And thanks to Dan Rathburn too - I was just reading his excellent advice on catching errors inside an undo commit operation when those replies came in. So now I can make invalid input values behave more robustly too!
Oh, what a grand place this is!

@thomthom said:

have you asked them to keep the Ruby Console open and report back any messages that might appear?

[FacePalm]
Thanks for the prod, ThomThom - why is it always the most obvious things that I forget?! More caffeine required, I think!

And many thanks to you and sdmitch
I still can't believe how fast those "reply to your post" e-mails go 'ping, ping, ping', I barely had time to make a coffee!

Indeed, now that I look at the API docs again, I see my schoolboy error. I started out using a component, and then decided to change to a group to avoid browser clutter - lazy bones using find/replace instead of RTFM!!

"Check the console, check the console, check the console, check...... "

Hi there, coders.

I've just taken down a new Ruby plugin download because of reports that it was not working for some people at all, though I don't seem to be able to break it on my own system.

It's pretty much my first experiment with creating geometry and groups, so no doubt this is just down to my inexperience.
What should happen, is that the user is asked for some basic dimensions, and then a very simple grid is drawn on the ground plane, with all geometry contained within a named group.
When I test here, on two different machines (SU8, WinXP), it works flawlessly - (so long as I type sensible values, I realise some input validation may be in order).

However, other users have reported that no geometry or group is produced at all - though nothing 'fatal' like a bug splat or damage to exisiting geometry (phew!).

Tile Grid.rb
Usage instructions and correct behaviour are documented in the Ruby header.

Thanks in advance for help and insights - I don't want to take the next step into more complex geometry until I'm sure I'm doing these simple things correctly!!

Thanks for testing again Box - I must be not taking something into account to do with how folks have SU set up differently I guess.
I'll move the download to a "Ruby Help" thread for the time being then, to save anyone else the same frustration.

Cheers Box, I'll take another look at the code - I think I know what I've done.

I do fiddly little mechanical stuff rather than buildings, so my default template is rather zoomed in - when I just tested with the default SU template to test the download, I couldn't see anything either - until I did a 'zoom to extents!
If I hadn't had the Outliner open, I wouldn't have realised it was there!

Seems I've set the default tile size as if for a miniature doll's house, so small that you can't see the grid because the axes get in the way!! Doh!
Seems fine if I type in a new size value - it regains its sense of proportion then.

When I get a moment to dig into the code, I'll fire up an editor and try editing the defaults to something a little more appropriate for the intended job.

Hi Alex,
First impression is that I like it a lot - I'll certainly put it through it's paces for you (and for me!)
I use Ruby in another similar environment for audio plugin development, where everything is nicely 'in-line' with instant feedback on tap. Much as a I am used to Notepad++ and the indispensable Console+ plugin, it always feels like a step backwards writing SU scripts - too much copy/pasting and messing about in the plugin folder for my tired old brain! And no more trying to find room for a FireFox window!

The feature set so far seems pretty much bang on for an interactive editor - just right for that tweaking and tweezing stage of coding where you want minimum clutter but enough editing capability to do some serious alterations. And the presentation is lovely - very easy on the eye for those late night bug fixing sessions! The only thing I think I'd miss is the ability to search the code to find "that" method, where I know that a bug I just noticed is snuggled!
I also get a slight graphical glitch with the output pane at the bottom - intermittent white lines when scrolling the display that don't line up with the text.

Pretty sure this one is a "keeper". I have a couple of file export scripts to do to speed up some stuff at work just at the moment, so I'll see how I get on using it on those and get back to you later in the week.

Many thanks for letting us play with your new toys!
Trog.

Easy - just open the previous version of your project that you saved before going nuts making the geometry all wonky!

@mike lucey said:

I wonder why they gave their obvious audiences a wide berth, the UK and Ireland?

Well, if my experiences back in the days when I was playing are anything to go by, because the UK just isn't half so accomodating, and the average punter is too closed-minded to listen to anything new (sweeping generalisation!).
After playing only the UK for years, we were stunned when we went over the channel to play a few continental gigs. The audiences there are just so much more open minded to listening to stuff across different genres - and the small local promoters really go to town with their hospitality. We were stunned to play events where hardcore punks rubbed shoulders with glittery disco fans - even, shock-horror, dancing to "each other's" music. Sadly that seems so rare amongst the Anglo's.

Then there's the added expense of crossing the channel with all your gear in tow, and more still for the hop from mainland UK to Ireland. I'm quite a fan of a couple of bands from northern France - and on the rare occasions that I get to see them in the UK, they make it clear that they would make the trip more often if they didn't always end up out of pocket. Playing small gigs just doesn't cover the expenses, as we discovered ourselves with our jaunts going in the other direction.

The big UK venues will only ever book acts that they know are guaranteed money pots - if you don't have some kind of nationwide recogntion, you're never going to get the chance to play anything more than the small pubs and clubs.
But the pub/club scene is a shadow of its former self too here in mainland UK. "Staying in" is the new "going out" because folks are strapped for cash, and the big pub-co's charge so much more for alcohol than the local supermarket. Pubs are dropping like flies, and are on such a knife edge of profitability that they won't risk paying for a band that doesn't just play the same old "safe" 60s/70s cliched cover versions, in case it scares off the few punters they have left.
Of course, there are still pockets of good things going on - I went out to a great all day festival in Leeds just yesterday. But many of those scenes are rather cliquey and divided by genre - if you don't know the right people, you'll never get on the bill.

Apologies for the rant. I love live music, and having been in bands myself and seen the opportunities to play dwindle, the state of the music scene here saddens me immensely.
What chance is there for a new Beatles, Rolling Stones, Pink Floyd or Who in this climate?

Ah, allowing the user a choice per component - that's very neat, thankyou.

Great to have this thread - I'm always fascinated by what us "visual creatives" like to stick in our ears!
And nice to see Primus getting a showing - that nutcase Les Claypool is the man responsible for the callouses on my fingers from spanking my plank!

Here's a little taste of PNEU - These guys blew me away when I saw them recently (sadly they don't get over to the UK too often).
Apologies for the lousy audio quality - they have some studio stuff, but the coolest bit of the experience is that the vid' shows how they always play live. Two French dudes, minimal gear, a big rug in the middle of the room - and they like you to get real close - as in nearly knocking their gear over CLOSE! Real sweet pair of fellas too...

And once my ears have stopped bleeding after that, I like to mellow out before bedtime with a little Renaud Garcia-Fons. You have to see it to believe that one guy, a double bass, and a few gadgets can make such a beautiful sound...

After a bit of playing around, the addition seems to work in all the situations I tried - I can only think that inappropriate classes of object are being used.
Even UI.messagebox(pt+v,MB_OK) with no explicit string substitutions works fine.

Are you trying to add two arrays directly? For the Array class the '+' method is indeed defined as a concatenation - not of strings, but of the arrays themselves. This returns a single, bigger array, containing the contents of the two input arrays.

The essential step in ThomThom's example is the explicit creating of Vector3d and Point3d objects. Although they can be converted to arrays, and have a similar appearance, they are NOT in themselves arrays or even sub-classes of Array - they are Sketchup specific classes of object for which the '+' method is defined differently in order to make geometry easier.

The x,y,z parameters can be turned into Array form using the '.to_a' method - but this should only be done if you are certain that a Ruby Array object is really what you need, as the '+' method will then revert to the standard Array class version.

Defining '+' any other way for arrays would make little sense, as they can contain many different kind of objects (within the same array even) - and for the vast majority of 'non-number' objects, an item by item addition would simply return an error.

Hi There,
Just wanted to say thanks, Ash, for the idea; and Dan for for the sterling work putting it into practice.
I very often derive components in a model from other template parts, and I forget to click "make unique" about 50 times a week!
Having a warning that pops up regardless of the 'hiding other stuff' settings is something that could save me oodles of time re-loading components or going back to previous file version.

@chrisglasier said:

One could ask why each plugin doesn't get their won environment - but then consider how much overhead that would require to run a separate instance of Ruby for each and everyone of hundreds of plugins. Also - each plugin is accessing the same model entities - how could you place each plugin in a separate environment and still give access to the same model data? You'd get much of the same issues you get with multi-threading

Re-reading this thread after encountering similar issues with another Ruby API entirely (FlowStone DSP programming software), which brought up this very problem of "sandboxing".

Simply, it is a non-starter in Ruby - even if it were desirable (careful what you wish for!), it couldn't be done. Ruby employs a 'Global Interpreter Lock' (GIL). In short, it is only possible to have one Ruby interpreter per process (the SU application being the 'process' in our case).
This is a decision made, and stuck with, by Matz who first created the language. The intention is that this ensures thread safety - and since all plugins must access the same model data, this is pretty important.
It's also why the API cannot access multiple processor cores - the interpreter runs in a single thread. Thus there is, on purpose, very little truly concurrent processing in Ruby - if there were, method calls could be processed "out of order", with the potential to seriously mess up any shared data.

From what I have seen here, it seems that the Ruby 'gurus' have found, and are actively promoting, the most effective and least intrusive solution to the problem. Over at the site for that other software, we are trying to build a similar framework of best practices - and the research we've done indicates that the techniques used here to manage the namespace are pretty much as good as it gets - given the limitations that using 'C' Ruby inherently imposes.

When writing a plugin, then as a developer, I would expect that my geometric calculations etc. were spot on so that the thing actually worked for its intended purpose - and I don't see how expecting the "housekeeping" parts of the plugin to be equally robust is an unreasonable responsibility. Not treading on the toes of the API or other plugins is part of the 'specification' for a good plugin, as important as getting lines and faces in the right place.

Maybe Ruby just makes it too easy? - folks using the more typical C SDKs of other applications have to work a lot harder to make robust add-ons, and things like thread safety etc. have to be considered and accommodated within their designs. Comparatively, wrapping everything in a module, and not messing with the kernel, is really not much to expect - anyone who can understand the API doc's should have no trouble understanding those things too.
The Ruby 'gurus' and mod's do a great job of advising us noob developers, but cannot force amateur dev's to heed their warnings. The techniques involved are not terribly complex (even I understand them!), and I have no problem with developers who consistently refuse to take good advice being censured for the ill effects that their plugins can cause.