Brep CP bug?

Dear people¡

I'm experimenting what seems to be a bug getting Brep CP.

In the attached image you will see the evaluated vertex cloud and the displacement vector to what I expected to be the Brep CP, but form those vertex below the brep it finds the CP in the nearest edge, not in the nearest face, being closer to the face than to the edge though.

Can any tell me whats happening, maybe I'mdoing something wrong.

Thanks, A

Attachments:

Picture 2012-08-20 19_06_40.png, 5 KB

Replies to This Discussion

Permalink Reply by David Rutten on August 20, 2012 at 12:31pm

If you are doing something wrong, I cannot tell what it is from the image you posted. You'll need to post the *.gh file and the *.3dm file needed to replicate the bug or at the very least an image of your Grasshopper file.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Roig on August 20, 2012 at 2:50pm

Thank you David for your interest,

I'm attaching both, the GH and the 3dm Files.

It takes a little to load, please patience. The problem might be in the cyan group, at the buttom.

Thank again. A

Permalink Reply by Roig on August 23, 2012 at 3:22am

Dear David, I realize that you must be a really busy person, so sorry for bothering you.

I'd improve the definition (attached) but the problem still is there¡

I'll explain the def for you, it might facilitate your work towards detect if it's a bug or something wrong by my side:

I'm trying to distribute randomly a fibers cloud inside a concrete volume. I compute randomly distributed and rotated reference planes. Every thing right up to here.

Then I calculate first one end point of the fibers (and repeated for the second extreme)so I can check if it is in or out of the volume. For those outer points I calculate the displacement vector towards the volume (to be used with the reference planes) and here the problem comes. For some points GH calculates the vectors towards the nearest edge not to the nearest face.

PLease help me find out what's happening. Probably it's not a bug, due to your consistent work.

If it is not a bug just tell me so I can try to work it out for my doctorate without bothering any more.

Best Regards. Antonio

Attachments:

SFRC MODEL EN T 02.gh, 66 KB
SFRC MODEL 02.3dm, 254 KB

Permalink Reply by David Rutten on August 23, 2012 at 4:15am

Hi Antonio,

that's a pretty big file. I would be very grateful if you could reduce the problem to just those components that generate the supposed wrong results?

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Roig on August 23, 2012 at 5:26am

Dear David, I'm the grateful one here. thanks¡

I did cut the components that slower down the definition, and isolated the problem origin.

The thing is, if I use the original brep to produce the displacement vectors, it fails, but if I move that brep, then it works... extrange, isn't it?

Just Disable/enable where told and you will see. Forget anything on the left, is tested and the problem is not there.

I attach the files.

Thank you again¡

Antonio

Attachments:

SFRC MODEL EN T 02 for David.gh, 60 KB
SFRC MODEL 02.3dm, 254 KB

Permalink Reply by David Rutten on August 23, 2012 at 9:21am

Hi Antonio,

I was hoping you'd remove more components still, but I reduced the file to the bare minimum (attached the files). You're right, the Brep CP result is indeed erroneous and it's a bug in the Rhino4 Brep Closest Point solver. I tried it in Rhino5 and it gives the correct answer there, so it would seem this bug has already been solved. I doubt it will ever be backported into Rhino4, as there will probably never be updates for Rhino4 again.

If you cannot switch to Rhino5, then I think your only option is to convert your brep to a mesh and use Mesh CP instead.

David Rutten

david@mcneel.com

Poprad, Slovakia

Attachments: