pyHull in IronPython 2.7.0

Hi!

I have been trying for days to setup the pyhull module into ironpython for rhino. The reason is that I need to use qHull or any n-dimension convexhull tool for python. Unfortunately scipy.spatial is not available yet so pyHull seems my only chance.

My problem is that I can not seem to install into ironpython. IronPython 2.7.0 doesn't support PIP and when I try to intall pyhull through the Command Prompt typing in: "ipy setup.py install" it says that I don't have setuptools installed. I have been unable to install setuptools into iron python and cant find a good tutorial.

(I am not a pro at any of this)

Has anyone been able to do this? Any ideas. Or do you know any other convex hull (4d+) toold for python? Thank you so much!!

*I have numpy and scipy working fine on python for rhino 32-bit as of now.

Jose

Replies to This Discussion

Permalink Reply by Vicente Soler on August 26, 2015 at 4:39pm

I understand you can load .NET libraries in ghPython, in that case http://miconvexhull.codeplex.com/ seems to work well.

Attached is a GH file with a C# scripting component that creates a 3D convex hull using this library (but you can use any number of dimensions).

I also attached the dll since you have to build it yourself (there's no download link).

Attachments:

convexhull.gh, 237 KB
MIConvexHull.dll, 35 KB

Permalink Reply by Jose Holguin on August 26, 2015 at 5:15pm

Thank you very much, I am eager to try this out. What do you mean by I would have to build it myself? ...I am not very knowledgeable of this. Thank you!

Permalink Reply by Vicente Soler on August 26, 2015 at 5:25pm

You don't have to anymore, you just have to reference the dll I attached in the previous comment.

Permalink Reply by Jose Holguin on August 27, 2015 at 10:27am

Thank you very much Vicente. I really appreciate it!

Permalink Reply by Paul Poinet on August 7, 2016 at 4:23pm

Based on the implementation of Vicente for C#, here is a ghPython version, if it's still of interest!

Attachments:

convexHullPython.gh, 238 KB

Permalink Reply by martyn hogg on August 31, 2015 at 12:53pm

This is great... almost!

Any idea why it fails on the group of points I've isolated on the layer "BAD POINTS"? The output is an invalid mesh.

If I rotate this set of points using the gumball in Rhino it sometimes works so maybe that's a clue.

Could the units and tolerance I choose in Rhino cause problems like this?

It works on every other set of points on the layer "GOOD POINTS"

...edit...

Just realised there are some points that share the same z coordinate. If I change the z coordinate of one point then the composnent works.

There must be some bug in it where points with identical z coordinates cause problems, possibly also adjacent points.

Anyone know what the logic / process behind the conves hull is in this case?

Attachments:

ConvexHullQuestion.3dm, 332 KB
convexhullQuestion.gh, 4 KB

Permalink Reply by Vicente Soler on August 31, 2015 at 3:05pm

That's weird, there's seems to be a point that's causing the issue (I think the 6th on the list).

Anyway if you just round the points to a few decimal places it seems to work fine.

Connect the points to the x input of an expression component and type as the expression "round(x,4)". That will round the numbers to 4 decimal places.

Permalink Reply by martyn hogg on August 31, 2015 at 4:41pm

Thanks!

I've been looking for an alternative to the slHull3d component because I was getting weird results with that too.

Anyway, i think I can cope with only having coordinates accurate to a tenth of a micron!

Permalink Reply by Jonathan Irawan on October 23, 2017 at 9:39am

Hi Everyone,

I'm trying to get this workflow going in my system but I seem to have trouble loading the assembly.
I even tried using Paul Poinet's ghPython Implementation and changed the clr.AddReference() to clr.LoadAssemblyFromFileWithPath(). I'm getting this error.

Runtime error (NotSupportedException): An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.
Traceback:
line 2, in script

Does anyone have any clue as how to solve this?

Cheers,

Permalink Reply by Paul Poinet on October 23, 2017 at 9:54am

Hi Jonathan,

Did you try:
In C#: right-clicking on the component > manage assemblies > load the .dll from there.
In Python: referencing it through EditPythonScript > Tools > Options > reference the path from there.

Otherwise, I am afraid I am not sure what's the problem. My guess would be a conflict between the Rhino .NET framework and the one from the .dll. Are you using Rhino6?

Paul

Permalink Reply by Jonathan Irawan on October 23, 2017 at 10:53am

Hi Paul,

Thanks for the prompt reply.

Yeah i've tried both. Funnily enough, i have now placed the .dll within the program files folder for rhino 5 64bit and the python reference works. The C# component is still out of action though. I think it might be a permissions issue? but will investigate.