this came while I was doing some Brep Topology, in particular find Face-Vertex relationships (which Vertex belongs to which face) as the Brep Topology component only gives Faces and Edges infos
I was aware deconstructing brep faces using Deconstruct Brep (which is using Deconstruct Brep on the Faces output of another Deconstruct Brep) would usually yield let’s say “unreliable” vertex numbering
meaning that the vertex list would be sorted correct but it could be shifted by one or more positions (which I can live with)
but taking as example a simple Box:
when I Deconstruct Brep on it then Deconstruct Brep on its faces to get their Vertexes, most of those appear seriously messed up…
Box top face, Normal vector is fine, Vertex numbering is fine:
I’ve run into tthis problem a lot of times. I still don’t know the reason it happens or the different behaviours, so the only thing I came up with is to fix the list in a way that stays consistent.
the vertex with the smalest number in the whole brep does have the smalest number in the face.. the order stays the same.
i did not expect these points to have a relation to the normal - I think they can not.
speaking of Breps which have planar/polygonal faces, maybe the most “reliable” method might be with Rhinocommon to go through each BrepFace, extract its BrepLoops and explode it to get the Vertexes? I’m gonna try something…
my previous example was for a box, or generally speaking for faces with a border without concavities.. a more consisten method I use when I know I will encounter also this cases is to get the polyline border for the face and explode it (I think it is what you are saying in Rhinocommon terms)
sorry, I do not understand:
are you looking for a special debrep that works for single face breps only?
if not, how can the list be ordered to match the normal? clockwise for one face is counterclockwise for the neighbour face
I sort of recall seeing that image in older threads (probably posted by you )
it makes a lot of sense!
I don’t think changing DeBrep component to output vertexes that way would break existing definitions because -as you have clearly explained- they are not sorted… so they somehow required some kind of sorting introduced by the user in order to be used for something useful, which means that if the Component would suddenly start sorting the vertexes, nothing would change… but -as always happens- I guess some people might have introduced some sort of manual indexing in some definition and that change would break their codes…
anyway, that component is awesome, thanks a lot!
@Jakob_v_Schirmeister what I meant with clockwise/counterclockwise is that if you draw -for instance- a planar polyline and make a surface out of that, the Normal of that surface should point to the direction where points order is counterclockwise (similarly to what happens for Mesh faces)
ok. and i dont want to start a battle. not at all.
we are discussing how the deconstruct brep could be improved. right?
it does -currently- give one list of points and a list of faces. these faces are breps again. single faced breps - but breps. since the surfaces could be trimed it can not give nurbssurfaces. we would lose the triming information. deconstructing these breps again does give us a shorter version of the lists we had. again. the same points but fewer in the same order. the same edges…
and that does make sense somehow. and it does not tell anything about the topology. we do not know how many ar which faces or edges meet in one point, we do not know which edge belongs to what face.
so we can ask for a differnt order when debreping a single face brep
i do not have an opinion about that yet. giving the same points in again but in a different order can be irritating an will take computation time.
OR
we can ask for an additional output of that debrep node (or a topologynode) telling us somthing about the topology . would be cool.
when you think I still dont understand - please show me how your ideal bebrep would output the 8 points of the whole box
Surfaces, proper, are always untrimmed. Breps hold all of the trimming topology.
All Breps contain trimming topology even if they were never “trimmed.”
If a Brep has a single face and that face is geometrically the same as the underlying surface - the face has trivial trimming - then Grasshopper will report this as a surface.
Not all surfaces in Rhino are NURBS. A Brep face’s underlying, untrimmed, surface could also a plane surface, sum surface, or a surface of revolution.
The “faces” returned by the DeBrep component are single-faced Breps. These Breps contain all trimming information, in addition to the underlying untrimmed surface. The output is essentially what you’d get of you baked the input Brep and exploded it with Rhino’s Explode command.
