Get rotation(transformation)

[kyyu]

@jolran said:

Hi Kyyu!

Interresting. So you mean I use the 3rd vector for measuring? Or was it meant to be
a method to get an angle 45 deg of the vector?
Remember 45 deg is just an example for this particular hatching. The user must be able to
choose any angle for the lines across the face.

I will look into it more and see if I understand you code a little better.
Thank you Kyyu.

The 3rd vector would be your translation vector. In your code you have it as:

vector=diag_vect
vector.length= user_length

It's perpendicular to what ever your final line is. Here, I just changed the line to a random new angle, not 45 deg. I set the length of the vector (distance of translation) to 1.

[jolran]

Translation vector? The translation must be on the diagonal or the lines wont cover the whole face.
I already have the rotation of lines, copy/translation set up. Except that the "bug" is that
the translation distance doesent get 100% accurate if the face is very distorted.
Maybe that is what you are trying to fix, and I don't see it.
If thats the case sorry I'm a noob, you know.

The angles of lines on the picture are the identical. Although they don't appear to be.

[jolran]

Hate to bother again, but I've been going on all day and intersect_with is troublesome.

Tried TIG's combo, and others but I think I'm making a fundamentional fault.
Doesent intersect_with work with nested groups?

tr3=Geom::Transformation.new()
face_group.entities.intersect_with(recursion,tr3,face_group,tr3,true,[hatch_lines_group])

[TIG]

If you read through the way I did it... I make a hatching group then simply add a face and overly long hatching lines to it, intersect everything with each other, erase the faceless edges outside of the face perimeter and then erase the faces too. I never use subgroups - if you want to then just explode them...
You are better off transforming points/vectors and drawing the edges that grouping things endlessly/needlessly it'll be slooooow

[jolran]

@unknownuser said:

I make a hatching group then simply add a face and overly long hatching lines to it, intersect everything with each other, erase the faceless edges outside of the face perimeter and then erase the faces too

Aha! Did not quite understand what was going on.

Yes, yes I will TRY to do the same. That way I will learn the right way. Slow doesent sound good

My resulted line_groups apears pretty fast on screen for the moment though, and its possible to make
a manual intersect with selected. But a lot cooler if it is manual.

[kyyu]

@jolran said:

...Except that the "bug" is that the translation distance doesent get 100% accurate if the face is very distorted.
Maybe that is what you are trying to fix, and I don't see it.
If thats the case sorry I'm a noob, you know.

Yes, that is what I am showing how to fix.

[TIG]

Where my script does a transformation.rotation on things simply using 45.degrees so it your user inputs an angle in a dialog as a 'float' - e.g. 12.5 use - angle=results[0] and spacing=results[1] (or whatever your dialog returns) and then in the transformation.rotation use angle.degrees instead...

[jolran]

Great!! Will try that. But? That correction will just be a fix for the dialoginput, no?
I havent gotten that far yet

Or maybe you mean your advice WILL fix missing geometry in the corners in certain angles)? Cause thats what bugging me, atm. I was only using Int's changing the angles and spacing.

Maybe that face.normal rotation of yours doesent work in all angles? Unless som serious fix?
Then using grouped edges might be more suitable, what do you think?
I'm not questioning anything, just don't know wich way to go.

Thank you TIG.

[jolran]

BTW. The splats in my script was probably coming from the outliner open.

So Hmm. The direction I'm taking now is using edge_group_copying(my original idea). I cannot modify TIG's version due to lack of understanding. Not sure it will work like it is. But I'm a screwbie with bad solutions, so TIG can probably just wack in something just like that to prove I'm wrong

But I will try to use the face normal to align my copies like in TIG's script, just to
have something to work on.
And use Kyuu's example for getting better accuracy with the distance between copies.
Methods for each view/axis would prob. make the script unnecessary long.
ABout adding groups. Sketchup doesent like it when your inside a group in model mode-
select a face- then by code add a group?

No suggestions I suppose?

[jolran]

Ok! Thats very nice Kyyu!

Will rework your advice. It looks like a smart solution. But I'm pretty confused right now...

I managed to get the intersect_with working in "my" code. It hatches as it should do in the X,Z-axis, although with the distance-error, your trying to correct. However selecting a face inside a group in Sketchup and running the script gives a constant bugsplat. So I don't know if I should go forward an do the other views yet. Does not feel solid.

I'm also worried going against TIG's advice with using groups hey-wild, but I can't implement his code into mine. It's to complicated to understand for me and can't get it to run properly.

IF I can get the problem with creating hatches inside Sketchup model.groupes, and the distance between lines can be fixed, I think the performance would be OK with my version. But maybe the problem cannot be fixed other
than rewriting everything as TIG says..
I'm not lazy, just dumb..

[jolran]

Ok, take2. A little bit forward. Baby steps.

So I've been going trough TIG's script 2 days now and I think I understand it better.
It's of course much more sofisticated an more effective than my intentional idea,
not surprisingly

vp.length=di*2
      tot=0
      until tot>=di*3 # fixes -45 deg. corner issue

Made an adjustment to line 27 di*3(was di). It's an until.statement, where it keep copying the edges on an offset until the "offset-amount" has reached the length of the diagonal?
(Hope I got that right..) So by multiplying the di by 3 it will get those extra edges
needed to cover the corners with steep angles. Extra calculation YES! But needed.

Have not fixed issues of spacing. The spacing is OK when kept around 45 degrees.
But gets narrower when the degrees amount goes "away" from the original amount.

MOST cases doing hatches one uses 45 degrees anyway. -45 and 45 degrees.
So I will go ahead and try too make the ver1. UI now.

---

[jolran]

I'm getting it to work almost.

@unknownuser said:

vector.length=20.0

The copied distance will always be desired length on the vectors line, but depending on the angle of diagonal the edges will not be same distance apart. So I guess I will have to do another compensation? Or is there some Quick fix like the last one(thank you TIG)

I'm guessing will have to do a comparison between Diagonal, user(desired angle, here 45 deg) and somehow
compensate the copy distance for that. Boy this is hard..

mod = Sketchup.active_model # Open model
ent = mod.entities # All entities in model
sel = mod.selection # Current selection

=begin
TODO
Wrap in module.
Get proper names. Shorter strings.
def methods for different Axis. Name them as SU views.
After Inputbox call appropriate method.
Use instance or global variables, necessary?
INPUTBOX promt; Hatch line degrees, distance between edges.
Extras; Background color, keep background?
Intersect with method.
=end



face_group = ent.add_group(sel)
Sketchup.active_model.selection.add( face_group )

bbox = face_group.bounds

bpt1 = bbox.corner(0)
bpt2 = bbox.corner(1)
bpt3 = bbox.corner(2)
bpt4 = bbox.corner(3)
bpt5 = bbox.corner(4)
bpt6 = bbox.corner(5)
bpt7 = bbox.corner(6)
bpt8 = bbox.corner(7)

pt1 =bpt1
pt2 =bpt2
pt3 =bpt3
pt4 =bpt4
pt5 =bpt5
pt6 =bpt6
pt7 =bpt7
pt8 =bpt8

# get center, diagonal vector directions from bbox
# mesure angle between x and diagonal

x_cen = bbox.center
x_diag = bbox.diagonal
x_vect = pt1.vector_to pt4   # horisontal X-axis line
diag_vect = pt1.vector_to pt6  # vector across
x_ang = x_vect.angle_between(diag_vect).radians   
user_input = 45   # Will get shorter alias
user_length = 20.cm # Will get shorter alias substitute for cm? Must work in inches.


h_group =ent.add_group()
line_group=ent.add_group() ###==new empty groups
line_group.entities.add_line(pt1, pt6)

# rotate and reset parallel to X
tr1 = Geom;;Transformation.rotation x_cen, [0,1,0],(x_ang).degrees
tr2 = Geom;;Transformation.rotation x_cen, [0,1,0],(user_input).degrees
ent.transform_entities tr1, (line_group)
ent.transform_entities tr2, (line_group)

cop_dist = x_diag/2   #copy distance/2 copies from center to top corner
cop_times = cop_dist/user_length   
    
vector=diag_vect
vector.length= user_length
gp=line_group
groups=[gp]
cop_times.to_i.times{|i|
tgp=gp.copy
tgp.transform!(Geom;;Transformation.translation(vector))
gp=tgp
groups << gp
} 
#my_transformed_vector.length=20.0   



   

[jolran]

I finally got TIG's version going(forgot to comment out #def.self when running it in R.code.editor, amanidiot!)
SOme funky thing going on when changing hatch_angle. But its stable and works in any axis.

Not what can be said about "my" script. A bit unstable, until the intersectionpart.
My intuition tells me doing copying edges within groups + intersection gives more predictable hatch_result when rotating hatches. But is alot more unstable when gathering and erasing?

Plan A: Stop whining and get the work done so Layout-users finally have a hatch-plugin

Plan B: Adjust TIG's script so it works in all angles, with menus and such.
(will be difficult, since I don't totally understand it yet)

PlanC: Continue to work on mine(a bit egoistic but I won't learn from copy/paste), integration as much of TIG's script as I can, thus make my script more stable if possible.
However. That might not be possible, and I would have to do at least 5 different methods for views.

I guess I'm asking if there is any pointers for things to avoid that make this script crash.