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

TIG

One thing it'll do with ease is 'tiling'!
Ages ago I started a tool that never got finished - uni-lecturing intervened...
Cross-hatch at the required centers - paving, wall tiling etc.
For complex tiling - e.g. with wide joints, or different size parts, or interlocking shapes - then use the newer ideas of 'component-hatching'
All it needs now is an extra 'tool' to set the 'origin' of the hatch pattern...

TIG

When you have a group finished use gtr=group.transformation to use later
Then you need to move the group to the origin, and transform all of its edges' vertices [uniqued] so its 'flattened' in plan. You'll need to trial some code for this
Then use inst=group.to_component.
Then use defn=inst.definition and change the defn's behaviors to make it a 2d/gluing/etc thing.
Also set the defn.name=???? etc
Use inst.erase!.
Transform 'gtr' to suit what you had to do the 'flatten' the group...
inst2=ents.add_instance(defn, gtr) to place an instance on the face back where the group was.
inst2.glued_to=face to cut the face.
Set the inst2.layer=??? etc etc............

EarthMover

@jolran said:

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.

I can see how you have reached a fork in the road, with many paths that this plugin could take from here. I would say pick a direction and stick with it. (Mainly so I can get my hands on it quicker. )

I'm thinking the simpliest, yet most practical path would make the most sense and probably be the most stable and workflow friendly.

I would like to see user defined patterns as I said before, which could be stamped into underlying geometry.

What would be ideal is a way for user to say for example, create a small section of brick pattern, 4 brick by 4 brick wide and accounting for the pattern (half brick on the offset bond).....then save that as "Brick Bond 01" or something. Then using your tool, it would ask the user the size of the stamp / hatch. If the stamp / hatch was set to 3 meters by 3 meters, you would visibly see a 3meter square plane appear on the cursor with the brick pattern tiled across it. I would think perhaps centering on the cursor, similar to the sculpting tool in Artisan or Sculpt Tools and have it conform to the direction of any give face. Then you click and stamp the pattern / hatch into that face. You could use predefined preference settings to set whether you wanted the hatch to intersect or remain a group, instead of bringing up a dialog box for each click of the stamp. Or define it by means of a toggle (Ctrl or Shift key). I'm envisioning taking a simple four sided house and just rotating around and clicking on each face with a brick hatch selected, then switching to a roofing hatch and laying down shingles. Essentially it would be as easy as dropping in a texture, but be ultra beneficial for B&W presentations and interacting with Sketchup's styles. Now that you have materials working as well, that opens up a whole other door of possibilities.

Thanks to TIG as well in this group endeavor.

jolran

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)

jolran

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.

jolran

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.

TIG

A group can have gluing properties [as that belongs to a definition], BUT it can't be made to 'cut', because you can't set its 'glue_to' as it's not an instance [at least I think that's right...]

jolran

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.

TIG

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

EarthMover

Why not create two separate methods to handle the Z fighting based on what the user wants? If the user chooses just a hatch, then doing a 2mm offset would be fine and eliminate the issue with Z fighting. If it's a stamp, then make is flush and the explode/intersect should get rid of it. If the hatch gets put on it's on layer, it can be toggled on and off that way and won't interfere in general modeling operations.

jolran

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

TIG

If it's a cutting thing you can always explode it when your happy.
I think that a Setting-Out-Point fro the hatching would be a big boon...
Still testing ideas on the whole cutting issue...

TIG

Here's how to make the group into a cutting component...
I know you've probably used different reference name but here I call the originally selected face 'face' and the group you've ended up with containing the trimmed hatching lines/faces etc 'gp' [Note a cutting components will make a hole the size of its perimeter edges so you need to remove any outer perimeters if you want a series of cut pieces... OR keep the outer perimeter equivalent to that of 'face' and make any 'un-hatched' areas of face within the hatching-group with the same material as 'face.material' so they look equivalent???]
` 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'

now set names/layers/etc

for the definition and instance

defn.name='????????????'
ins.name='????????????'
ins.layer='????????????'
###`

jolran

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!

TIG

The group becomes a component, that component can glue/cut.
When you add an instance manually the face you snap to is taken as the face the instance will glue to.
However, in code the instance is just sitting there unglued on the face, so you must tell it which face it glues to with
ins.glued_to=face
Obviously the instance needs to be on the face to work properly, BUT in our code it is anyway so we don't need to move or transform it to suit - as we might with other less specific code...

jolran

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!

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.