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

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.

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

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.

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.

Hah! Sofisticated! That's why I did not see any translation.

I understand what you are saying, but must not you add a new instance to get the cutting behavior? Therefore translate as well to orirgin, and put on
an inverse transformation on the new instance?

I'm not getting any effect. Could of course have made some misstake when I incorporated your code into my script, will doublecheck that.

Anyway, I will experiment a little with your code. I'm very happy with your rotation script. That's the part I was stuck on. Just had to put on a vector translation to get to origin(bounds.center to ORIGIN). Wonder if one could use that as inverse.transformation though?

On with the testing!

Thanks!

X_AXIS, Z_AXIS, Y_AXIS. I've totaly missed those symbols.
You should see my code for retrieving the X axis comparison... Oboy, what a rookie....

You know. In the API the examples use small letter for stuff like x.axis etc. I though they where aliases and not acctual symbols.

I like your code, nice and clean. This could work I have already put in the defs and behavior, so I only need to change the transformations.

It's only face who cuts no? Maybe that's what you mean. Anyway, that is the behavior desired.

Will try now. Thanks a lot TIG!

@unknownuser said:

I think the cutting compo is best.
Let me 'sleep on' the best arbitrary-placed-group>>>cutting-compo idea

Yeah, that sounds very nice, much appreciated. I think we give this cutting thing another go.

Meanwhile, I will work on solving the crashes with nested components. It's irritating business
Have to restart Sketchup everytime, after running the script.

Eartmover. Thanks for your suggestions. I'm glad some potential users of this plugin is acctually responding, with requests and solutions. Your ideas will be Plan B. And what do you think about an option that the geometry explode on the face, as well (In case we go for plan B). As a modeling tool.

Bum

If you know a"simpler" method of getting things to the origin other then how I do it(if you understood my explanation earlier), I woulden't mind continue trying with the cutting behavior. Otherwise, what do you think? Go 2mm? To get thing's going? There is more stuff to add.. I trust you experience with plugin-developpment in this.

Thanks.

Yep, Nice house. Will try your plugin as well.

I don't know. Been far busy just coding and not acctually testing the plugin. After some testing now, I'm accepting the workaround to move the geometry 2 mm from face, more and more(To get rid of the Z-fighting). Not because it's a quick fix. But it bothers me that a new component gets added each time a boolean is made. I guess this behavior cannot be transfered to groups? I know groups can have some ordinary attributes in Sketchup compared to other softs, but behaviors?
Worth exploring.. It's getting quite computable as well. Doing tiling could crave a fast computer if patterns are complex.
And doing this extra group to components and behavior-translation stuff might be over the top.

Other peoples opinion regarding this workflow would be of value! Earthmover has already come up with some good points.Remember if result is 2mm from face it cannot be exploded without moving it back, of course..And from a side view, the edge would look thicker. Certainly if one want's to put the hatch on the face that could be an option as well.

Think I'm trying to make things harder than they should be.

So far I've been comparing face normals, cross products, and vectors vs axis to transform to Origin. And it finally works, exept when the 2dshape is flat on the ground. Then the vector cannot make any comparison cause it has the value 0.

If I recall this is the problem we had before with linehatches, and had to incoperate a comparison to an edge. So I wonder do I have to do it this way to get the 2dshape flat at orgin, or is there some easier standard way? TIG?
Translation was easy. bounds.center.vector_to orginpoint and then set that length and direction.

If I call the group.origin I get 0,0,0? Must be local.. SO I'm working on the entities_transform method.

Moving the result in face-normal direction 2mm is looking very tempting at the moment.

Thanks TIG! I needed a push. Will make it work with your suggestions.
Was very stuck with transformations, wich I imagine is an easy task for you.
There so much information to suck in as a newbie.. Things get forgotten quickly.

I was thinking of adding tiling as a separate part of the tools. From a library/file. Maybe that's what you was meaning.
Then one would get 3 icons. Linehatching, stamp(manual stamp), and pattern/hatch(tiling from file).

@unknownuser said:

Ages ago I started a tool that never got finished - uni-lecturing intervened...

I imagine you have quite a few scripts lying around

A little side question. How the heck do I turn on comments on the API-site?
I've signed in and everything.. It feel's like there is a lot of information I'm missing.
Searched for info about id 2 days now.

Those are some good suggestions Earthmover! I'd be careful using inputpoint's and observers on this plugin. It's computing geometry a lot. But will never know until tested of course! Thanks for the suggestion. If I can get the transformations going + the face-cutting behavior, there might be a test release of the plugin. I bet there will be some issues to deal with.
Also need to rearrange the script quite a lot.

Thanks!

And yes, TIG's been very helpful(worth mentioning again)

Earthmover, there sure are some possibilities for this plugin. I'm a bit conserned about the performance ATM. There can be quite a lot of objects that need to be computed, when using sofisticated pattern. And files WILL get bigger.
It's not vector graphics. But if the plugin get stable enough it will probably be useful for some peoples.

Having problems transforming the group to ORIGIN. Must be doing something completely wrong..
I'm supposed to transform the group and not the entities therein?
Another read up..

@unknownuser said:

changing its behavior to 2d/gluing etc

Is it enough to change the behavior of the component and glue to face to get it cutting. Or do I acctually have to insert
a new instance? Like in Sketchup modeling.. Guess I will figure that out if I get the transformation working.

Another discovery.

Strange enough exploding the group now, transfers the material onto the face
I wonder if it has to do with the fact that the edges has been trimmed to fit the face. Or rather like before, when exploding a face onto an edge or vice versa had to create a new face=materials lost?
Anyway that is not a bad thing. Maybe cutting behavior is not needed. But then again, the hatch must be merged to the face and might not be so desirable..

PS. Could be used as a modeling tool. Starting to look like something that french guy Pilou created...

Heh So that what it was.

Hmm ok, will see if it's worth the effort. I kinda know now why you recommended moving the component a few mm to get rid of the issue. And doing that, it can remain a group. Working on it.

Yep! OK! Will probably have to do that. Even at 3mm from face there where still some glitches at certain viewing angles.
Don't want to get to far from the face. Some people might not like that, for aligning and stuff..

Thanks TIG! I have o good Master

Yes it's done TIG! It's supposed to be colored for special hatches or design tool etc..It will be like Vector in
Layout.

Move the face 1mm in face normal vector.. Hm Yes that is probably easiest. I was thinking of converting to component and
put on a cutting behavior, to make it more perfect. Maybe overdoing it. Things must be stable first.

Thanks for your help in this.

More tests. Overlapping components get intersected well. It's quite computable.. So one have to be careful not to overdo it I think.. We will see...This is all in 1 go. But I suppose one can split the computation up in several goes.
When I come and think of it. This is a 2D boolean!!

YEEEEEESSSSSSSS!!! ATM I am VERY happY!!

I'm sure there are things tome come that will put me off. BUT at least it's going forward!

I made the misstake of putting the collection of edges BEFORE the intersection. Had some problems with classify points to
edge removals. Anyway look at the picture! It has curves and circles to, with materials.
Now. Must convert it to component, so faces will cut underlying face and materials will get cleaner.
That's for tomorrow!

Hang on! Edge.end and edge.start is vertex objects. I can't use them as point when using face.classify_point()???
In the API face.classify_points needs points as arguments.

How come I get a result from array.length? Strange... Or is there some equallity between points and vertices I'm not aware of?

Edited apparently I get some edge deleted. Almost there I think! Only did comparison against face. Maybe need against
other entities as well.