Physics inside Houdini

[csp]

I would like to understand how Physics works inside Houdini's DOPs. For that I have runned few tests and went inside dop nodes.

The most import variables are:

v (velocity)

force

targetv

impulse

mass

accel (which exists only on old POPs)

Time

Timeinc

 

The rules:

 

force = mass*accel

accel = v*Timeinc
P = accel + Pprevious
v = P/Time

 

All these are proven, but where it gets confusing is on the rest attributes: force,targetv,impulse

On my test I have found that when you set manually with POP Wrangle a vector value to force or targetv this will take in count the mass inside the solver. So the same force will move further a light object over a heavy one. So you dont have to multiply your input vector with mass yourself. So far, so good.

About targetv, on my test I found that:

force = {0,0,200}

and

targetv = {0,0,200} * Timeinc

Both will give you the same result. So you can say that:

force = trargetv / timeinc

So what the point to have both?

And what about Impulse? In theory

impulse = force/Timeinc

Is that right inside houdini?

 

For example building a RBD Pack solver where takes in count from impacts (impulse*normal) and from other POP forces, attributes force and targetv.

How can we bring them to the same unit in order to get its length and compare it with the same threshold?

 

cheers

Edited January 7, 2015 by cparliaros

[bandini]

I may be wrong, but I am not sure about some of your initial statements...

 

force = mass*accel
accel = v*Timeinc
P = accel + Pprevious
v = P/Time

 

 

accel is change in velocity over change in time, rather than v * Timeinc

P should be Pprevious + v*Timeinc (since V is measured in units per second, rather than per frame)

v is change in position over change in time

[paxsonsa]

Adam makes a good point about your initials but for you question about the force and targetv,

 

To my understanding targetv is primarily used in the calculation for Air Resistance. 

 

Your thought about impulse is correct in terms of how Houdini uses the phrase impulse ( as a per frame value ).

 

 

 

 

For example building a RBD Pack solver where takes in count from impacts (impulse*normal) and from other POP forces, attributes force and targetv.

How can we bring them to the same unit in order to get its length and compare it with the same threshold?

 

I am not sure what you mean nesscary by that statment other then you would want to take the cummulative forces of all forces in your network and then do something to them?

[harima]

Yep the rules you assume look wrong.

 

In calculus terms. Acelleration is the derivative of velocity and velocity is the derivative of position.

In simpler language and in case of constant acceleration then acelleration is just a constant number . Velocity is then calculated by adding and accumulating this constant number every frame . Then the result for velocity is used to update position the same way.

I guess in a point wrangle inside a solver it would look like this :  

v@accell=set("constant",0,0);

v@v+=v@accell;

v@P+=v@v*@TimeInc;

 

correct me if I am wrong!

[paxsonsa]

I agree Stavros,

 

I wonder if houdini's acceleration attribute is impulsive (units/frame) or if uses units/s and then multiplies by the TimeInc. I believe it is the latter.

 

Does that sound right? I seem to remember multiplying the accel/force by TimeInc when I was doing some flocking and swarms.

[csp]

I am not sure what you mean nesscary by that statment other then you would want to take the cummulative forces of all forces in your network and then do something to them?

 

Thanks for the reply and correction. Let me make it more clear.

I have bullet simulation where in a multi solver, a Buller Solver is connected, followed by another Sop Solver where auto freeze packed primitives with velocity and angular velocity loser than a given threshold. This is happening gradually until velocity is 0 and sets active variable to 0.

Then you have an option to wake it up. My initial idea was to make it work when there is an impact from an active primitive where its impulse is great than a given threshold and this works like a charm @force = (@impulse*@normal).

 

I want to be able to wake up a frozen primitive not only on impacts but on forces like POP Wind or POP Attract.

Wind exports a targetv attribute and attract exports force attribute.

 

I want to have the same threshold for impulse, force and targetv in order to wake up a frozen primitive. My problem is that all those three variables are measuring different things.

 

So if I will say (length(@force) > threshold) || (length(@targetv) > threshold) || (impulse > threshold) will be wrong. Isn't it?

[paxsonsa]

So if I will say (length(@force) > threshold) || (length(@targetv) > threshold) || (impulse > threshold) will be wrong. Isn't it?

 

Hey Christos,

 

I understand what you mean now. I don't think that the method you propose is wrong at all. Instead I may create an attribute (or variable) that is the sum of the forces and compare that value to a threshold. If it evaluates true, set the Packed RBD  to active. Though! You may need to perform this before the bullet sop depending on when the auto-freeze is calculated and if the particles (packed prims) would receive a velocity before that freezing is computed.

 

I feel like I am not being entirely clear? What do you think?

[csp]

Hey Christos,

 

I understand what you mean now. I don't think that the method you propose is wrong at all. Instead I may create an attribute (or variable) that is the sum of the forces and compare that value to a threshold. If it evaluates true, set the Packed RBD  to active. Though! You may need to perform this before the bullet sop depending on when the auto-freeze is calculated and if the particles (packed prims) would receive a velocity before that freezing is computed.

 

I feel like I am not being entirely clear? What do you think?

 

 

Hmm, I am not sure.

I have the auto freeze solver as the last solver, after the bullet solver and all the forces in between. This way the freeze solver can read the targetv or force attributes if available and compare their magnitude to a threshold and a you said all you have to do is to make them active which will allow these variables to effect the velocity. But that wake computation inside autofreeze solver will run only for static primitives. And on the other hand the freezing computation which performs before wakeup run only in active primitives. In my tests works great.

Edited January 8, 2015 by cparliaros

[paxsonsa]

I would love to see the example if you every get the chance to upload a file! Have you used H14 with PBD yet?

[csp]

I would love to see the example if you every get the chance to upload a file!

I am afraid that I am not allowed to upload any hip file. but the setup is very simple and in my previous two replies I have described most of it. The only missing is how which impact point belongs to which packed prim and the answer is 

int match = findattribval(3, "point", "otherobjprimnum", @ptnum); 

Have you used H14 with PBD yet?

 

I had a quick look to H14 and PBD with sand solver which in my test was very slow (maybe on the official release it will be improved on speed).

Have you used it?

Edited January 8, 2015 by cparliaros

[paxsonsa]

I am afraid that I am not allowed to upload any hip file. but the setup is very simple and in my previous two replies I have described most of it. The only missing is how which impact point belongs to which packed prim and the answer is 

int match = findattribval(3, "point", "otherobjprimnum", @ptnum); 

I had a quick look to H14 and PBD with sand solver which in my test was very slow (maybe on the official release it will be improved on speed).

Have you used it?

Oh mce!

 

I haven't played with it much yet but out of the box it seem nice, I am eager to play with the modeling tools to see how those have been improved.