Forums Houdini Indie and Apprentice Vex gravity in fps (instead of seconds)?

Vex gravity in fps (instead of seconds)?

   4884   13   1
User Avatar
olivierth
Member
1007 posts
Joined: April 2017
Offline
 
Hi!

I know POP is probably the way to go when doing simulations of points but I'm trying to learn more about VEX.

I just want to apply a gravity force (9.80665) but since my vex calculates at every frame rather than seconds, how can I convert gravity to meters per frame?

-Olivier
 Report
User Avatar
Andr
Member
900 posts
Joined: Feb. 2016
Offline
 
@Time attribute in a Vex wrangle is expressed in seconds, already adjusted to your playback speed of choice (24fps, 25fps, 30fps, etc)

I guess this should be correct:
vector g = {0, -9.8, 0};
@P = @P + ((g * @Time * @Time)/2);

https://en.wikipedia.org/wiki/Equations_for_a_falling_body#Equations [en.wikipedia.org]
 Report
User Avatar
jsmack
Member
7767 posts
Joined: Sept. 2011
Offline
 
Acceleration is derivative of velocity. Velocity is derivative of position. The derivative is expressed with respect to a change in time, or one second. To express by a different interval multiply by delta t, or for an acceleration delta t squared.

You still need to integrate velocity in order to integrate an acceleration and apply to position.

in a wrangle you can do:

float g = -9.8 * @Timeinc * @Timeinc;
@v.y += g;
@P += @v;

Note that v here is meters per frame and not meters per second as integrated by pops.
 Report
User Avatar
Andr
Member
900 posts
Joined: Feb. 2016
Offline
 
mmh what did I do wrong?
 Report
User Avatar
jsmack
Member
7767 posts
Joined: Sept. 2011
Offline
 
Andr
mmh what did I do wrong?
I don't think you did anything wrong. I guess you can do an analytical integration, rather than a numerical one. I assumed it was going into a solver. But doing a double integral means you don't have to, so I guess your answer is better.
 Report
User Avatar
Andr
Member
900 posts
Joined: Feb. 2016
Offline
 
ok, thanks for explaining.
Very nice to know how to do it inside a solver.

Interestingly it seems that the two methods we proposed move the object with different velocity. Mine seems a little bit slower.
 Report
User Avatar
jsmack
Member
7767 posts
Joined: Sept. 2011
Offline
 
Yeah I found that too. The numerical method (solver) is not as accurate as the analytical method (yours).
 Report
User Avatar
olivierth
Member
1007 posts
Joined: April 2017
Offline
 
Wow, thanks for all the explaining! And yes, I was trying to use this inside a Solver.

Now back to dropping points!

-Olivier
 Report
User Avatar
olivierth
Member
1007 posts
Joined: April 2017
Offline
 
Hi!

I tried the solver version of the code and tweaked it to fit my needs. After 24 frames my points is at -5.10763 (started at 0 with no velocity). …I'm guessing it should be at -9.8 after a second. What am I doing wrong?

v@vel;
vector Pref = @P;
vector velRef = @vel;

float Gstrength = chf("gravity_ms2");  // 9.80665
vector Gdir = normalize(set(0, -1, 0));
vector G = Gdir * (Gstrength * (@TimeInc * @TimeInc));  //convert to frames instead of seconds

@vel += G;
@P += @vel;

if(@Frame == 1)
    {
    @P = Pref;
    @vel = velRef;
    }

Attachments:
Gravity_too_slow.JPG (144.0 KB)

 Report
User Avatar
Andr
Member
900 posts
Joined: Feb. 2016
Offline
 
https://en.wikipedia.org/wiki/Equations_for_a_falling_body#Equations [en.wikipedia.org]

first equation shows you are very close actually
Edited by Andr - July 28, 2019 15:30:54
 Report
User Avatar
tamte
Member
8551 posts
Joined: July 2007
Online
 
let's simplify things a bit
1. don't use vel in frames, it makes it unnecessarily confusing, keep it in seconds as it is used in whole Houdini and it makes it easier to doublecheck your values
2. why calling it v@vel, when there is perfectly good standardized v@v everywhere in Houdini?

here is a bit simplified code:
float Gstrength = chf("gravity_ms2");  // 9.80665
vector Gdir = set(0, -1, 0);
vector G = Gdir * Gstrength ; 
v@v += G * @TimeInc;
@P += v@v * @TimeInc;

3. while this will not change your result, it may be easier to understand whats going on
on frame 24, you will see that v@P is about -5.1 which is correct (or within expected error considering the time step size and integration type)
what you should expect to be around -9.80665 is value of v@v in seconds, which if you look at spreadsheet it is, so all seems to be fine
Tomas Slancik
FX Supervisor
Method Studios, NY
 Report
User Avatar
olivierth
Member
1007 posts
Joined: April 2017
Offline
 
Oh wow! All that time I kept thinking it should reach 9.8m (distance) instead of 9.8m/s speed! DOH!

Thanks for the info!

-Olivier
 Report
User Avatar
Akelian
Member
34 posts
Joined: July 2015
Offline
 
since I found this post from a google search, the solution I was looking for (to get $FPS in vex) is:
float FPS = 1/@Timeinc;
 Report
User Avatar
tamte
Member
8551 posts
Joined: July 2007
Online
 
Akelian
since I found this post from a google search, the solution I was looking for (to get $FPS in vex) is:
float FPS = 1/@Timeinc;
be careful with this assumption as it is not necessarily true
it's better to inject fps into the code as $FPS, since it is constant it is not gonna cause issues

because @TimeInc is duration of the current timestep in s, so if used inside of a dopnet or solver with substeps or above gas substep, etc. will be smaller than 1f and therefore 1/@TimeInc will not equal to FPS
Edited by tamte - July 19, 2022 12:33:22
Tomas Slancik
FX Supervisor
Method Studios, NY
 Report
  • Quick Links