Grid Search
-
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.
-
Sorry, no I tried that. And tried again now on another PC, at 1, 2 and 20m nothing.
-
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. -
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.
-
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!
-
It certainly works now.
I'm slightly curious though, it may be unimportant but it creates an unusual structure to the lines. The lines of the grid don't intersect. Are they not all on the same plane? If you throw a surface over them it breaks up into a mixture of overlapping horizontal and vertical bands not squares.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.
-
@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. -
Crossing lines made with the API don't auto-intersect - unlike the basic Sketchup setup.
However, since they are in a group, so use something like.
tr=Geom::Transformation.new() group.entities.intersect_with(true, tr, group.entities, tr, true, group.entities.to_a) -
Thanks for the explanation Trog.
Tig on a side note, does that mean you could turn off auto intersect in normal life? Sometimes it would be nice to move a bunch of curves around and then only have them intersect when you have finished positioning them.
-
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). -
Trogluddite!
What a champ! Thats amazing what you've done. Thanks so much. The TileGrid plugin works perfectly, and the instructions you gave to install it are idiot-proof! Just what I need
Thanks also to sdmitch, thom thom and tig for the tips they gave you.
Trog I think you're ready to join the Axis of Awesome!Thanks to you too Box. Your input on this was very much appreciated.
Cheers
Mal
Advertisement