Bug Brep.ClosestPoint ComponentIndexType

rhinocommon

#1

Hi All, @stevebaer ,
is it correct that the ComponentIndexType from Brep.ClosestPoint is always of type Face, if the Brep is a simple Box, i.e. a polysurface made from untrimmed surfaces only? Or am i’m missing something?
Thanks, Jess


#2

Hi @Jess,

i’ve just remembered this discussion and wondered if it would be possible in RhinoCommon to limit the search to BrepFace only as it is possible in RhinoScript (rvb) ? That blnFaces argument is missing form rs.BrepClosestPoint unfortunately.

_
c.


#3

Hi Clement,

the other discussion is a bit different. In case of a Type Edge the Brep.ClosestPoint does NOT return the normal vector at the closest point. But this does not work as expected if the edge is adjacent to untrimmed surfaces.

In other words: Brep.ClosestPoint will never return type edge or vertex on a simple box. It always returns type surface and a “random” surface’s normal vector.

To get this info I could check if the closest point is at the limit of the surface’s domain and then find the closest edge to that point. But I’m wondering if there is a better way which I have missed?

Thanks, Jess


(Dale Fugier) #4

Hi @Jess, @clement: Brep.ClosestPoint only checks edges if the closest point, calculated from a test point, lies on the inactive part of the face. For untrimmed surface, this is (probably) never the case.

– Dale


#5

Thanks Dale!
How would you get the type and index of the closest point (in c# or python)?
I need it to average the normals of adjacent faces.
Jess


(Dale Fugier) #6

Hi @Jess,

Brep.ClosestPoint provides the component index. From the component index, you can get the type and index.

– Dale


#7

…which always returns Face in case of untrimmed Edges. I need to identify these cases and wonder if there is a better way than the workaround I’ve described:

Thanks,
Jess


#8

Unfortunately Brep.ClosestPoint also returns type BrepFace in certain trim cases. Thus using the domain to speed up the Edge check will not work and I’ll have to take the long workaround.

I don’t see any good reason for this inconsistent behavior and therefore will call it a bug.


(Dale Fugier) #9

Can you post some geometry and source code that you have question about?

– Dale


#10

Hi Dale,

see attachments. No matter where I place the test points I’ll only get BrepFace types.
For the box from untrimmed Srfs and the extrusion I understand why, but not for the others.

I don’t expect changes for this method. But I wish for a method which returns all BrepFaces and their normals which are in touch with the closest point location.

Also many thanks if you can give me a hint how to solve this reliable with the current RhinoCommon SDK.

Jess
BrepClosestPoint_ComponentIndexTypeBug.py (546 Bytes)

Edit: Added some freeform breps
Bug_BrepClosestPoint_Type2.3dm (110.5 KB)


#11

Hi Dale,

I wrote my own Function and ended up in calculating the closest point to each of the brep.Surfaces. I was trying to avoid this because the user’s geometry might be very complex and there are many points to check.

However, I don’t see any other reliable way to detect certain closest point cases. For example the tip of a Pyramid - here I’d expect a type BrepVertex, but what I get from Brep.ClosestPoint is a random BrepEdge which has just two AdjacentFaces of an n-sided Pyramid.

Do I miss something? Can you give an example with a type BrepVertex?
Are there other types which may happen and useful to optimize the the calculation?

Thanks, Jess


#12

It took some time to generate such a case. If someone needs it for testing attached is an example where it returns BrepEdge. CP_BrepEdge.3dm (60.2 KB)

An example where it returns BrepVertex would be helpful.
_
c.


(Dale Fugier) #13

The function will never do this.

– Dale


#14

pretty lame


(Dale Fugier) #15

@Jess,

Why is this lame? Why would you ever want to know this (if a test point was closest to a Brep vertex)? If fact, how would one know the difference (when a test point is equally close to a face, edge and vertex)?

No matter, the function in question does consider Brep vertices in it’s evaluation.

I should add that, being that you are frustrated with this function, there is certainly enough in RhinoCommon for you to write your own…

– Dale


#16

Sorry, but I was not frustrated by this function but by your support.
I explained why I need this and I already solved it with RhinoCommon.
Thanks, Jess


(Dale Fugier) #17

Sorry to disappoint…

– D