Crenellation pattern trough a set of points

Replies to This Discussion

Permalink Reply by peter fotiadis on January 18, 2017 at 12:55pm

Just spotted that one:

A classic case where connectivity stuff rains supreme: for instance for locating the "inner" edges of interest ... then the faces adjacent to edges etc etc.

Note: If thingsA are listed in ListA and thingsB in ListB, a AtoB connectivity is a Tree of type integer where branch paths are the indices of thingsA (in ListA) and branch items are the indices of thingsB (in ListB).

See the Topology native GH component used and try to get the gist of what it does.

Good news: rather easy to do it with code (PS: quite probaply with native components as well).

Bad news: code only used.

Ugly news: indicative AND unfinished with regard the (obvious) desired result. Too many checks are omitted and especially a Method for creating solid pieces that "bite" each other.

If you are still interested I could finish it if I can find some spare time.

best

Attachments:

• CrenelateBrepEdges_V1.gh, 146 KB

Permalink Reply by Sebastien de Wit on January 18, 2017 at 1:49pm

Hi Peter,

I have been trying it for days and it still ain't working with native components. Again an example of the power of scripting. I don't know if it is to much asked for an example using only native components, because to me the script is a magic box and I still need to defend my thesis. So I really wanna know each step in the model. The problem of pieces that bite each other is taken care of in a different way. I already have a new model which i will upload as well. Thanks again, really appreciate your work.

Attachments:

• Example file.gh, 146 KB

Permalink Reply by peter fotiadis on January 19, 2017 at 1:00am

Hi Sebastian

Well ... if in the future you have plans to work within a teamwork basis in the AEC field at some contemporary practice of a certain size (meaning lot's of applications under some BIM umbrella - Revit/AECOSim etc etc) then scripting is the only way to do business. In fact Dynamo/Generative Components would be your main parametric app ... but GH can offer a thing or two as well. 

Other than that here's a very brief explanation upon the "steps":

1. Using connectivity trees (faces to edges, edges to faces, faces to faces) ...

2. ... Find the "internal" edges (meaning edges that are connected to more than ONE face) and store them in a tree. Doing this find the smallest edge as well (for defining the "module" of the pts divisions minus the start/end offset). Used an object type tree since I store the indices of the adjacent faces as well (an object type is a "general" container that can hold cats, dogs, numbers, bananas etc etc ... with the cost of un-boxing when an item is to be used [Note: un-boxing costs time but in this very simple case we can afford the "luxury"]).

NOTE: if you observe the paths on that tree you'll notice that they correspond 1:1 to the indices of the related edges in the EList List (of type Curve).

3. Loop withing the "interior" edges and define the coplanar vectors per edge related with the 2 adjacent faces. These vectors are the Cross Product (Google that) between the edge direction and the normal per face (at u/v: 0,0).  Divide the edge (taking into account the start offset AND the ratio of the edge length/ minEdge [as derived from phase 2 as above]). Using these points create a "zing-zag" polyline and store it in the same path as the OEM edge.

NOTE: The polyline is not planar since each teeth is laying to the corresponding adjacent face plane (if the Brep Faces are not planar more "smart" stuff is required).

From this point (not included in V1):

4. Using Face to Edge connectivity data: IF a path exists (in the polyline tree as in 3 above) with the given index sample this polyline as Curve ... if not get the OEM Curve (case: "boundary"/perimeter Brep Faces). Join the Curves (take provision to report failures) and project them to the corresponding Brep Face plane (case:  planar face) or ... to some suitable "mean" plane. Define a planar Brep out of the newly created closed planar Curve and extrude it (actually the Brep Face of it) both sides at once for doing a "solid". If Brep Faces are not planar ... well things are a bit more complicated (not nuclear science ... just another approach is required).

In fact ... is a bit more challenging than that since there's assembly tolerance AND clash issues around ... but this is the "general" idea anyway.     

Permalink Reply by peter fotiadis on January 19, 2017 at 1:46am

BTW:

Re opened the V1 (had some freaky ideas) and guess what? Internalized stuff is "partially" internalized as follows:

That's "normal" Sir: as everybody knows GH can't memorize a thing or two ... thus do the following:

Clear all things:

Reference Breps using the attached Rhino file:

Moral: DO NOT INTERNALIZE BREPS.

Attachments:

• CrenelateBrepEdges_V1.3dm, 556 KB

Permalink Reply by Sebastien de Wit on January 19, 2017 at 2:22am

Hi Peter,

Well that is a firm explanation. I am going to try it myself and see how far I can get. Really appreciate your effort to explain this to me! Thanks again. Regarding the internalization of Breps, I normally don't do that only for certain files on the forum ;).

Permalink Reply by peter fotiadis on January 19, 2017 at 2:44am

Well ... I always admire the brave, he he.

Why? (case native components)

Here's why (imagine the checks required in order to do that in real life with a "reasonable" manner AND the required explicit reports: piece too thin in this place, teeth too long, no Karma etc etc).

BTW: the last bool (flipV2) is used in order to allow you to viz the face/face angle thingy (yielding non planar polylines):

Permalink Reply by Sebastien de Wit on January 19, 2017 at 2:53am

The idea of using only native components is mainly because of the scope of my thesis. Each macadamia structural engineer should be able to use the model. Most of them have no knowledge about scripting ( wish we all had ) and therefore only native components is easier to follow.

Besides the distance between the vertices is equal at all segments isn't it? or does it vary? Between now and a few weeks some elements will be produced with a CNC machine as well ;)

Permalink Reply by peter fotiadis on January 19, 2017 at 3:12am

Well ... the issue is that the future is galloping (not to mention AI) and I predict that most people would be greatly surprised when they'll discover that ... things would be a "bit" different in no time (think the transition from vellum paper to mouse > multiply by 1000).

Get the V1A with some basic visual explanations with regard the mysterious connectivity matters/trees (critical in order to handle that type of stuff and ANY AEC stuff to be honest).

BTW: If the ultimate goal is to do it without broken pieces (and nerves) ... then ... well ...

Attachments:

• CrenelateBrepEdges_V1A.gh, 139 KB

Permalink Reply by Sebastien de Wit on January 19, 2017 at 3:35am

Thanks, this already clarifies some of the things happening in the script. I am studying it right now. Hopefully it will be clear in the end :D.

Permalink Reply by peter fotiadis on January 19, 2017 at 4:11am

BTW: Added a simple check related with the input Brep (after Join): if there's more around then the C# stops working since the whole DataTree handling is not written(*) having Lists of Breps in mind. This is what happens IF the internalization partially fails (meaning that the Join yields more than one Brep > Adios Amigos).

(*) I'll fix that limitation in some future version.

Attachments:

• CrenelateBrepEdges_V1B.gh, 141 KB

Permalink Reply by peter fotiadis on January 19, 2017 at 8:29am

BTW: Here's what I propose: take a short break from attempting to do it via components and focus/practice to the most important thingy in AEC matters. connectivity trees.

Added some more visual aids related with the Topology outputs:

So let's try to do (via components) the face reconstruction stage (the missing 4 as above):

Alias crenelatedEdgesTree as polylineTree.

Imagine a Lst that samples all the edges per Face ("changed" and "unchanged") as Curves.

1. Let's take face 3: this is surrounded by edges 10,11,12,13 and 37.

2. Has edge 10 "changed" (to polyline) ? No because in the polylineTree there's no branch {10} ... thus sample edge 10 from the EList (Note: apparently that's a boundary edge). Has edge 11 "changed" ? No ... blah, blah.

3. Has edge 12 "changed" ? Yes because in the polylineTree there's a branch {12} ... thus sample the item from that branch. Same for 13 ... etc etc.

4. Thus we have sampled all the surrounding edges as Curves and the next step is to join them > yielding a closed Curve.

5. Then we must "planarize" that Curve (by projecting it into the corresponding Brep Face plane) ... and the rest are history.

So ... try it and report any issue encountered.

Attachments:

• CrenelateBrepEdges_V1C.gh, 144 KB

Permalink Reply by Sebastien de Wit on January 19, 2017 at 9:21am

Ok, So basically you check for each surface the adjacent faces (FF conn) on the other hand you check how each face is build up by  which curve/line in (FE conn). If a curve/line is only being used in one face it has no additional branches in the (EF conn) and needs to be culled out (these are basically the naked edges). All other curves are thus poly-line curves and required for crenelating. Am I on the right track?

Next the OEM face list contains all surfaces while the OEM edge list contains ALL face edges. The difference between the OEM edge list and the crenelated edges, are the culled lines from the (FE conn) list. Furthermore (EF) conn is "equal" to the int Crvs plus Face conn.

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page