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

jolran

The "earliest" place where I can insert gents.erase_entities(faces2go) without erasing the access to face.plane is:

tr=Geom;;Transformation.rotation(pt,face.normal,@angle.degrees)
       vp=ve.transform(tr)
        vp.length=di*2
         vs=face.normal.cross(vp) #spacing vector perpendicular to hatch line
          gents.erase_entities(faces2go)

The result is not correct. Missing edges and too short.

Is face.plane or any command referring to "face" using the inner-hole faces, perhaps?
Should one use gents.entities.face(or something to retrieve the face.entity in gents) instead of just face?

TIG

You can set variables plane=face.plane and normal=face.normal and pt=face.outer_loop.vertices[0].position, then face.erase! - the variables are still remembered... then use them later as needed ?

jolran

@unknownuser said:

You can set variables plane=face.plane and normal=face.normal and pt=face.outer_loop.vertices[0].position, then face.erase!

Ok. You mean before faces2go << face? After erase.faces2goI was going to define the
linehatching as a method for crosshatching, as we discussed earlier. They will have to be instance.variables then or do I pass all of them into the argument-list when calling the method?
That's why I was wondering if one could use face from gents.entities, since gents will be passed into the args-list anyway.

Or did you originaly mean I should put the whole operation into a method for crosshatching?

I'm sorry if I sound confused. But I am.

TIG

All this part is trying to do is set the vector from which you will set the angle for the hatching.
At the moment it's set from the vertices [0] to [1] vector which varies, so to fix it I suggested a way of projecting the x-axis onto the face.plane and getting a vector from that to use instead [with changes for a plane that doesn't play nicely with the x-axis to give a valid vector...
You get all of this from the original face NOT the temporary face ??

jolran

@unknownuser said:

You get all of this from the original face NOT the temporary face!

Yes, that part I understand(hopefully) what it was about to fix for problems.

However when you said I can't get the plane or normal of an erased face, I thought
order matters. I think my english is a bit bad, I don't understand everything right away. Apologize for that.

Lets say I use ORIGINAL "face" for face plane, I still must pass "face" on in the argument-list if I am going to
have following script setup, wich will be needed for crosshatching later on, no?

Feels like I'm doing some fundamential misstake here.

(edited)It should be "face" in the argument list. NOT faces.

jolran

Think I got! @face=gents.add_face etc..in tha Face creating-part And use @ varibles in the code below seams to do the trick!
It works on holes anyway. Don't know how kosher that is TIG? It would get into the linehatching method.

jolran

Works with holes..

test forVer1.4.jpg

TIG

It seems to work now - is the angle always more logically oriented to an axis rather than an edge of the face ??

As @face is a reference to a face before you run hatch and you erase it afterwards you don't really need to pass [@]face as an argument because @face is an instance variable read across methods, but if you do it'll probably still work...

Also you [mistakenly] show a space in the def name AND started it with CAPITAL letter - use 'linehatch' or 'lineHatch' or simply 'hatch' or even 'make_hatching' etc which are all just fine... call it with self.hatch(aa, bb, cc) or whatever it's called...

Use a @xxx variable where you want to use it across several methods [def's]
Pass arguments to a method when you want to reuse the method with changes to arguments without using @xxx as you want to keep that for later - e.g. the @angle etc IS reused next time you use the dialog so when you pass angle again you use @cangle for the crosshatching angle but want to use the same method again...

jolran

Thanks for all your help and advice TIG!

I will follow them.

@unknownuser said:

is the angle always more logically oriented to an axis rather than an edge of the face ??

Don't know

So I'll update the plugin then? All OK?
Will work on the crosshatching later. I think it is a good idea to get this fix out, so people can use this plugin
more properly.

This coding-testing burns more calories than a 2hours jogging in the forest

TIG

Test it on a cube's faces and a copy/copies of that cube rotated oddly in 3d to see what the hatching angles look like ??

jolran

Crap! It always hatches in the axis. Doesent matter if the cube is rotated or not.

OK. for tomorrow then... sigh... I hope you will come to the rescue again
I'm guessing -transformation to axis something?

I will never get to experiment with NEW features!!!

It put the ver 1.4 update up anyway. Think it's better than it was before.

sergey2402

It's just great!
I see - this is a very difficult job.
But now I am a real bad guy. I see only flaws!
(I’m sorry )

jolran

Sergey. No need to feel bad. It's good if you report anything suspicious.

The hatchgroup is created on Hatchlayer. The edges are created on the "active" layer.If you want ALL hatchline-geometry on "Hatchlayer". Just create one hatch(to add the hatchlayer). Delete it.
Select Hatchlayer as active layer, then ALL lines will get to that layer.

If we go back to the problem with hatchline alignment. Yesterday's update (TIG code)fixed the problem with ngons or to call it "asymmetrical" faces .

I thought about this. I think the best solution(if doable) would be to do an additional edge selection.
Where hatches get aligned to that edge. Something like if selection.contains edge, the vector will be created from that edge and override current solution. Eg if only face is selected hacthing will be done as current "on axis solution".

I do not think this problem can be solved by an automatical solution(hope I'm wrong), cause faces can be created in so many different shapes. What edge should hatching be aligned to and so on..

sergey2402

Angle of Hatching

jolran

That is true Sergey!

Should be an relativley easy fix. For TIG that is For me, everything takes time..

jolran

Hmm. GRRRRoin
The problem from yesterday is worse than I thought. Linehatch direction gets switched in different axis.
That is probably what TIG was reffering to. In my over-enthusiastic mood I did not notice that.

So my only conclusion is that an selected edge MUST be included in the calculation of hatch.angle.

jolran

Trying something. Comments are VERY welcomed. Have selected the face and 1 edge.

Can retrieve the edge like this.

@h_edge=ss if ss.class==Sketchup;;Edge

And if using the edges points to make a vector, I've tried @h_edge.line. Did not work. This does not work either.

pt=@h_edge.start
p1=@h_edge.end
ve=pt.vector_to(p1)

Main goal is to make a condition: If an edge+face is selected run this code. If only face is selected run the axis code.
Of course only 1 edge can be selected.
Bad idea?

TIG

The problem with the idea is that currently it processes all of the faces in a selection, if you have one edge selected it won't necessarily lie on the plane every face processed ?

My way uses the x-axis [usually] to determine the start vector [projected onto the face's plane] from which you angle off the hatching edges...

jolran

Ahh, you mean multiple face selection? Yes I see, that will not work of course.
I don't see it as a big limitation that only 1 face could be processed at each time?
Or faces on the same plane, wich is probably the most common case?

Edges get drawn a bit irregular atm.

jolran

If selecting face and edge I can only get an array, not the edge as an individual edge selection?
Even if doing a ==Sketchup::Edge thingy..
Must I use a selection observer for this?
Would be fun if I could even try this method out, but stuck on basic things..