Register Latest Topics
 
 
 


Reply
  Author   Comment   Page 1 of 2      1   2   Next
Thomixioso

Think about being or just to be?
Registered:
Posts: 158
Reply with quote  #1 
Hello Peter, what I really miss in Soup is node for calculation of nearest particle's neighbours. Especially  usefull for melting of anything. ( same parameter is  in realflow)

Example:

You have filled sphere volume with particles. Then those particles, which are laying close to sphere's surface and have lowest count of neighbours particles could trigger event, when gravity field turns on and particle fall down on ground.

So this the idea, I hope you understand..:)

Tomas.

0
pshipkov

SOuP Jedi
Registered:
Posts: 4,646
Reply with quote  #2 
Oh, i get the idea perfectly clear.
In fact i tried to talk Maya devs to give us built-in lookups in the nParticles for neighbours but i think they feel it is unimportant. Too bad.

How do you think the system should work ?
A node that is connected to the particle shape and outputs two arrays. Each element of the first array storing the number of neighbour particles and the second array the particle ids of the neighbours of each particle.
Or maybe this should be a command that can be called from within the particle's dynamic expression ?
0
DickyT

Avatar / Picture

Asking for seconds
Registered:
Posts: 82
Reply with quote  #3 
I'd love to have this too!
Ideally you would be able to ask for an arbitrary number of nearest particles - for example only the nearest 4.
But god knows how the particles expression could make use of this type of array?!...
  I guess you could have a node that could output several pairs of arrays.
That way you could specify how many neighbors you require in the node and
connect these arrays to the particles expression individually.
partNeighboutNode.niebourParticleId[0] - closest
partNeighboutNode.niebourDistance[0]
partNeighboutNode.niebourParticleId[1] - 2nd closest
partNeighboutNode.niebourDistance[1]
partNeighboutNode.niebourParticleId[2] - 3rd closest
partNeighboutNode.niebourDistance[2]

A command would work, but would it be as fast as a node?



__________________
Segway all the way!
0
pshipkov

SOuP Jedi
Registered:
Posts: 4,646
Reply with quote  #4 
Using compound attributes and updating them on the fly for every particle is going to be slow and will take permanent memory space for bigger-ish lookup radius. There is no way around it.
It makes sense to be command so we can ask for specific particle neighbors. Once the command exists the memory is released.
Also, doing brute force point-to-point distance measurement is going to be very slow, relatively of course - still much faster than mel or python solution, but still bad from production stand point. Some accelerated structure has to be implemented to speed things up. I have one here, but that automatically makes the implementation of this tool non-trivial.
Finally i assume that the command should return not just the IDs of the particles but any existing data "attached" to them that is requested through command arguments - like radius, velocity, color, mass, some_user_data, etc. Correct ?

0
DickyT

Avatar / Picture

Asking for seconds
Registered:
Posts: 82
Reply with quote  #5 
hmmm... some thoughts...
I think a basic id number would be OK. It would be great for it to return information too, but personally I could live without as I can just query the specific data once i have the ids.

Rather than neighbours within min and max distance ranges, perhaps it would be faster if the command got nearest 1, 2, 3 neighbours as required. For example...
particleNeighbors -numberOfneighbours 3;
returns an array of integers of particle id.


__________________
Segway all the way!
0
pshipkov

SOuP Jedi
Registered:
Posts: 4,646
Reply with quote  #6 
Agreed.
0
ruchitinfushion

First taste
Registered:
Posts: 54
Reply with quote  #7 
In past i ve used "ANN Kd-Tree"  for rendering millions of particles at rendertime using 3Delight DSO & Ri Filter.There are two three more algorithm for searching nearest neighbor,but I m happy with Kd-Treee.Wht's ur opinion pshipkov?
0
pshipkov

SOuP Jedi
Registered:
Posts: 4,646
Reply with quote  #8 
Well, i completely agree :)
0
Thomixioso

Think about being or just to be?
Registered:
Posts: 158
Reply with quote  #9 
I am happy, that you gyus are interested in this feature. Keep moving. :) My programming/scripting knowledge is somewhere between poor and bad unfortunately, so I can only keep my fingers crossed for you :) 
0
pshipkov

SOuP Jedi
Registered:
Posts: 4,646
Reply with quote  #10 
I have it on my to-do list. But it will not be in the next update.

0
viki164

First taste
Registered:
Posts: 82
Reply with quote  #11 
its little late to reply here but along my way of general googling. I found this scripts to calculate nearest neighbor :

http://www.insidethelinesvsfx.com/sections/scad/vsfx705/plant_mel_code.html

http://www.insidethelinesvsfx.com/sections/scad/vsfx705/plant_python_code.html

Hope it helps :)
0
pshipkov

SOuP Jedi
Registered:
Posts: 4,646
Reply with quote  #12 
If one wants to do it right now this (http://soup-dev.websitetoolbox.com/post/selecting-objects-near-an-object-7194469) will be more appropriate for the case.
It needs to be modified a bit to operate on particles but not transform nodes.
But proper command written in C++ and using good off-the-shelf library, or coming up with new one needs to be coded for this to be real production ready solution.
0
viki164

First taste
Registered:
Posts: 82
Reply with quote  #13 
Is there a way to use KD tree inside maya for particles ?
0
pshipkov

SOuP Jedi
Registered:
Posts: 4,646
Reply with quote  #14 
not as out of the box feature.
you can use pointcloudtomesh node and then run the builtin octree on that but it does not have builtin ability to find closest members.
simply put we are on our own here :)
0
viki164

First taste
Registered:
Posts: 82
Reply with quote  #15 
I hope its still not too late to request this stuff from Autodesk.
looks like even 3ds Max has it :
 

Even Nucleus uses KDtree for most particle operations. Don't understand why its not exposed as a command/node for the users. It would be really useful to have it !

Using expression is not always efficient when dealing with high particle count & it is hard to get the indices of the particle that was previously emitted. The expression thus does a double loop over the particle age array to find the next youngest particle for each particle. Perhaps there could be a better way to write a particle field in C through the api, and fix the distances that way, As being api noob I could only rely on developers to have this integrated or available to us.

 

0
Previous Topic | Next Topic
Print
Reply

Quick Navigation: