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

jolran · 10 Aug 2011, 19:42

No. Exploded instances do not merge materials to the face lying underneath. Is it supposed to happend?

TIG · 10 Aug 2011, 19:44

On an explode it should [untested].
Alternative 'intersect' after the explode ??

jolran · 10 Aug 2011, 20:18

Well lately I have done quite a few intersects. And the results vary. But no. Materials get lost=white default material.
However I will try intersection after exploding things.

Thanks.

Edited. Not very good results. Things are very negative at the moment. Exploding geometry connected to a face has very destructive behavior. On top of that materials don't get transfered properly, and that was the whole idea of this process.

There is more problems. Let's say I can recreate the face-clone first. No problem!
On top of the face-clone, recreate the whole component instance. Faces, edges without faces, and materials, in code.
Problem here is that I would probably have to do an intersect_with the face_clone, so the edges get connected and form new vertices at the edge crossings. And there the face materials would get lost...In the intersect_with method.

There is an theoretical alternative! I woulden't mind the opinions from TIG on this one:
If doing an component intersect_with face.edgeloops without face? That would at least give new vertices so the unwanted edges theoretical could be removed. Without affecting materials and destructive behavior (tested). But like the method TIG recommended, selected_face.classify_point(). One would need a face to compare against.
Could the face be in a different group? And deleted after comparison? What say you Massa TIG?

jolran · 11 Aug 2011, 06:33

Yes. Something positive!

An intersect between component(hatch-pattern) and face-clone's edge loops(no face). Gives you new vertices. Without affecting materials and destroying faces! so now it's possible to erase all edges and vertices outside the face.

Will see if it's possible to make a comparison against a face in a group. Can't explode it! Destroys everything.

TIG · 11 Aug 2011, 09:09

You can test if a point on a preselected-face in another entities context - BUT you might need to transform! the point by its container[s] transformation back to align with the preselected-face ?

jolran · 11 Aug 2011, 11:55

Ah, sounds great, thanks. I will will try that now. Been busy with some other stuff..

jolran · 11 Aug 2011, 17:08

I think I have a collection of points outside the face now. Plenty of iteration...
There is no way to see the real result until it starts deleting edges. Anyway, see some collection when
using puts.array of points to go

Simple question how do I convert those pt to vertices? Is there a simple way or another comparison?
I guess if getting the collection of vertices it's just a matter of deleting edges connected to that vertice. Edge.used_by?(collection of vertices) ?

jolran · 11 Aug 2011, 17:37

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.

jolran · 11 Aug 2011, 19:33

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!

jolran · 11 Aug 2011, 19:42

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

TIG · 11 Aug 2011, 19:52

Do you now need to erase the uncolored faces or is that done ?

To avoid the 'z-fighting' with the existing face you could move the new group say 1mm in the originally_selected_face.normal so it's avoided...

You have indeed made a 2d-boolean tools... well done

jolran · 11 Aug 2011, 19:59

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.

TIG · 11 Aug 2011, 20:02

When you make it a cutting component remember to set the face to the face it is glued to...

jolran · 11 Aug 2011, 20:08

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

TIG · 11 Aug 2011, 21:16

You are aware of the needs for the axes of a cutting component ? Z/blue is out of the face it glues to... You'll need to transform the group to the origin [flat], make it a component [changing its behavior to 2d/gluing etc]; move the instance back with a inverse transformation, then tell the instance to glue to the originally selected face...
That should avoid the z-fighting ?

jolran · 11 Aug 2011, 22:01

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.

jolran · 11 Aug 2011, 22:29

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

EarthMover · 12 Aug 2011, 01:26

Nice work mate! Looking more and more promising. I'm definitely excited about the direction this is taking. Should be great for doing facade work! Keep it up!

jolran · 12 Aug 2011, 08:02

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.

TIG · 12 Aug 2011, 10:39

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