[Plugin] Hatchfaces (v1.8 beta) UPDATED 15-Dec-2012

TIG

Even if you add a new instance in code it will not cut until you specify its glued face.
So just use the existing instance [the converted group] and glue that to the face, as it's already in the right place !!
Why do you need to change the transformations at all?
A group's definition is made at the ORIGIN etc no matter where it actually is.
The group itself can be adjusted using its transformation data like .origin and .xaxis....
Why do you need to involve 'bounds' ??

jolran

Ok forget about bounds for a minute.(I was using it's center as pt for pt vector_to ORIGIN).

Anyway since this did not work at first few tries, I assumed it had relvance with Sketchups behavior in native mode.
The cursor must be at the face to be able to glue to a face=NO transformation on entities.

(You know this I'm sure) If you select the entities inside a component and translate them AFTER components been created.
Then insert a new instance, it won't glue to a face. In fact it will keep the distance from cursor and it's impossible to place it on to a face. You can move it after it's been placed though, but it will not then cut the face.
I provide some pictures to better illustrate what I mean.

BUT! If you say translation is not needed. I believe you. You know more then me about this. Then I will continue to work with your code as it is. This is just a theory I had why it wasent working in the first place.

TIG

Well... if not group.parent==model then you MIGHT have to use the group.parent.transformation.origin and group.parent.transformation.xaxis instead of ORIGIN and X_AXIS which are the model's equivalent - just experiment...

Why would you want to place a hatch-component onto another face - it's custom trimmed to the one face ??

jolran

Ok, I will try that.

@unknownuser said:

Why would you want to place a hatch-component onto another face - it's custom trimmed to the one face ??

I don't want to do that. I was just dragging an instance of the "result" from component sampler to illustrate Sketchup behavior. To show where the "input point" was on the hatchcomponent.

I don't think we are far off a solution anyway, I will keep trying.

jolran

No Go

Using the exact transformation as you provided TIG. It stays in place as you said. AND the instance get glued to the face.
Even tried making a new instance from that definition + transformation. It has the correct position and glues to the face.
But no cutting behavior. IF you test and insert another instance from the component sampler manually, you can see the origin is off.

The problem must be there? Don't know what else to think of. Behaviors should be correct.

My guess is.

tr=reset group.entities transformations to origin(flat at 0). Don't know if have to multiply transformations to do that.
Group.to_component.
Make definitions.
Erase instance.
Insert a new instance with the inverse transformation of tr.

TIG

Are you sure the defn.is2d and defn.cuts_opening = true and defn.snapto = 0
Test the defn to see what these are
defn.is2d? defn.cuts_opening? defn.snapto
should be true/true/0, and then inst.glued_to should >>> 'face'

TIG

The components you are using to compile the hatch-group contents, which will eventually become a component don't need any special behavior - you are adding these transformed anyway, then exploding them etc.
Only the new hatch-group that's to become a component-instance later needs transforming so if it were at the origin then all of its entities are transformed around the 'X_AXIS' so as to be flat within it - i.e. so the 'origin' then has the blue/Z axis sticking out of it. Once you've done that the original-instance [the group >>> component] is now seen to be at 90 degrees to where is was first made on the selected-face [its innards have been flattened], so you need to transform that instance about its origin/xaxis so that now it stands back up again, where it was before; but now of course its axes are turned to suit its new role as a cutting-component's. The inst.definition.behavior is then adjusted so it glues/cuts/is2d=true and snapto=0, but at this point it is not glued to anything - inst.glued_to >>> nil - therefore you use inst.glued_to=face and it now glues/cuts the 'face' as expected.......

TIG

I'm confused too.
After you have added the smiley components and exploded them, then trimmed etc they will have lost their cutting/gluing behavior if they ever had it - which is not needed anyway...

What you have is a group this is 'flat' on the originally selected face.
this group will have an origin given by Sketchup - usually at its bottom left corner - tis equates to the ORIGIN. Therefore we transform all of the group's entities - faces/edges using a rotation transformation centered on the ORIGIN around the X_AXIS and -90.degrees...
If the group.parent != model we take the group.parent.transformation.origin and .xaxis instead ???
At this pint we have the group laid flat with the same axes.
We rotate-transform the group about its .transformation.origin and .xaxis and 90.degrees... so that it stands back up with its axis now so the blue axis out of the face.
Make it a component, change that instance's definition.behavior to glue/cut etc etc and then tell the instance it's .glued_to-face ???

I keep repeating this in tests without problems?? You show me images of the thing before that's cutting when it shouldn't be etc...
Are you sure you are using the right code/references etc...

jolran

@unknownuser said:

I keep repeating this in tests without problems?? You show me images of the thing before that's cutting when it shouldn't be etc...
Are you sure you are using the right code/references etc...

Before smiley is an original. It's a component with cutting behavior.

I'm not sure I'm using the right references. I've tried changing them back and forth a little. It's no big change. My group is called gp.2 and transformation tr4. The thing is I have altered the smiley comp several times before the plugin is about to do your provided rotations. Exploding, entities add to group, intersection, edge removals etc. Maybe I've gone wrong somewhere there, and the axis is off somehow. I will have to do some more tries.
But if you look at the last picture, the blue model axis IS pointing in the face.normal direction. Which is good?

I thank you for your help in this TIG. I have difficulties understanding transformations in code. I thought I got it, but It seams not

Just a theoretical question. IF one would move the group to Global origin, one would have to rotate around each axis no X,Y,Z? To be sure to cover all angle variations.. Hope you understand what I mean.
I will do some more tries, and also see if I have put in your code wrong.

TIG

Deliberately testing off origin and it works for me

jolran

@unknownuser said:

Deliberately testing off origin and it works for me

Yeah, that was a desperate long shot, assuming you did not think off that .

Ok, so now I guess I'll have to pinpoint what goes on with the geometry at each step, that would different than in your model.

TIG

Select a face in the model, in the Ruby Console type or copy&paste face=Sketchup.active_model.selection[0] to get a reference to it - we'll use it later.
Make a standard piece of hatching on that face [it needs to be smiley face type in a group] with no attempt at make it a component, or glued or cutting in code.
Select that group, in the Ruby Console type or copy&paste group=Sketchup.active_model.selection[0] to get a reference to it.
Now run the individual lines of code one at a time on that 'group' - see it's changes.
It should eventually become a component that glues and cuts and is attached to 'face'...

Repeat with a face inside another group.
See if it fails - if it does then try changing the code for the transformation used in the initial group.entities.transform_entities() to the 'parent' version I gave. If that part succeeds but the later instance transformation fails try using something like (group.transformation*parent.transformation).origin etc instead...

jolran

Thanks TIG. I've acctually just done something similar.
Although with the smiley exploded.

I will try your method as well.

What I have discoverd so far is that when turning group to component.
ins=gp2.to_component
The center of component.entities get to world origin(you follow my explanation?)
(I see this if double clicking the component and the axis are shown. PIC)

**This happends with or without your rotations.**Your rotations flips the "blue" axis in the face normal direction, wich is what we want, right? So thats good.

But in order to make the cutting work in think one must move the component.entities center to the face, can't explain it better..
That's probably why it works when I'm doing test at ORIGIN.

In short! It doesent look like something fishy is going on with the geometry UNTIL turning group to component.

Elaborating with group.transformation*parent.transformation might be a good idea. Cause this problem has to do with transformations. The glue to face is working.

jolran

Hmm a second thought. I might have looked at it the wrong way.
The problem is not turning group into component. But Transformations made to entities before that.

And the problems comes from the intersection I think. It uses face-clone group.transformation. And I MUST use that transformation to intersect. So maybe it alters the group.orgin somehow..

jolran

BTW your code works. For testing with a group, not inside my script though

I had to do it a little differently selecting groups. I can understand why your asking youself
what the heck I'm fuzzing about..

Although! the result have the inputpoint at face(like I desired), so that is what I must solve then.

ss=Sketchup.active_model.selection
faces=[]; groups=[]; ss.each{|e|
    if e.class==Sketchup;;Face
     faces << e
   end
    if e.class==Sketchup;;Group
     groups << e
     end}
face=faces[0] if faces; gp=groups[0] if groups


puts face
puts gp
tr=Geom;;Transformation.rotation(ORIGIN, X_AXIS, -90.degrees)
gp.entities.transform_entities(tr, gp.entities.to_a)
### it's made flat
###
tran=gp.transformation
tr=Geom;;Transformation.rotation(tran.origin, tran.xaxis, 90.degrees)
gp.transform!(tr)
### it stands up but...
### we have now corrected the axes to suit a cutting-component
###
### now make it a component...
ins=gp.to_component
defn=ins.definition
###
### make it 'cutting'
defn.behavior.is2d=true
defn.behavior.cuts_opening=true
defn.behavior.snapto=0
###
### glue to the original 'face'
ins.glued_to=face
### it now 'cuts holes' in the 'face'

TIG

OK...
I now see the issue.
Before you do any of the steps I mentioned in converting the group into a cutting component we need to ensure that the groups bounds are reset so its bbox is parallel to the face...
Insert these steps between making the grouped hatch and flattening it.
We find the group's rotation in 3d relative to the main axes.
We rotate the faces in side the group so they lie on the X_AXIS and the bounds are a rectangle.
We rotate the group back so it is back on the face.
tr=Geom::Transformation.new(bbc,zaxis)
where 'bbc' is the group.bounds.center and zaxis is the face.normal will transform the group.entities axes correctly so, then transform the group.bound.center back to bbc which itself should be transformed translated inversed back to the origin...

This is all getting too too complex.
I'll try to write some simple generic code to turn a grouped face that's coplanar to a face into a group that is placed on the face with its z-axis==face.normal...watch this space...

jolran

OK! Now I think I've actually found the problem. And it's kind of a careless and stupid one.

In the code I first make a group called gp2. Then I add the selected component instance to the group.
I do that by it's definition and transformation. Now since I did it in an iterator using e=instance (e.definition, e.transformation) the transformation is using defintion.origin!! I must use another transformation in (e.definition, e.?)

Be back soon

Edited: Sorry TIG I was typing when your answer came, I think this issue is THE problem
Or maybe at least have a look at it before you make a fix. This is happening at the very first in the plugin.

jolran

Ähh.. Nothing seams to work.. I'm trying to add the function to use groups in the plugin. Like the testingcode from TIG.

Anyway, here is the part where the sketchup selection get's turned into groups. ...
Probably some basic faults in here. Would appreciate a cleanup on this.. I do have to add the instance by definition to cents, no? Also the groups in cents don't get exploded.

Edited Well, found a thread about adding groups. So now that feature is added(code changed), but not without issues.. At least one can use groups for 2dbooleans, now. Could be useful.

Did not fix transformation issue, though... My guess is I cannot use the groups own instance transformation?
Very wierd to see groups as instances though. Illogical... lets see what TIG will comes up with..

 if comps ##comps=Collection, array of instances and groups #######
       
        gp2=ents.add_group(); cents=gp2.entities; gp2.name=name; gp2.layer=hatch_layer
		

		
		
	   comps.each{|e| #Add instance to group and erase original.
	       if e.class==Sketchup;;ComponentInstance
               cents.add_instance(e.definition, e.transformation) 
			   e.erase!
			   
		   end
		   if e.class==Sketchup;;Group
		     gp2ents = e.parent.entities
             gp2defn = e.entities.parent
             gp2tran = e.transformation
             cents.add_instance(gp2defn, gp2tran) ### group instances
             e.erase! ### remove original groups  ###################
		   end
	    }
	 ####### Explode everything inside gp2.entities ####
	   cents.to_a.each{|e| 
	       if e.class==Sketchup;;ComponentInstance 
	           e.explode
           end
	       if e.class==Sketchup;;Group
	           e.explode
	       end
        }
	   
   end

jolran

@unknownuser said:

We find the group's rotation in 3d relative to the main axes.
We rotate the faces in side the group so they lie on the X_AXIS and the bounds are a rectangle.
We rotate the group back so it is back on the face.
tr=Geom::Transformation.new(bbc,zaxis)

@unknownuser said:

This is all getting too too complex.
I'll try to write some simple generic code to turn a grouped face that's coplanar to a face into a group that is placed on the face with its z-axis==face.normal...watch this space...

Yes, I feel it maybe be a complex transformation, no? TIG, are you working on something or should I dig in to the rotation part?
I'm still not sure if I'm creating the instances from definition correct. I've split the code up for testing.
After exploding the instances into group B.BOX looks OK.
After intersection and deleting edges still OK.
It's when turning group.to_component the B.BOX reaches to ORIGIN.
I've already shown this in picture, just doublechecked it again..

Although! If I manually make component from group at each step described. In Sketchup, the boundingbox reaches to ORIGIN. So that's why I'm wondering if the instances has been created improperly from the definition, regarding the transformation.
Once again: When saying B.BOX I mean entity bounds from doubleclicking the component.

jolran

BTW. Is there any possibility to explode the instances first thing? Collect the exploded entities and put them into a group, before they merge with underlying entities. I know there are some issues in this field.. Don't have time to test that right now.
But maybe that would be better than messing around with definitions and transformations..

After surfing info in this forum, I think doing above is not possible.. Not without trouble anyway..