How to account for point animation in Solver SOP that comes before it?

[magneto]

Hi,

I had a simple object where I animated the transform.x, then added a Solver SOP afterwards. I created a Transform SOP that increment's transform.y but when I display the result of the Solver SOP, the object only moves in Y, not in X.

Does the Solver SOP not account the animation that comes before frame by frame? If not, how can I do this?

Thanks

[anim]

it doesn't since you are running dopnet inside which takes first frame and then at every timestep it runs all sops in contained sopnet so it's up to you to decide what is happening inside

you can still access the geometry of any input of Solver SOP inside

there are already placed sops for you named Input_1-4

so you should have no problem copying any information you need from live inputs onto simulated mesh as a part of a simulation step and in any way you want instead of letting Houdini do it in some way by default which would be very constraining

[Solitude]

The sop solver isn't set up to take in deforming geometry by default. You can have it get the geometry every frame, but I think it overwrites all the attributes when you do that, so (assuming point count doesn't change) I usually just use a simple vopsop to copy P from the input1 to Prev_Frame.

Edit: Tomas beat me to it!

Edited June 14, 2013 by Solitude

[magneto]

Thanks guys. I wanted to do something like a jiggle deformer I saw in Maya. Copying P from input1 using a VOPSOP sounds good, but how can I get the previous position in the animated geometry? Because I need to calculate the velocity from the previous point position to the current point position, and use that.

Maybe I shouldn't use the Solver SOP for this?

[anim]

as the inputs are live you can use timeshift sop to get previous frame of any input

EDIT: you can as well use CHOPs for jiggle (there is even a shelf tool for that but that's not per point)

EDIT2: you can even use trail SOP to compute velocity prior to Solver SOP then access it inside and compute offset from it just for actual timestep of the dopnet since it doesn't always have to be 1 frame

Edited June 14, 2013 by anim

[magneto]

Thanks anim, I will use the timeshift sop then. I just wanted to create the same tool for practice. But Jiggle CHOP is also good to know too

[Solitude]

You can do jiggle or lag on each point with chops, but I wouldn't suggest it if it's a heavy mesh. Though, you could also do a low res version then cloth capture it over to a high res model.

I think it's a matter of the order you do everything in. I (and others) have been able to do simple (or complex) particle systems using sop solver instead of pops, and this kind of falls into that category I think. I would have to think harder on how a jiggle deformer works to figure it out.

[magneto]

Thanks Solitude. I was actually watching from here:

http://www.cgcircuit.com/lessondetailcomplete.php?val=783

if you click "Jiggle Math", you can see the idea he is using pretty much. Since I never implemented this, I am not really sure why he has a goal attribute which has the exact same value as the currentPosition. But this is how he does it:

goal = points[i]
velocity = (self._currentPosition - self._previousPosition) * (1.0 - damping)
newPosition = self._currentPosition + velocity
goalForce = (goal - newPosition) * stiffness
newPosition += goalForce
# Store the states for the next computation
self._previousPosition = OpenMaya.MPoint(self._currentPosition)
self._currentPosition = OpenMaya.MPoint(newPosition)
self._previousTime = OpenMaya.MTime(currentTime)
newPosition = goal + ((newPosition - goal) * jiggleAmount)
[/CODE]

[old school]

It's just basic velocity weighted previous-current frame deformation that many Houdini users have been using for a long time.

I'd be using the Trail SOP over the Timeshift SOP btw but make sure to put a Timeblend before the Trail. The Trail SOP has some very nice ways of computing inter-frame point velocities on geometry in the past couple releases that has non-changing topology. Centre difference being the one I tend to use more often these days.

goalForce which you seem to be confused by is an artist-controlled bias toward the final geometry and not a real force per se. Just a Mix VOP with the velocity deformed geometry and the current frame geometry and would result in some overshoot in a simulation context where the "jiggle" comes in requiring heavy damping but in this implementation it's a linear damping. The CHOP jiggle uses a bi-phasic spring model that results in nicer jiggle.

As for CHOPs jiggle, that was implemented to jiggle points within muscles or on bones for characters so applying this to a 200k point mesh would slow things down and best to implement something in a SOP solver.

Finally, you can opunhide the pop_integrate DOP, place one in DOPs and peer inside the VOP networks used to compute the velocities and forces and re-purpose this for your own SOP solver. That's what I've been doing recently and the force model in place of acceleration gives you results you'd expect, and very fast.

Edited June 15, 2013 by old school

[magneto]

Thanks alot old school, very informative. I will give one of those options a try.