Well, I ended up just copying the gem scripts I needed into my plugin folder (it was Builder fyi)... but it's really not ideal for when people already have an existing Ruby installation, and I don't think it will even work if the gem is more complex (I suppose it could be using a C library, or a dll, which is harder for me to copy around, or have too many dependencies to realistically copy all of them into my plugin).

Why is SketchUp reporting version 1.8.6 for me, when I don't technically have that version installed? Is it just the interpreter that SketchUp is using? Why doesn't it use the interpreter from my installed version?

Maybe Dan Rathbun has some advice for me here?

@tig said:

Outer-loops are always returned counter-clockwise.
Inner-loops are always returned clockwise.

Thanks TIG, I know you've posted on this before... just wanted to be sure!

Hi all,

I'm writing a recursive method that will find all the groups in a tree-like fashion and print their names. I think I have something that works, but recursion always makes me nervous, so I'm hoping someone can check my reasoning... maybe it's not very optimized etc etc...

  #
  # recursively print the group tree
  #
  def print_group_tree()
    @model.definitions.each { |d|
      if (d.group? && d.instances[0].parent.is_a?(Sketchup;;Model) )
        if (d.instances[0].is_a?(Sketchup;;Group))   # Assume Groups are unique
          puts d.instances[0].name
          recurse_group(d.instances[0])
        end
      end
    }
  end

  def recurse_group(group)
    group.entities.select { |e| 
      e.is_a?(Sketchup;;Group) 
    }.each { |g| 
      puts g.name
      recurse_group(g) 
    }
  end

I'm making Groups unique before I run this, just to be sure (I know SketchUp can be touchy about Groups and uniqueness...)

Thanks!

Is there an order to Loop.vertices retrieved from Faces? I think I read somewhere that outer_loop is guaranteed to be counter-clockwise. What about inner loops?

Just did a quick check on a donut-like face, and the outer loop is CCW, but the inner loop is CW. Is that always the case?

I'm trying to use some RubyGems. I have Ruby191 and Ruby192 installed, but not 186, which is my RUBY_VERSION as given by SketchUp...

I am looking at the script in this thread: http://forums.sketchucation.com/viewtopic.php?f=180&t=29412

Must I install version 1.8.6 of Ruby (or, generally, a version matching SketchUp's reported Ruby version) to use gems etc? I've read around the forum that I shouldn't mix Ruby versions with what SketchUp uses.

YAY! Thanks a ton thomthom, your solution works.

@thomthom said:

ok...

What about:

1. user pick face
2. group the face ( group1)
3. get the definition of the group ( group1.entities.parent)
4. add a new instance of the group into the group you want it
5. erase group1

When you have the group instance you can use entities.add_instance to add a copy of the group.
It might avoid the problems if using .add_group with entities as argument and exploding.

Oh... tricky. I'll try that tomorrow.

@thomthom said:

I'm confused by all this...
Why are you not creating the entities directly into the appropriate group instead of trying to move them from group to group?

Because, my "real" code gets the faces by way of the user clicking a context menu on an existing face and clicking my plugin's option. So, the face is already there, but my example script is emulating this by creating a face inside of model.entities first...

Check it out. I have all these groups (group2 - groupN), under a root group (group1). And then I have faces, which I want to group with edges (faceGroup), and place in a nested group (group2 - groupN). There could potentially be many faceGroups, as shown in the picture...

HOWEVER... my example script 2 posts up is a simplified version of this, with only one nested group (group2), which is initially empty.

Clear enough?

Thank you very much Chris. And thanks to TIG too, even though I'm pretty sure he's moved on to bigger and better threads than this =D

@tig said:

Aaargh...
Please try recasting your code [ignoring names and reusing references [variables] as it's getting confusing] in a way I outlined...

Argh indeed!

Here it is - as simple as I can make it. This is 14 lines of code. Now tell me, what is wrong?

The heirarchy is: model.entities -> group1 -> group2
After the code finishes, it should be: model.entities -> group1 -> group2 -> faceGroup -> face+edges

You can see that I'm creating these groups here, so there's no "magick!"

` # Testing group nesting

model = Sketchup.active_model
modelEntities = model.active_entities

Create a face

pts = []
pts[0] = [0, 0, 0]
pts[1] = [100, 0, 0]
pts[2] = [100, 100, 0]
pts[3] = [0, 100, 0]
face = modelEntities.add_face(pts)

Create root group

group1 = modelEntities.add_group()

Nest group2 inside group1

group2 = group1.entities.add_group()

Create group for faceGroup

faceGroup = modelEntities.add_group(face)

Nest in the first level

newGroup1 = modelEntities.add_group(group1, faceGroup)
group1.explode()

Repeat to get it to the second level deep

newGroup2 = newGroup1.entities.add_group(group2, faceGroup)

group2.explode() # This crashes SketchUp`

I think TIG gave up on me...

Thanks thomthom!

I'm having trouble getting an Array of all Face's in the model, since Sketchup.active_model.entities returns Group objects, without the Face's contained within them.

@thomthom said:

You have it selected. The currently active material will not be purged. Select the default material before you purge.

I see... is there a way to find/change the currently active material thru Ruby?

Cool... except that I purged and there is still one material left - "0135_DarkGray". What's up now?

Can someone explain this screenshot to me? I tried to delete one of those 8 Materials. Where are these materials being used? I even killed Susan...

So how do I get a list of all Materials on existing Entities? Must I loop through model.entities?

@tig said:

The 'groupGroup' group DOESN'T really exist... except that you have made an empty group [too early] with that reference.
Adding that empty group so early on into the mix and then trying to 'move' it into another group only confuses things.
IF you already have a non-empty group with that reference then it's OK... but if not only make it when you need it otherwise.

In my real code, there is already a CPoint inside "groupGroup." If you think it's a problem that groupGroup is empty, then fine, I just tried adding a CPoint to groupGroup in my example script. Still broken.

@tig said:

If you still can't get your head around this

Sir, my head is wrapped around this problem about 9 times already. I feel like you think I don't understand, but I do. I understand every word you have written, and I keep telling you, "I'm doing that, I'm doing that. Look at my code, look at my code."

@tig said:

please post a simple before and after set of uniquely named objects with their hierarchy - e.g.

I did this already. Look at my script!!! Look at my screenshots!!! I am creating rootGroup and groupGroup. That is my hierarchy.

I'm going to repeat my question again. What is wrong with line 49 of my previous example script? I COMPLETELY understand EVERYTHING you're telling me, and I believe I'm doing it, but it's still broken, and I don't see why!!!!!!!!!!

Okay, you're just confusing me now, and what you're describing doesn't work for my situation. groupGroup already exists, and rootGroup already exists. I'm only creating them again in my example so that it can stand alone. So doing anything like groupGroup=newGroup.entities.add_group(faceGroup) isn't acceptable, because groupGroup is ALREADY THERE.

Look TIG, can we get a bit simpler? Can you look quickly at test_group_bug.rb? I just simply don't understand why this line:
LINE 49: newGroupGroup = rootGroup.entities().add_group(groupGroup, faceGroup)
is breaking my code. As far as I can see, this is EXACTLY what you've told me to do. The contexts of groupGroup and faceGroup are identical (faceGroup.parent = rootGroup, and groupGroup.parent = rootGroup... I've checked).

Moreover, the SAME CODE works several lines up, when I do the SAME THING, except in model.entities instead of in rootGroup. I'm very confused, and I need a straightforward answer. What EXACTLY is wrong about that line of code?

@tig said:

Try this...

Try what? I did all of this in my code! I also want to nest faceGroup one level deeper, into "groupGroup."

As I said, getting faceGroup inside of rootGroup isn't a problem. It works using your trick. But I need it to go one level deeper, into groupGroup, and it's not working!!!

You stopped the code RIGHT BEFORE the point where I don't know what's wrong... And you took out the part with groupGroup, which is my entire problem!

Your code does this:

Please TIG or someone else, can you tell me specifically in my code, i.e. what line and WHY, am I doing wrong? I posted the example which reproduces my bug. What am I doing wrong? This bug has been stopping me for a week now... it's getting ridiculous!