Albert Callejo Amat

old_school
Thank-you for the image of the ice tree. Explains everything actually, in a couple seconds.
Next time don't be throwing us a wrench by showing us what you want (http://en.wikipedia.org/wiki/Accretion_(astrophysics) and http://en.wikipedia.org/wiki/Galaxy_formation_and_evolution, [en.wikipedia.org] etc.) then asking for something completely different. Just the ice tree at the start and nothing else could have shortened this to just two posts.

Finally had a few minutes to whip up a file for you. See the attached hip file for one way of implementing this in Houdini using POPs inside of a DOP network.

It builds the POPs inside a DOP network allowing the point cloud op:/path_to_sop syntax work as expected fetching the previous cached frames result inside a SOP Solver only used to point to this cache (which you can do whatever you want to inside btw).


The first part of the ice tree is about getting the average position around the current point and NOT the nearest 3 points specifically. I gave you a file above that lets you get the nearest 1st, 2nd, 3rd, 4th, Nth point around the current point.

This is EXACTLY what Point Clouds were designed to do: Find the average attribute weight around the current position P. In the given Ice tree, it returns the AVERAGE of the array of Point positions and not the point indices themselves, as you requested and as I delivered. Unlike the ice tree which takes 6 or 8 nodes to do, it is done with just two VOPs and no loops as this is an iconic technique:

Point Cloud Import VOP
Point Cloud Filter VOP

The Point Cloud Filter VOP in the example finds the average vector P position around the current point and you can set the number of nearest search points to 1, 2, 3, 4, 10000 if you so wish all within a given radius again if you so wish.

That again isn't the driving force with this set-up as exposed in the ice tree.

The real motivation provided by the ICE tree isn't the fetching of the average weighted P. As I stated very clearly in a previous post, this gives you random white noise like behaviour.

It's the Randomize Around Value ICE node that is setting things in motion giving the sim it's pseudo-accretion behaviour. It simply randomizes the mass of the points which in turn is used to randomize the forces (Mass * force) in the ICE Tree time step most likely buried in the Simulate Particles node.
I used a Property POP to add a float mass attribute and use the ubiquitous expression setup:

fit01(rand($ID+1.001), 0.2, 1)

where:
rand($ID+1.001) returns a value from 0-1 that contains a random value given the particle's unique ID and a seed offset value of 1.001 just because I feel like 1.001.

Then take this random mass and modify the velocities directly. That's the most common method to directly affect particle motion is to drive values directly in to v and generally not in to force.

It is the randomness of the masses that picks the winers and losers in the pseudo-acretion set-up where by the larger guys eventually end up winning and sucking in all the neighbouring particles. Again it isn't the nearest point look-up doing it. That's just getting a field of values to work upon. Can do this in a few different ways.

As I mentioned in one of my earlier posts, you need to create a subset of points that will become the overall attractors/winners. Using a random mass is one way of selecting such winers from the losers.

As for adding the swirling motion as the heavier mass particles start to accrete surrounding points, that's easy to do and not in the ICE tree attached.

Again Mr Dickson and everyone else are trying to help you get to that initial youtube video result so don't be so harsh on us.

—-

These days I would not use this method. It's quite old school and out of date in Houdini. Using volumes to get weighted averages of regions can be far more efficient and allows you to decouple the number of points from the result which is always a good thing. The ability to simulate ten thousand points or tens or hundreds of millions of points and get a similar result is what is required these days. You ain't gonna get that with random ID seeds driving things.

Hi,
I've tried it in H17.5 and gives me a lot of errors, something like
Bad node type found: popsolver in /obj/dopnet1.
/obj/dopnet1/popsolver1:
Skipping unrecognized parameter “guideswitcher”.
Skipping unrecognized parameter “mainswitcher”.
Skipping unrecognized parameter “parmop_usepoppath”.
Skipping unrecognized parameter “usepoppath”.