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
Vex gravity in fps (instead of seconds)?
4946 13 1- olivierth
- Member
- 1010 posts
- Joined: 4月 2017
- Offline
- Andr
- Member
- 900 posts
- Joined: 2月 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:
https://en.wikipedia.org/wiki/Equations_for_a_falling_body#Equations [en.wikipedia.org]
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]
- jsmack
- Member
- 7802 posts
- Joined: 9月 2011
- Online
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:
Note that v here is meters per frame and not meters per second as integrated by pops.
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.
- Andr
- Member
- 900 posts
- Joined: 2月 2016
- Offline
- jsmack
- Member
- 7802 posts
- Joined: 9月 2011
- Online
- Andr
- Member
- 900 posts
- Joined: 2月 2016
- Offline
- jsmack
- Member
- 7802 posts
- Joined: 9月 2011
- Online
- olivierth
- Member
- 1010 posts
- Joined: 4月 2017
- Offline
- olivierth
- Member
- 1010 posts
- Joined: 4月 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?
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; }
- Andr
- Member
- 900 posts
- Joined: 2月 2016
- Offline
https://en.wikipedia.org/wiki/Equations_for_a_falling_body#Equations [en.wikipedia.org]
first equation shows you are very close actually
first equation shows you are very close actually
Edited by Andr - 2019年7月28日 15:30:54
- tamte
- Member
- 8592 posts
- Joined: 7月 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:
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
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
FX Supervisor
Method Studios, NY
- olivierth
- Member
- 1010 posts
- Joined: 4月 2017
- Offline
- Akelian
- Member
- 34 posts
- Joined: 7月 2015
- Offline
- tamte
- Member
- 8592 posts
- Joined: 7月 2007
- Online
Akelianbe careful with this assumption as it is not necessarily true
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;
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 - 2022年7月19日 12:33:22
Tomas Slancik
FX Supervisor
Method Studios, NY
FX Supervisor
Method Studios, NY
-
- Quick Links