Add_group( entity ) weirdness

thomthom

g1 = model.selection[0] < group with set of faces

face = g1.entities.find { |e| e.is_a?(Sketchup::Face) } < fetch a face in g1

face.material = 'red'
face.back_material = 'green' <- Highlight the face for debugging

g2 = g1.entities.add_group( face ) <- group the face

This causes the face to appear to have been shifted to the origin of g1 - instead of preserving it's original position.
On top of that - there appear to be a face also in the top context - it's even selectable. While g1 doesn't let you select any groups.

It seem completely messed up. I tried Fix Problems - but it reported no errors.

What is going on?

Jim

I got the same results - screwy.

TIG

Even weirder... the original face and the one in the group are the same and select together.
Now try exploding the new group.
The new face from the exploded group stays where it was [wrongly located] with edges BUT the original face [in the wrong place] now has no edges except those that have appeared where it was originally ! The exploded face is also now outside of the original group!

The entities.add_group(face_in_entities) should work
Cross-threading entities contexts causes splats but not with this simple way.
My 'Mirror' tool does something very similar - you'd select the face that is within the group and mirror it, it'd be temporarily grouped and an instance of that temporary group inserted and transformed in the same entities so it is mirrored: you then choose to erase the original selection [original temporary group is erased and copy group exploded] or to keep the original [both groups are exploded].

I've just tested Mirror and it works fine... it is doing almost the same thing ?
BUT there is a difference - the difference is that you are within the group's entities when selecting and mirroring the face so that the newly grouped-face stays in the right 'context' of the active_entities... If you do thomthom's 'steps' BUT just before creating the new face-group you manually edit the enclosing group so that the active_entities changes to be the group.entities, then all is well!

So it seems that entities.add_group(face_in_entities) WILL work IF the entities are the model.active_entities - OK if you are selecting stuff first within a context, because they will then be [unless you close the edit] but as you can't ' set' the model.active_entities within the API we're knacked if selecting an object outside of the active_entities... The only way to do this safely is to check is the entities==model.active_entities - if == you can use entities.add_group(face) BUT if not you must clone the face and erase the original -
` entities=g1.entities

'face' got as before

pts=[]
face.vertices.each{|v|pts << v.position}
g2=entities.add_group()
nface=g2.entities.add_face(pts)
fmat=face.material
bmat=face.back_material
layr=face.layer

etc ### you could also clone the face attributes if it has any...

you could also clone the face.edges material/layer/attributes for completeness...

nface.material=fmat
nface.back_material=bmat
nface.layer=layr

etc for attributes if necessary or to match the edges properties too...

face.erase!
face=nface`
We now now have 'cloned' the face from inside of g1 and put it into g2, and erased the original.
What a faff!

thomthom

Not that easy - faces can have holes in them.
I did make a method that will first recreate the face by taking the outer loop vertices, and then iterate over the remaining loops and create a face - then remove it. But I then ran into cases where SU claimed loop vertices where not planar (?!?) . x_X

TIG

@thomthom said:

Not that easy - faces can have holes in them.
I did make a method that will first recreate the face by taking the outer loop vertices, and then iterate over the remaining loops and create a face - then remove it. But I then ran into cases where SU claimed loop vertices where not planar (?!?) . x_X

I successfully use the face-clone method in some of my tools - even for faces with holes.
Get the face.outer_loop.vertices positions and make the cloned face ' nface' then use (face.loops-[face.outer_loop]).each{|loop|...} to make the inner face-holes from loop.vertices positions - e.g. tface=g2.entities.add_face(pts) then immediately remove that face tface.erase! to leave the inner_loop for the nface...
Now you have cloned the 'face' as 'nface' with all of the required holes in it.

thomthom

yea, it was due to the face being pretty much a point that cause my errors.

kwalkerman

This is the same bug I detailed here:

http://forums.sketchucation.com/viewtopic.php?f=180&t=31443&p=276973&hilit=kwalkerman#p276973

thomthom

duh! I even participated in that thread. yay for human memory!

kwalkerman

@unknownuser said:

hmm im somewhat confuses here-why did the face appear to have been shifted to the origin of g1 - instead of preserving it's original position?

I think that there is a problem somehow with the transformation of the objects. Following my instructions in the other post:

http://forums.sketchucation.com/viewtopic.php?f=180&t=31443&p=276973&hilit=kwalkerman#p276860

the end result is that in the outliner, a group is added to Sketchup.active_model.entities. The transformation of the group is equal to the transformation of the original face in it's original group.

Then, when you open the original group for editing, the face appears in its original location.

So, there are two major problems:

when passing entities into entities.add_group, entities MUST equal model.active_entities
the entities passed in retain their original transformation, relative to the previous entities collection, with some strange behavior.

--
Karen