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.

Attachments:

grass_for_favor.zip, 1.6 MB

Replies to This Discussion

Permalink Reply by Nik Willmore on August 12, 2015 at 2:24pm

Bake off:

Kangaroo is at 420 milliseconds per iteration and it takes about a dozen steps to equilibrate 1300 particles, expanding to fill a volume:

Kangaroo2 is about 200 milliseconds but it's bouncing all over the place, with only a few settings I can't seem to tweak to get it to settle down, two strengths and a radius. I have to minutely tweak my sphere radius setting or it jiggles way too much.

So it's twice as fast but it's out of control too. Ah, so is the Kangaroo1 version, actually, since you already tweaked the radius there. Both go crazy when the radius isn't adjusted to a nearly perfect volume fill. I guess you could calculate the mesh/brep volume and divide by the number of particles with a fudge factor to maybe automate that, but then I can't add some gravity here and there, or areas will again go crazy. The SPM system doesn't do this so badly, but has its own quirks. Looks like their use of a logarithmic force modifier feature lets it mellow out better.

Attachments:

Permalink Reply by Daniel Piker on August 12, 2015 at 4:12pm

With Kangaroo 1 you can gradually increase the radius and as long as the spheres are big enough to push against each other but not completely overlap it gives a stable result.

It is true that the SphereCollide in the current release of K2 doesn't settle so well though - this is because it hasn't been fully adapted to make proper use of the new projective solver. I identified the source of the error recently, but you'll have to wait for the next version for this fix (or code your own custom goal...).

Permalink Reply by Nik Willmore on August 12, 2015 at 4:30pm

Can one code a custom goal for particles that has falloff such that the forces are soft enough to equilibrate robustly even when I set a radius that is either too small to pack fully or too big to fit easily? If so, I'd be willing to climb another learning curve.

3D Studio Max has custom script tweaks too, simple enough compared to the Space Shuttle cockpits that are Houdini or Maya particles that have no guarantee to work anyway since they are such black boxes. Worse, video effects experts have little use delving into such details on various forums so there's not much in the record about such nerdy physics concerns and my own questions are not answered so Grasshopper remains the best option.

Having escaped the ugly world of random point Voronoi in favor of various forms of relaxation what remains is 3D adaptivity to highly curved surface features as well as general finer grain near any surface boundary. Lloyd's iterative Voronoi algorithm threatens to equilibrate away adaptive forces, and I so far lack even a coherent plan of attack.

Permalink Reply by Daniel Piker on August 12, 2015 at 5:12pm

Yes, it would be possible to code a goal with a custom falloff, and I believe you are right that a softer function here could result in more stable packing. With the linear elastic spheres the force falloff with distance is continuous, but its derivative isn't.

I'll try and post an example soon to show how to get started on this.

Permalink Reply by Daniel Piker on August 12, 2015 at 5:52pm

Here's a pairwise potential custom goal.

In this example the falloff function is a simple power of the distance, but you can play with replacing this with other functions (the Lennard-Jones potential is an interesting one to try).

Interestingly for a power d^-2, all the particles end up getting pushed to the boundary, whereas when we take it to d^-3 they distribute quite nicely within the interior.

This simple pairwise approach doesn't scale very well though, because of the number of interactions increasing as the square of the number of particles as I mentioned before.

To get around that requires some different techniques, such as cutting off the interactions at some distance, and doing some sort of spatial organization like that contained in the SphereCollide to avoid comparing everything to everything else.

Attachments:

pairpotential.gh, 13 KB

Permalink Reply by Nik Willmore on August 12, 2015 at 7:43pm

A very important 13 kilobytes, thanks!

(There's a note about hard wiring the file path, but upon merely opening the script I had to redirect the script to C:\Users\Nik\AppData\Roaming\Grasshopper\Libraries by entering %appdata% into the dialog box and browsing to the Grasshopper Libraries folder to find KangarooSolver.dll.)

Oh wow, because of "physics" there is substantial gap between the surface layer of many particles and the inner truss, so we already have some form of boundary adaptive 3D meshing, albeit only in the surface "XY" direction not the normal "Z" direction. There's less full XYZ directional force on the particles at the surface, so they can cluster more there due to the forces from within having to struggle much more against one another from all directions. Something like that.

Differing surface curvature has not much if any affect on particle packing:

The actual physics of electrons along a conductor says they are all on the surface, where they concentrate at sharp features, but here I imagine if they concentrated more at the finger tip, they would then push more interior particles away, which is not very adaptive after all.

Higher falloff exponents than 3 (actually -3) give much more even distances of surface vs. interior, so my color coding by length doesn't even work and there are visibly a lot more interior particles:

I confirm that exponent -2 drives everything to the surface, but also gives a quite odd artifact that they are not minimizing energy by close packing away from each other but are forming squares that seem to align with the UV directions of the container:

Exponent -4 then and even more -5 maximize the interior population, but beyond -5 it it becomes unstable and bounces around like crazy.

The Kangaroo2 custom goal C# script is simple enough:

I'm still confused how to attenuate the effect according to distance to the surface and also curvature of the surface when you are getting close to it since I don't understand if Kangaroo is running the entire Grasshopper script each iteration or not so I could just do calculations via Grasshopper stuff and feed it into the C# script as needed?

Permalink Reply by Nik Willmore on August 13, 2015 at 6:03pm

If I use Kangaroo1 Physics' Pull To Mesh, I can add not enough "spheres" (particles with an efficient hard collide radius), they will congregate along the surface, packing nicely, and then I could perhaps add two more layers of bigger spheres, in order to emulate adaptive remeshing from interior to surface, but it's rather slow again since I need so many small spheres (9200) to achieve the fine surface "3D meshing":

It's crucial to actually set the timer leading into Kangaroo to a second longer than how long it takes each cycle, so it lets you access the interface to stop the damn timer that locks you out of Rhino.

They do pack quite well in this thick shell of a layer of balls:

Permalink Reply by Nik Willmore on August 13, 2015 at 6:19pm

Oh goodness, Kangaroo2 also has PullToMesh deceptively called OnMesh despite having a force input that merely pulls it towards the mesh, and Kangaroo2 is at 10X faster at this, so it becomes a much more workable playground:

So can I now add a second inner layer of bigger balls after fixing the first in place? Welcome to the Anchor component:

Attachments:

Kangaroo2 Fill Volume Using Sphere Collision B LIMITED POPULATION AND PULLING TO MESH.gh, 95 KB

Permalink Reply by Nik Willmore on August 13, 2015 at 6:42pm

No luck, despite using Anchor on the fixed output points of the first Kangaroo2 run, its timer being stopped, the new points blow right through the old ones instead of hard radius collide with them:

Using many fewer new balls or also adding a surface bounce constraint doesn't really fix it. Anchoring some hard balls isn't working well.

What I really want it for the radius to automatically get smaller according to how far the closest point on the mesh is, so I don't have to do tweaky or broken multiple layer runs.

Permalink Reply by Daniel Piker on August 14, 2015 at 4:46am

It looks like that input going into your SphereCollide needs to be flattened, as there is a tree coming out - so the 2 sets of spheres are being treated separately.

Permalink Reply by Nik Willmore on August 14, 2015 at 5:34am

It was sloppy too for running the old instead of new points into the OnMesh force.

Yet, upon sleeping on it, there's now a kinetic tunneling effect where particles escape to outside the mesh and then bounce around outside it, under attraction to it from the outside too.

Overall this strategy is way too convoluted. I considered a sifting system with various fixed sized balls (points with variously sized hard influence) having more pull to the surface when they are small so the end result would be layering of small balls at the surface. Still, that's also just too much to deal with. It screws up enough that it's hard to debug with a clear mind. I have to worry too about the initial packing of the source particles since too close and the force seems to blow up and they explode, tunneling through the time resolution to the outside. Real physics is like that too though :-).

Permalink Reply by Daniel Piker on August 14, 2015 at 5:51am

There is also the SolidPointCollide object which can be used to keep points inside a solid.

Anyway, I agree that this approach with doing it layer by layer is not ideal...