Excellent TIG!

So far so good! Havent failed yet. Works in off axis, strange rotations etc.

Needs some more testing of course, but THANK YOU! THANK YOU!
Things can probably move forward now.

Oh Yeah, and the code is much more streamlined, as you call it.

A lot of experiments going on. I welcome ideas and possible options that could be added or improved
look at the dialogs what is planned, already.

Got the tiling going pretty nicely. (Not from file yet) It's quite slow if having complex patterns. Fewer (tile) copies is considerably faster regardless of the sum of edges So crosshatching may be restricted to linehatches only. Rather create more patterns=larger library than doing a 2nd computation? Patterns with faces is slowest.

Since the goal is to have a big library of hatches, they may be difficult to remember by name. So I guess webdialog is the best solution. Im not to sure about that one yet, though. Havent done any webdialogs, yet. It might be a very step learning curve to get it right for all plattforms On the pic there is a inputbox version with dropdownlist. For round 1 that might be the solution, there are a lot of quirks to sort out first..

http://sketchupapi.blogspot.com/2011/07/gofaster-parameter.html
FYI: saw this post on API blog and performed som tests with this method(not the pic, more complex pattern), and boy what an speed increase!
On test 1: 5.226 seconds
On test 2: 2.793 seconds! Just typing "true" in the model.start_operation('bla bla', true)
On test 3: 2.496 seconds. Same test as 2, but outliner closed.

There are some issues with this method though..

http://forums.sketchucation.com/viewtopic.php?f=180&t=25305

This is of course interesting as well. But maybe before doing any performance increases I will work on the features.

@unknownuser said:

Speaking of which - does anyone have recommendation for good learning resources, that I might at some point get to asking useful questions?

Well, this forum

Depending on your level of expertise, Automatic Sketchup is a good start.

http://www.autosketchup.com/

After some testing. I've only had 1 incident so far when the axis.center wasn't on face, on an extreme angle. Otherwise it seams to be working

Now, when axis align better on face(thanks to TIG), one can explode and the materials merge on face underneath more consistent.

It's a perfect modeling tool.
Textures will transfer as well. And I suppose the option of saving a component with textures gives many possibilities.
There are some experiments to be made, to see what can be done....

@unknownuser said:

I threw it together to show it was 'do-able'...........quote]

@unknownuser said:

I'm absolutely sure we can streamline this code a lot -

Honestly, I don't know if I can be of much assistance in that regard. There's so much going on with rotations and stuff I get a migraine. I can of course try, but just by touching the computer you will beat me to it

So, you don't think theres any trouble in the starting of the script, where I create the instances from definition?

Do you want my sample W.I.P code to see if there is trouble elsewhere? It's without menys and linehatching..
And quite documented..

@unknownuser said:

You seem to be invoking it at a weird point

I don't know. At the end? As a definition passing group and face. Maybe thats wrong timing..

Are you testing at ORIGIN by a chance? Or does it work for you in all positions? Another pic..

EDITED After some rigorous testing, I have a strong feeling the entities inside the group is off according to the group. Must experiment more with rotation axis etc, but time is running out for this.. Must move on.
Give it another day..

I trying to understand what you are getting at. The cutting behavior is still not working.
Unless face is on "ground" an I apply NO transformation or O rotation(same thing).

Blue Z axis should point in the face.normal direction? To have a chance invoking inst.glued_to=face
Well It does, after your rotations, and the instance is glued to the face.

But must not the World axis origin be at the instance to get cutting behavior?

To do that: move group to global(world?) origin. Reset any rotations= group made flat. THEN make instance from group and move back to face?? I know it sounds strange but why is the inputpoint at orgin if inserting an instance(copy) of the result?

TIG, yes I got true on all of those.

Did a little test! Placed the face at origin and the component on top. Changed the transformation to 0 rotation=NO transformation. Transformation is not needed when placed on ORIGIN, of course. Did the test on both the created component instance, and on a new freshly inserted instance. And voila it glues, and cuts the face.

Test nr2 I removed ANY transformation made on the component, (after group.to_component).Still on ORIGIN.
And it worked as well??? Of course this only works when the component is lying flat at 0 position.

Is this some sort of bug? Cause I get the impression you can only invoke cutting behavior IF you do it on 0,0,0 and 0 rotation= ORIGIN

Maybe the problem has to do with what position you create the component from group(group.to_component).
And it's position relative to insertion-point.

SO what's the fix? Transform the group to ORIGIN. Make the comp and remove it back to where it was?
Seams a very strange solution but can't figure out the logic in this one..

I guess just have to find a transformation that get the group to origin flat from ALL postions, do the behavior and transform back with an inversion of that transformation.

**Edited:**As it turns out TIG's rotation transformation is all that's needed(first rotation), if it only get's translated to the ground at 0.
Now, this must be done in 1 transformation OR multiplied because I am going to use THIS transformation.inverted to get back to the face. PFFIooUUH. Don't have a grasp of this transformation stuff yet. It's quite complex to understand when doing multiple transformation's.

Talking to myself mostly... Another pic(will delete older pics later on, in case I'm overusing this function a little to much).

I think we are hitting some bug here. Isent this strange behavior?

Going through your script trying to get a grasp on it. It's comparing axis to vectors a lot, no? I wonder would it be more predictable to use crossproducts where possible? I don't know, from for ex face.normal? Just a wild guess.

Much better TIG!
There are still some issues. Pic says all. Now I was gonna put this "is as" a method at the end no, passing arguments? There won't be any problem with putting declarations inside a method I persume. I mean for ex model=Sketchup.active_model..

It works perfectly on Y axis. X axis it flips upside down. Off axis, a little troublesome..

The definition has quite a lot of transformations might take a while before I understand what's going on, and can track issues.

Performance is good. Havent tested on super heavy geometry.

Yeeehhaaa TIG!! BIG job from you. Thanks a million+ times.

That's quite some extra bit of code. We will have to see some performance tests when/if I manage to add this.
Already the plugin is quite processor intensive, doing all the iterators face_classify, erasing stuff etc..We won't know until tested.

In general, do transformations put a lot of strain on the calculation/computation?

Anyway, thanks again. This will be interesting to test.

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..

@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.

Ä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

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.

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'

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..

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.

@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.