algorithmic modeling for Rhino
Well ...
1. A Brep as the name suggests (BoundaryREPresantation) is a collection of chopped (in most of cases anyway) Surfaces > i.e. a collection of things called Brep Faces that are (a) the underlying surface + (b) trimming "info" (where to chop > and create the "boundary"). Trimming info is "grouped" in 2 things: Outer loop and inner loop(s) - the holes if they exist.
2. Thus if you evaluate a surface you'll get results with regard the surface that MAY "extend" well beyond a given visible "boundary" (in some cases with a rather weird way). Programmatically we test a given u/v coordinate for inclusion on a given Brep Face in order to find IF the face contains the point in question.
So whilst a "piece of code" like Surface.PointAt(u.v) exists ... there's no such thing with regard a Brep Face.
3. If you connect a Surface component to any BrepFace collection this gets the underlying Surface instead of the BrepFace. Try connection a Brep component (Note: a Brep can have one face the so called sheet body in several solid modelling CAD aps).
I have a C# that does (for fun) a convincing demo on all that freaky stuff ... but it's solely code.
I'm having a hard time following, but I think I get what you're saying.
So I have my model - a simplistic rectangular shape with 7 faces - in Rhino. Instead of referencing it in as a BREP and using explode brep what would I do?
Yeah, this might be a bit over my head. Since posting my question I've started using 'divide surface' to generate the lines for the robot to follow.
OK, I'll try to do some simple demo using native components on that matter unless some other good Samaritan does it first.
But ... well... regardless of coding and other freaky things ... I would strongly suggest to spend some time (and then some more) reading about all these things starting with curves ... that are the base "ingredient" for surfaces, breps, brep faces, cats, dogs etc etc.
Thats ok - don't waste you're time. I understand the issue - it wouldn't be such a problem at the moment if the end goal wasn't to have it adaptive to other similar shapes for wire cutting on a KUKA.
Thanks for your assistance.
I'll get it.
Well ... anyway ... a freaky (unfinished) demo can't be a bad thing: a Blob and a "sheet body" (a single trimmed surface) to play with.
See the underlying Surface as well (turn true the thing in the black group). See the somehow "indirect" way to test for Brep Face inclusion (given the u/v coordinates).
Load Rhino file first (and read about these freaky things).
That said (and irrelevant with the tread's topic) a Brep is "knda" a Mesh: has vertices, edges and faces. There's a native component (Brep Topology) that gives you clues about how these are "connected" .
BTW: although you are not familiar with coding (but never is too late, he he), here's the freaky "insights" of finding points (in this case random) in a given trimmed Surface (that in fact is NOT a Surface ... is a Brep with one Brep Face [LOL]):
Translation for normal people:
Working on a given BrepFace and a random number :
LoopInfinitely (I do hope not, he he) ... from here
to there
All the above mean that there's no way to tell if a U/V point is inside a BrepFace ... other than testing for inclusion (that does the native GH component in the V1 provided).
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by