Grasshopper

algorithmic modeling for Rhino

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

Views: 662

Attachments:

Replies to This Discussion

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

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

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:

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

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:

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:

Thank you so much. I was mad about it.

Best wishes

Antonio

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service