Distance Between Particles

[boomsters]

How do I instance 3 objects so that object 0 instances in the most dense regions of a particle field, object 2 in the least dense, and object 1 somewhere in between.

I was thinking it might be easiest to write a script that assigned a specific object to a particle depending on the distance of that particle to its nearest neighbor within the particle field. I know how to set this up, just not how to write the script to actually find the distance. I have found scripts describing how to find the distances between two points, and a point and an object, but never for one particle and its nearest neighbor for every particle in the field.

Any other suggestions on how to create the same visual aesthetic/density of the three objects when instanced onto a particle field?

Thanks!

[amitc]

QUOTE(Boomsters @ 03/02/08, 02:43 PM) [snapback]282066[/snapback]
How do I instance 3 objects so that object 0 instances in the most dense regions of a particle field, object 2 in the least dense, and object 1 somewhere in between.

Any other suggestions on how to create the same visual aesthetic/density of the three objects when instanced onto a particle field?

This is a wide open problem. Clustering point cloud is non-trivial and MEL wont cut it. You need to constrain the problem more to get a workable solution.

Some ideas
a) Find distances of all particles from origin [that would be sqrt(x*x +y*y+z*z)] and store them in a list. Sort the list based distance. Say you have n particles, pick n/4th particle for dense location, (n/2+n/4) for intermediate dense location, (n/2+n/4+n/8) for sparse location.
b.) average of all particle position may yield a location of interest. Averaging randomly selected portion of particle positions may provide interesting results as well
c) bounding box properties for particle system could be of interest

Interesting problem though

[ptb]

Quite interesting problem indeed. Here's my solution:

CODE
float $pos_array[] = getParticleAttr -at position -a 1;
float $dist = 10000000000000000;
float $max = 0.00001;   // for normalization
float $mdist_array[]={};
float $norm_array[] = {};
vector $a, $b;
int $k,$i;

for ($k = 0; $k < `size($pos\_array)`; $k += 3) {

    $dist = 10000000000000000;
    $a = <>;

    for ($i = 0; $i < `size($pos\_array)`; $i += 3) {
        if ($i!= $k) {
            $b = <>;
            float $mag = `mag($a-$b)`;
            if($mag < $dist) $dist = $mag;
        }
    }
    if($dist > $max) $max = $dist;
    $mdist_array[$k/3] = $dist;
}

for ($k = 0; $k < `size($mdist\_array)`; $k ++) {
$norm_array[$k] = $mdist_array[$k] / $max;
}

This script compares each particle with every other particle ( -> (num particles)^2 iterations) and returns the array $mdist_array, that contains the minimum distance to the next particle by ID and for your purpose i added $norm_array: It normalizes the values from 0 to 1 (1 being the biggest distance), so organizing is easier.

Anyway, what i think you should do is rewrite it, so it averages between lets say 4 or 5 Neighbour particles, because the distance to one particle doesn't really represent the density.

[joojaa]

You could actually benefit quite much for running the data up into a tree of somekind and get the n^2 natrure into something like (n/64)^2 algorithm wihch is quite significant boost for 100000 elements (100000^2/((100000/64^2))is in magnitude of 1000 times faster )

[ptb]

QUOTE(Joojaa @ 03/03/08, 07:25 AM) [snapback]282105[/snapback]
You could actually benefit quite much for running the data up into a tree of somekind and get the n^2 natrure into something like (n/64)^2 algorithm wihch is quite significant boost for 100000 elements (100000^2/((100000/64^2))is in magnitude of 1000 times faster )

Maybe, but i don't know how

Anyway, since it's apparently not for runtime purposes hence one-time calculation it's alright i guess..

[joojaa]

but still considering each loop takes a 1 microsecond, 100000^2 =thats still 10 thousand seconds worth of computing wich is almost 3 hours. Now three hours is quite different from ten seconds. So yes if its a one shot deal with very luttle data then okey dont build up a acceleration structure. But if it is intended to be used more than once please do.