particle velocity from color

[meldrew]

Hey,

 

I'm trying to advect some scattered points along a curl noise (or similar) - controlling their velocity along the curl based on their color attribute - which is coming from a pointvop.

 

I'm basically trying to achieve this kind of motion, but driving the point velocity with color:

 

 

Which the process I found outlined on this thread:

 

http://forums.odforce.net/topic/23447-particle-collisions-inside-animated-mesh/?p=138142

 

 

I have made a start on a scene, but have reached the limits of my knowledge

 

Could anyone point me in a good direction to achieve a comparative result? Would grains be a better approach?

 

Thanks for anyone who takes the time to take a look - I'm super appreciative!

 

 

An important note: I'd like the points/particles to inherit the point color at every frame, rather than just the first. So that the animated noise can drive the advect velocity.

 

THANKS!

advect_by_color_test.hip

[mestela]

The pop examples in the 'differential growth with curves' essentially do what you're after. A pop interact force makes the particles self collide, a terrain force or static collide will keep the particles on the mesh, and a force pop (or force of your choosing) will swirl them.

http://forums.odforce.net/index.php?app=core&module=attach&section=attach&attach_id=26891

[Farmfield]

Something like this - I just had to test using color for velocity - though noise data is noise data, but still, wanted to test it.

untitled.hip

[meldrew]

The pop examples in the 'differential growth with curves' essentially do what you're after. A pop interact force makes the particles self collide, a terrain force or static collide will keep the particles on the mesh, and a force pop (or force of your choosing) will swirl them.

http://forums.odforce.net/index.php?app=core&module=attach&section=attach&attach_id=26891

 

Hey (again) Matt Thanks for the heads up on this... I did come across your post on this thread, but I must admit I had a hard time understanding each step... am just having another look now/today.

 

Something like this - I just had to test using color for velocity - though noise data is noise data, but still, wanted to test it.

 

Thanks so much for the file Johnny! I'm going to spend some time today going through it & hopefully learning exactly what's going on there & re-building it in my scene.

 

At first glance it seems to to exactly what I was looking for.

 

I must say, as a relative newbie poster on here, I am so appreciative of this positive forum community. Hopefully as my knowledge increases I can start to help others out as well!

[meldrew]

The pop examples in the 'differential growth with curves' essentially do what you're after. A pop interact force makes the particles self collide, a terrain force or static collide will keep the particles on the mesh, and a force pop (or force of your choosing) will swirl them.

http://forums.odforce.net/index.php?app=core&module=attach&section=attach&attach_id=26891

 

 

Something like this - I just had to test using color for velocity - though noise data is noise data, but still, wanted to test it.

 

 

Hey,

 

I've managed to make a Frankenstein of both Johnny's & the 'differential growth' file Matt suggested. It's actually working ok now.

 

However I have 1 further question...

 

How would I set up the pops so that the noise color gets set in a pointvop which is then fed into the popnet? Is that possible?

 

I'd like to do my noise animation outside of the popnet just so I can preview it without having to simulate.

 

If it isn't possible - any ideas how I could optimise my preview?

 

Thanks again for the help!

[Farmfield]

Easy-peasy. And though I kept the base setup using color and piping it into normals for visualization and to velocity in POPs, there's really no reason to do this using color, better pipe the noise straight into velocity and update it in a SOP solver inside POPs.

color_to_vel.v2.hip

Edited April 16, 2016 by Farmfield

[meldrew]

18 hours ago, Farmfield said:

Easy-peasy. And though I kept the base setup using color and piping it into normals for visualization and to velocity in POPs, there's really no reason to do this using color, better pipe the noise straight into velocity and update it in a SOP solver inside POPs.

color_to_vel.v2.hip

Nice... I overlooked the cd inherit attrib in the popnet because I thought a '*' in that field meant it inherited all attribs?

 

I have something which is working nicely now - Thanks so much for you help!

 

On a similar note though, let's say I wanted to make the same noise > vel setup, but set a rule that a single point/particle could only move 'x' distance from it's starting/birth position before being constrained - How would I go about that?

 

Something along the lines of rest positions? Or is that a little overcomplicated.

 

I'm just thinking that over a long scene (thousands of frames) This setup will likely end up with all particles collected in a particular area, or along the edges if using a grid as the source.

 

This will hopefully be my last question on this thread I promise!

[Farmfield]

Sorry for the late reply, I've had this tab open for a while now, though, so time to get to it.

Here's a setup for checking distance and changing color based on a threshold. And checking the distance is pretty simple to set up, I write the initial position into an attribute on frame one, then check the distance to the current position against that and if the value is greater than what I set, I shuffle the particle into a group.

pop.red.distance.hip

If you want to check distance traveled, you need to measure the difference each frame and accumulate that in an attribute, then check that attribute for a set limit. Here I set that up in a SOP solver and then I compare that value to a set limit in the POP VOP and shuffle selected particles into a group.

pop.red.accum.distance.hip

Edited April 21, 2016 by Farmfield

[meldrew]

3 hours ago, Farmfield said:

Sorry for the late reply, I've had this tab open for a while now, though, so time to get to it.

Here's a setup for checking distance and changing color based on a threshold. And checking the distance is pretty simple to set up, I write the initial position into an attribute on frame one, then check the distance to the current position against that and if the value is greater than what I set, I shuffle the particle into a group.

pop.red.distance.hip

If you want to check distance traveled, you need to measure the difference each frame and accumulate that in an attribute, then check that attribute for a set limit. Here I set that up in a SOP solver and then I compare that value to a set limit in the POP VOP and shuffle selected particles into a group.

pop.red.accum.distance.hip

Hey Johnny,

 

No worries on delayed reply - I appreciate that you were thinking about it at all!

Thanks for the scene files... I can follow the logic in the vop (accumilated.hip), where you've setup a compare, and then a two way. I'm going to sytudy it further and see if I can apply it to my setup, but as yet no such luck.

When I change the constant values, they don't seem to have any impact of the behaviour of the particles/distance at which they change color?

I've attached a .hip if, being the kind soul that you are, you'd take a look at?

 

I guess a better description of what i'd like to do is set a defineable individual softlimit to each particle based on its starting position.

And in an ideal world, possibly find a way to do this in sopsolver/wrangle so that I don't have to continually sim stuff to animate my color noises? It because quite hard to make artist decisions when the particle count gets above a few thousand (proposed final output will be at least 1mil).

 

As always, all help & tips come with a million thank you's. This setup is teaching me loads, and I hope to share it when I'm done!

 

pop.red.accum.distance_tim.hip

[Farmfield]

Well, the the twoway input value you changed is what I use to set group membership - 1 = in group, 0 = not in group - and it's the first constant in the compare that, well, compares.

That being said, the whole twoway switch isn't needed anyway, the compare outputs a 0/1 value, so now I piped it right into the group bind export instead.

pop.red.accum.distance_tim_fix.hip

[meldrew]

AAhhhhh, yes of course, I get it now. (also compare value has to be relevant to the amount of motion, of course. I was putting too large values in before).

 

Ok, so I now fully get that, and I understand that once a particle passes a certain 'compare' threshold, it get's put in a group. very handy.

 

I guess next for me to understand/look into is how to put a softlimit type behaviour on each particle as it reaches the defined thershold. If that's even possible?

 

Can I use spring constraints on pops? I thought that may be easier & perhaps I could use the birth points as anchors.

 

Thanks again!

 

 

[Farmfield]

Simplest way to create a softlimit is to use the accumulated dist attribute in itself, just use a fit range and remap it, e.g, between zero and one and then pipe it into a multiplier for velocity, force, etc...

As for using constraints on a particle system, of course it's possible but as for setting it up, depends on what the desired behaviour is. I haven't dug that deep into the world of constraints, but it's not overly complicated.

Edited April 21, 2016 by Farmfield

[meldrew]

Ok, that sounds simple enough (famous last words!) let's see if I can get it working.

 

Thanks!!!

[Farmfield]

Like this.

pop.red.accum.distance.soft.hip