Particle force - selfmade

[Macha]

I want to create a custom "molecular force" between particles.

In order for this to work correctly each particle needs to scan its surroundings and sum the force for each particle in its vicinity according to a function.

But but but, I can't figure out a good way of doing this. The proximity pop only gives me the nearest particle, so that's not very good because I can only calculate the force between pairs, not whole bunches.

Using the point cloud nodes doesn't work either. I think pops go into a strange loop thing there.

Placing a vopsop with point cloud nodes after the pop-network (in the sop context) and then referring to it with an expression does kinda work but it is very buggy and weird and probably just functional by accident.

What can I do? Is there a sop-solver type of node for pops in dynamics? Can I loop over each particle in a loop for each particle? (similar to what Peter Quint did in his point cloud videos for shaders)

Edited July 31, 2010 by Macha

[mawi]

What can I do? Is there a sop-solver type of node for pops in dynamics? Can I loop over each particle in a loop for each particle? (similar to what Peter Quint did in his point cloud videos for shaders)

Here is a file using sop-solver to pC-filter closest particles and using that as a force in pop-solver.

You might want to do the pc in a while loop instead.

This was really fun. Thank you Macha, now i will be stuck in front of the computer all day.

***Its a H.11 file.***

sop_pop_test.hipnc

[andreu.lucio]

Hi,

I´ve been using pcs with particles a lot and found that a sop solver-pop solver combination works very fast and get nice results.

The setup its quite simple, start with a pop object in dops and plug a multiple solver with a sop solver and a pop solver.

In the sop solver you can create the forces or groups (just point attributes) with a vopsop and a point cloud setup. And in the pop solver just aply the forces that are allready created attributes in the particles. This hapens every frame so it works really well and its very easy.

Hope it helps.

[Macha]

Thanks for those setups!

[pclaes]

I posted a file in this thread that does some cool custom sop solver behavior with points:

[andreu.lucio]

Sorry, forgot to say that particle fight file from pclaes is were I learned such a powerfull technic.

Thank a lot for sharing that pclaes!

[Macha]

I'm a bit puzzled by this, maybe somebody can have a look at it.

I am trying to take every point P, and then iterate over all the point's neighbors within the search radius, calculate the vector from P to neighbor and sum those vectors up. The resulting vector is the average force direction (I haven't scaled it yet according to a distance function. I'll do that later)

But, I can't write out that force attribute as a vector! Only float. Maybe I'm tired and sleepy or something but what am I doing wrong?

force.hipnc

Edited August 2, 2010 by Macha

[Macha]

Oh...I am sleepy... I think I just piped in condition as an attribute value...

A minor problem remains though. The values are updated in the sopsolver but not carried over to the posolver.

Edited August 2, 2010 by Macha

[Macha]

I'm making some progress with this. I can now calculate the force and simulate the particles. However, I find it extremely buggy. I crash every few minutes (when adding or deleting parameters) or the simulation suddenly stops working (have to restart app) or doesn't pass over attributes to pop (restart app)or decides to do only part of the particles, or not until frame x, etc etc.

Here, if you want, have a play with it (it's quite fun!). There is an attribute vizualising the force.

I also wonder if somebody knows a better way of making a ramp. The standard ramp node goes from 0-1 and that's about it. I'd like to draw an arbitrary curve. It would be better than trying to work out a suitable function by hand...

I tried a chf expression in combination with a curve for a dummy parameter but it's a little cumbersome to set up. Any ideas welcome.

force2a.hipnc

Edited August 2, 2010 by Macha

[andreu.lucio]

Hi Macha,

I haven´t opened your file jet cause I don´t have houdini in this computer. There is a pcfilter function that does the average of the attribute, I supose is faster than the while loop. About the buggy behavior you are reporting I noticed that is almost allways because of the dops cache. When you see that things don´t work until some frame it´s because it´s cached until that frame. My workaurond on this(not sure if it´s the best but it works) is to play the simulation on dops and not from inside the sop solver. And sometimes need to toggle of and on again the pop object to get correct refreshing of everything(I think it´s when you create new things like attributes inside the sop solver and not just modifing).

I will look at your file at work to see what you are doing with the ramp.

[Macha]

Here are some renders. Particle scale is based on density. The lines are the force vectors. Colors are force components.

I would have thought the particles settle into a plum-pudding object, or fly apart but instead they attempt to create spherical shells! (looks solid in the images below because of the vectors)

OK, not useful but I'm happy I can make a force that is created/influenced by every particle.

Next I should try to include a rest position.

I also wonder if I can speed-up the whole thing by calculating a force field instead of the one-by-one iterations I do at the moment, but I haven't got a clear conceptual idea of this yet.

Vimeo:

Andreu:

I think you are right with the dops cache. I find it helps when I give the particles a little velocity "wakeup kick" in the source pop before I simulate. There are other H11 bugs as well I think.

About the ramp: The basic idea is that I want to manipulate the strength of the force so that if particles are too close they repel, if they are further they attract. A ramp only displays this 0-1 range in a tiny view but I need negative values as well, and they are not displayed so it is inconvenient. A better way would be to draw a curve in the motion or channel editor. That's what I tried with the chf expression. I'm sure somebody knows a nice chop trick for all this!

Edited August 2, 2010 by Macha

[mawi]

About the ramp: The basic idea is that I want to manipulate the strength of the force so that if particles are too close they repel, if they are further they attract. A ramp only displays this 0-1 range in a tiny view but I need negative values as well, and they are not displayed so it is inconvenient. A better way would be to draw a curve in the motion or channel editor. That's what I tried with the chf expression. I'm sure somebody knows a nice chop trick for all this!

Use the fit range VOP to remap P->pc max search distance to 0-1.

Something like fit(distance(pcPos,P),0,maxSearchDist,0,1)

Plug that into the ramp.

***File on next page***

Edited August 2, 2010 by mawi

[mawi]

Use the fit range VOP to remap pc max search distance to 0-1.

Something like fit(distance(pcPos,P),0,maxSearchDist,0,1)

Plug that into the ramp.

Did this one really fast so there might be some error. However i think you got the idea.

fitRange.hipnc

[Macha]

Thanks Martin, but it is not the input value that needs to be in the 0-1 range but the curve itself should be outside. Imagine it had to look something like (distance+d)^3 or something. I attached an example.

Look what happens in the red force node.

So, how can I set it up in a vopsop? And could I set the position of keys with expressions? Resample the curve? Perhaps a chopmaster knows these things.

rampme.hipnc

Edited August 2, 2010 by Macha

[Macha]

Here's another question I have.

To take an evolving rest position into account I think I can do the following: Every n frames I will add another weighted force vector pointing from each particle to it's the rest state position, thereby "advecting" the force and give the particles an overall shape that they can retain.

The question is, how can I refer to geometry of a previous frame? (in vops preferable, but maybe sops is ok as well because I could just plug it into a vopsop)

I thought "Bing! I will use a op:/obj/blabla[$F+`lala%la`] expression in a file sop!", but the file node doesn't like the op expression.

I also thought that perhaps I can cache it with a rest vector attribute a la if($F%5==0,$TX,$RESTX) but it doesn't keep the attribute for 5 frames (in this case) constant, but just for the case when the condition holds.

Because I do all this in dops, I am sure there is a better way to refer to geometry from previous frames?

Edit: I think that attribute method may work after all...I think the dops cache bug got me again there...

Edited August 3, 2010 by Macha

[Macha]

Here is the file if anybody wants to have a look at how I set up the rest position force.

If you visualize the attributes, blue is the rest position force, gray the original force, and yellow is the combined force+restforce.

There's a lot of dops cache updating problems. Everytime you change a value you need to go into pops and fiddle about a bit to reset the whole thing. Even then, I'm not sure it clears it all, so it is nearly impossible to tweak...

The ideal situation would be to get the rest position values, keep them for n frames, update and keep for n frames, etc etc, but it won't do that properly with this attribute method.

forcerest.hipnc

Edited August 3, 2010 by Macha

[Macha]

Here is the same with the rest position taken from an objectmerge, showing that the principle works.

In this case however there is no evolving rest position, so it is much less useful.

The blue lines are the restforce vectors pointing nicely and correctly towards the rest position (spheres). I made the force increase in strength proportional to the square of the distance.

You get a squishy bouncy effect as the particle forces battle with the restforce. If I wanted to break, evolve and reset those shapes I would need an evolving restposition. That is why I am searching for a method to do it.

forcerest_noanim.hipnc

Edited August 3, 2010 by Macha

[Macha]

Sorry for the many posts but I'm on a roll and find this problem very interesting!

I found a way to implement my custom curve ramp by putting it outside the vopsop, into a create-attribute, and then back into a vopsop.

I also think I got the evolving rest-states working by using a timeshift sop with an expression int($F/steps)*steps, which gives me a step function without the need for a chop. It only works if the node is located outside dops though.

Quite some acrobatics there but I hope I can continue from there.

The only major problem is the dops cache updates.

Btw, the ramp in the vopsop node does absolutely nothing, but I can't delete it without crashing, so I have to leave it in.

new force scale.hipnc

Edited August 3, 2010 by Macha

[Macha]

I used this new particle force to melt an object.

There are easier ways of doing this but it seemed like a neat thing to test and I get a kick out of setting up such a thing myself!

It is a low res version but it should be possible to do much higher resolutions once I have refined and revisited the force calculations. (I think I can reduce manual tweakings and make it more automatic)

Vimeo-video:

new force scale d.hipnc

Edited August 3, 2010 by Macha

[Jason]

That does look pretty neat! I like it sir.