Grasshopper

algorithmic modeling for Rhino

# generating point inside the volume

Hello, a post with trabecualr with voronoi again..

I am thinking about generating uniform point "inside the solid."

That is, all points should be distributed uniformly along the shape of the structure.

How can I do this work ?

Pop-3D may not be used since it generates a random set of points.

Thanks.

p.s. attached file is the solid I want to make points within.

Views: 17139

Attachments:

### Replies to This Discussion

Here's a new way compared to that long bone structure thread ( http://www.grasshopper3d.com/forum/topics/idea-with-bone ), which takes a standard 3D Voronoi diagram and applies Lloyd's Algorithm to it, which is merely making a new Voronoi from the calculated centers of mass of the original Voronoi cells, and doing so again and again, but here I'm not using Hoopsnake or Anemone plugins to make a loop, I just copy the component into a stack of them. Hoopsnake was slow anyway since it stores all the solutions. I'm not using the native Voronoi since it only allows a geometry bounding box, not a 3D surface, so I had a VB script I got somewhere, and used that instead, and you can double click them to see the code inside. It's rather slow but can be quickly tested on smaller numbers of original points, and you really only need about five cycles since it rapidly converges on a minimum. I've created scaled down versions of the full final Voronoi cell solids, so the actual NURBS solid is likewise bigger than what you see here:

Those were done with 300 points, though many of those are immediately deleted since they lie outside the NURBS surface which is a sphere point edited into a new shape, and took several minutes, but it's only one minute for only 50 starting points in the bounding box. The blue dots show the paths of relaxation:

There are no surface points here, all are inside the original body, rather evenly, so connecting to the outside world is another matter.

Because it's not a strict topological all-tetrahedral mesh, it can in fact be more even in distribution than the usual finite element tetrahedral meshes.

It could be vastly sped up, perhaps, using something like Qhull, a command line C program, rather than a Visual Basic (VB) script.

I'm curious what exactly your STL file is. Is that a scan of real bone? Now if that really is the solid you want to make points in, well, it's already highly complex and perforated, so doing this script on it may be rather slow! A drawing of what you want would be helpful. Hundreds of points inside, but evenly spaced within the little threads of the truss? Why not use the mesh vertices as points and not use any points in the interior of the beams?

Here is a quick 2D version of Lloyd's algorithm, though it uses the extra plugin Hoopsnake:

Again, you could replace Hoopsnake with merely a dozen or so copies of the Voronoi component and the center finding.

Attachments:

Hmm... thank you always.

I should find out Lloyd's thing.

Anyway, my computer is very slow and I am not sure whether my computer sucks or not

I made the points along the surface by Geomagic Studio (I am pretty sure it is not that good solution to the pointing task though)

Does your computer work good with the files attached?

You may explode the point clouds and save them into "point" in Grasshopper.

"Box" and "Domain" in Grasshopper are useless but I can't delete them since my computer is not a good one.

If it works good with your computer, could you specify the specs ?

Attachments:

Computers and Grasshopper 101 question? You included a very simple script. With only 50 points, after I remove them from your point cloud using PointCloud in Rhino and put them in your script after rescaling for lack of any units in the IGES file, and add some nice preview features, it takes one second to complete. The Display > Canvas Widgets > Profiler shows the time each component required:

The 786 points you had assigned were not included in the script itself by right clicking and using Internalize data, but 50 is a good enough test number.

I'm on an i7 Intel 2.66Ghz with 24GB RAM using Windows 7 with an expensive Nvideo Quadro K4000 graphics card. If 50 points takes one second, it shouldn't be too bad with an old computer unless you lack RAM which is now quite cheap.

The bone scan is fascinating.

wow, seems like a work station. I should change mine to get better off.

And yes, it is a real bone of an animal.

Well, well, I just discovered real and professional particle dynamics in Grasshopper via the SPM plugin from 2012, called "SPM Vector Components" which should be called "SPM Particles" since it is quite as useful with much fewer shortcut-algorithm artifacts that I suffered in 3D Studio Max, Blender, and Modo 901, without the crazy Grasshopper-like node programing systems of Maya or Houdini or Thinking Particles in 3DS Max which no casual user can decrypt! It also gives me surface points and though it's the same procedure of my original thread use of Kangaroo Physics to mutually repel particles, it's much faster and able to handle many more particles than Kangaroo was able to do for me instead of just hanging forever.

http://www.grasshopper3d.com/group/spmvectorcomponents

http://www.food4rhino.com/project/spm?ufh

Blender made particles all collect in the damn mesh vertices, no matter what, perhaps since it's calculating an overall field instead of calculating real local physics, here shown with a wireframe preview of the simple mesh it's using, and gravity at work too:

Whereas 3D Studio Max with its Keep Apart component created a sadly bizarre (kinetic instead of equilibrium result) constant fast lane conveyor belt of particles along the border from finger and knuckle features over to palm areas where the particles would then bunch up and burst back into the interior, here constrained to a very flat cylinder distorted into a finger:

Modo 901 also showed odd mesh artifacts but I never figured out mutual repulsion, here seen creating its own internal mesh for calculation, seen in Debug mode, where particles are ridiculously collecting as they bounce around in the open top cylinder under gravity:

The real physics of charged particles should make them bunch together more in fingers and knuckles more than in palms since there are fewer particles around them in full 3D space there:

Wouldn't that be a nice option, to have finer 3D meshing in fine features! Perhaps I can add field influence based on surface curvature, manually? Not sure how yet.

The SPM plugin is quite fast and professional so is well worth a download, and though it's quite fun to watch, it is also tweaky for settings, to stop it from being too bouncy dynamic while still doing much, but instead of crashing it just may break out of the surface bounds. I do need the logarithmic force attenuation to be quite small (big falloff) or it never mellows out at all, and I used mostly damping in the Separation component to achieve stability from bouncing, since the use of Drag in the main settings creates serious friction that stops final small movements altogether so it locks up in a slight mess.

Attachments:

If it was hanging with that few particles in Kangaroo then something wasn't set up right. 10,000 particles filling a volume takes only a few seconds if you use the SphereCollide goal for optimized collision speed.

Here's the definition.

Attachments:

Re-upload please, though I can just build the simple script from the video shot:

Here is what I had before, whereas, ah!, you are using Kangaroo2 where I was stuck using Kangaroo:

I'm not "colliding spheres" so perhaps I didn't look deeply enough at the SphereCollide component so I was using individual springs between all particles, which made the numbers of links blow up when I doubled the particle count.

Two good particle systems to play with now! I want to add a surface curvature attractor to make particles cluster locally, for adaptive 3d "meshing" minus the formality of tetrahedral meshing definitions, since I'm not doing tetrahedrons, it just turns out that way, along with octahedrons etc.

Attachments:

The SphereCollide is actually there in K1 as well. Here's an equivalent definition in the old version.

Interactions between every particle and every other particle very quickly gets unworkable as you found (increasing as the square of the number of particles), hence the need for some more efficient ways of figuring out which pairs to consider, as in SphereCollide.

Also - I can't say too much right now, but there are some improvements on this front coming in the next version

Attachments:

• View All