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

TIG

This code takes any 'flat' 'group' drawn on a 'face' [that's at any orientation] and turns it into a gluing/cutting component... it needs completing for the name/layer etc and also testing for nested groups... You also don't need the start/commit operation code as it'll be inside another set - it's put there for testing separate from the main code...

### turns the 'group' into a component glued/cutting 'face'
def g2cut(group, face)
  model=Sketchup.active_model
  ###
  model.start_operation('g2cut')
  ents=model.entities
  pents=group.parent.entities
  gents=group.entities
  bb=group.bounds
  bbc=bb.center
  norm=face.normal
  if pents==ents
    xaxis=X_AXIS.clone
    yaxis=Y_AXIS.clone
    zaxis=Z_AXIS.clone
  else ###??? unsure if we need to redefine for nested groups?
    xaxis=X_AXIS.clone
    yaxis=Y_AXIS.clone
    zaxis=Z_AXIS.clone
  end
  ve=group.transformation.origin.vector_to(bbc)
  tr=Geom;;Transformation.translation(ve)
  group.transform!(tr)
  tr=Geom;;Transformation.translation(ve.reverse)
  gents.transform_entities(tr, gents.to_a)### centered
  tr=Geom;;Transformation.new(group.transformation.origin, norm)
  group.transform!(tr)
  ve=group.transformation.origin.vector_to(bbc)
  tr=Geom;;Transformation.translation(ve)
  group.transform!(tr)
  tr=Geom;;Transformation.rotation(group.transformation.origin, group.transformation.xaxis, -90.degrees)
  gents.transform_entities(tr, gents.to_a)
  ang=xaxis.angle_between(group.transformation.xaxis)
  tr=Geom;;Transformation.rotation(group.transformation.origin, zaxis, ang)
  gents.transform_entities(tr, gents.to_a)
  pt=gents[0].vertices[0].position
  ve=Geom;;Vector3d.new(0,0,-(pt.z))
  tr=Geom;;Transformation.translation(ve)
  gents.transform_entities(tr, gents.to_a)
  gents.parent.invalidate_bounds
  bc=group.bounds.center
  ve=bc.vector_to(bbc)
  tr=Geom;;Transformation.translation(ve)
  group.transform!(tr)
  ve=group.transformation.origin.vector_to(bbc)
  tr=Geom;;Transformation.translation(ve)
  group.transform!(tr)
  v=ve.reverse.transform(group.transformation.inverse)
  tr=Geom;;Transformation.translation(v)
  gents.transform_entities(tr, gents.to_a)
  ### make component
  inst=group.to_component
  defn=inst.definition
  be=defn.behavior
  be.is2d=true
  be.cuts_opening=true
  be.snapto=0
  inst.glued_to=face
  ###
  ### complete these items...
  #defn.name=
  #inst.name=
  #inst.layer=
  ###
  model.commit_operation
end

jolran

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.

jolran

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.

jolran

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.

jolran

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?

jolran

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.

TIG

I'm absolutely sure we can streamline this code a lot - I threw it together to show it was 'do-able'...........

jolran

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?

jolran

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

TIG

You seem to be invoking it at a weird point - use it after all of the other processes leave the exploded-instances/trimmed group...

jolran

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

TIG

Here's some shorter updated code that I think now works better to make a selected 'group' that has its faces overlaid onto a 'face' into a cutting component...

### turns the 'group' into a component glued/cutting 'face'
def g2cut(group, face)
  ###
  model=Sketchup.active_model
  ###
  model.start_operation('g2cut')
  ents=model.entities
  gents=group.entities
  bbc=group.bounds.center
  norm=face.normal
  ve=group.transformation.origin.vector_to(bbc)
  tr=Geom;;Transformation.translation(ve)
  group.transform!(tr)
  tr=Geom;;Transformation.translation(ve.reverse)
  gents.transform_entities(tr, gents.to_a)### centered
  tr=Geom;;Transformation.new(bbc, norm)
  group.transform!(tr)
  gents.transform_entities(tr.inverse, gents.to_a)
  ve=group.transformation.origin.vector_to(bbc)
  tr=Geom;;Transformation.translation(ve)
  group.transform!(tr)
  ve=ORIGIN.vector_to(bbc)
  ve.transform!(group.transformation.inverse)
  tr=Geom;;Transformation.new(ve)
  gents.transform_entities(tr, gents.to_a)
  ### make component
  inst=group.to_component
  defn=inst.definition
  be=defn.behavior
  be.is2d=true
  be.cuts_opening=true
  be.snapto=0
  inst.glued_to=face
  ###
  ### complete these items...
  #defn.name=
  #inst.name=
  #inst.layer=
  ###
  model.commit_operation
  ###
end
###

Please try it out... again remember that you don't need the start/commit operation parts IF it's to be embedded into a wider set of code...

jolran

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

jolran

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.

jolran

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.

kaas

Hello Jolran,

First of all; thanks again a million for your effort and to those who are helping you! It's a much much welcomed addition to Sketchup! I can't wait to test it out!

I think your Photoshop dialog already has all the options we could want. Maybe you could add a target layer-option for the hatches? The visual webdailog of course would be the most user-friendly but I wouldn't mind the non-visual dialog. You could always print out the patterns + names on a sheet of paper instead.

@jolran said:

Got the tiling going pretty nicely. (Not from file yet) It's quite slow if having complex patterns.

I wouldn't be too much concerned with the performance. The time for the calculation of hatches will be much less compared to having to draw them yourself by hand! The plugin itself always be a great time-saver and will save us from dull repetitive work.

Greetings,

Max

jolran

Hi Kaas!

Finaly someone answered

@unknownuser said:

Maybe you could add a target layer-option for the hatches?

That should be possible. You do mean put the hatch in a layer already existing in the model?
Anyway I think layers are pretty flexible to work with.

@unknownuser said:

You could always print out the patterns + names on a sheet of paper instead.

That is a good solution, if going for inputboxes. I guess file browser is also possible, like TIG's 2d tools hatches.

Thank you for the inputs, and please don't hesitate to add more requests.

kaas

@jolran said:

You do mean put the hatch in a layer already existing in the model?

Yes. Most people will work with a template file which already contains standard layers, styles, scenes etc. I guess there is no need to over-complicate the code at this stage for adding new layers on the fly.

jolran

@unknownuser said:

I guess there is no need to over-complicate the code at this stage for adding new layers on the fly.

I don't swear by it, but it should be relatively straightforward to get a list of layers pop up in the inputbox.
I think it is a good idea you have, otherwise ALL hatches will end up into 1 layer unless moved manualy.
Putting "hatchlayer" as default in inputbox means one won't have to select layers if happy with that layer.

I put this on the todo list

jolran

Good evening.

Things are moving forward, but have been hooked on webdialogs and speed performance lately.

All in all, all features I can think of is implemented. Loading from file and tiling with some options to it, is ok.(not from some dialog, in script)

The "tech" part:
Some sort of dialog has to be made. I'm thinking webdialog, but quite scared of diving into that part actually
But it will be difficult using dropdownlist with a long list. And I don't know if a list can be updated automatically if user add new components I guess UI.openpanel can only be used for images?

Also performance is an issue.. Things can get quite slow sometimes, maybe to slow..

The plugin tiles the group in 1 direction inside group1. Then it copies group1 in the cross direction.

Copying groups are fast. Exploding and intersections is slow. I don't know if there is any way to speed up thoose things.
Is there any way to copy and tile entities collection without using groups

Have also been experimenting with textures+lines combinations to "get away" with less geometry, but the result is less then satisfactory. Look pics:

More artistic questions arise, what is needed from hatches anyway?
Have been looking for ISO standards but can't find information regarding exact size of patterns. If you look at Doublecad for ex. When creating a hatch, the sizes of pattern often need to be adjusted. So what is the scaling standards? This could be of importance regarding speed. Cause, the bigger patter=less geometry >> speed increase.

Any tips would be welcome.