brendan mccloskey

I am following the excellent jit.phys video tutorial

https://cycling74.com/tutorials/introduction-to-jit-phys-part-1/

and have successfully created a bouncing ball, gravity and a moving floor (or 'paddle')

and have encountered a minor issue. As part of a larger patch, wherein the user (via force-sensing resistor -> gui slider) can hit a ball into the air by moving the onscreen paddle, occasionally the ball will pass through the floor, especially when the floor is moved very quickly. I have attached a small patch below to demonstrate (my 'net computer has issues with jit.phys, so apologies for the non-compressed file).

Hi
I am following the excellent jit.phys video tutorial 

jit-phys-tutorial-video-question

hi brendan. you need to set @kinematic 1 on your phys.body "paddle"

this tells the rigid-body that it's going to have it's position/rotation set based on your input, rather than based on the forces in the world.

this should fix your problem, but let me know if not.

this tells the rigid-body that it's going to have it's position/rotation set based on your input, rather than based on the forces in the world.
this should fix your problem, but let me know if not.


......it DID work; I did some quick research before I started tweaking, in order to get the desired functionality and......the problem returned.

I need the ball to have some real-world weight, so I have set the following parameters: @mass 3 @restitution 0.8, and the world gravity is quite extreme (-500!). And now, as before, if the paddle accelerates past the ball, it will pass through it. Please see the attached patch and image.

you could use "fixedtimestep", "maxsubsteps " parameters on "jit.phys.world" to increase the resolution of the simulation

https://cycling74.com/forums/jit-phys-world-physics-frame-rate-response-maxsubsteps-and-fixedtimestep

hi,
you could use "fixedtimestep",  "maxsubsteps " parameters on "jit.phys.world" to increase the resolution of the simulation
Rob Ramirez wrote a very useful note
https://cycling74.com/forums/jit-phys-world-physics-frame-rate-response-maxsubsteps-and-fixedtimestep
hope that it can help you
mathieu


Thanks mathieu, I'll read more on those two parameters; obviously there's a lot more going on than I understand - loads of experience with Max but none at all with Jitter; your suggested link was very helpful too.

not too sure what my own fps rate is, but I changed the qmetro from @interval 60Hz, to 10ms (any higher and the problem returns) and set the maxsubsteps parm to 2; this appears to have resolved the issue. I understand this is my own lack of knowledge, not a Jitter quirk. : )

edit
not too sure what my own fps rate is, but I changed the qmetro from @interval 60Hz, to 10ms (any higher and the problem returns) and set the maxsubsteps parm to 2; this appears to have resolved the issue. I understand this is my own lack of knowledge, not a Jitter quirk. : )


ideally, you want your physics engine update frequency (fixedtimestep) to match your render FPS.

if you use jit.window with @sync 1 (the default value), and a very fast qmetro (eg 1), your render rate will sync to your display refresh rate (usually around 60). this plays well with the default phys.world @fixedtimestep of 60.

however, if you run your render fps at 30, you need to adjust your physics hz as well, otherwise the physics simulation will lose time (and look like it's running in slow-motion). easiest solution may be to set @fixedtimestep = 30. this will fix the slow-motion effect, however 30 fps is not the ideal hz for the physics simulation (although it may be fine for many patches). the alternative is to increase @maxsubsteps to 2 (allowing the physics simulation to take 2 substeps for every render frame: 60 / 30 = 2)

more complicated physics scenes may require a faster update frequency to accurately simulate the objects. so you may wish to increase the fixedtimestep to something like 120 or 240, and the max substeps to either 120/30 = 4 or 240/30 = 8.

of course with any computer simulation, greater accuracy requires more cpu.

ideally, you want your physics engine update frequency (fixedtimestep) to match your render FPS.
if you use jit.window with @sync 1 (the default value), and a very fast qmetro (eg 1), your render rate will sync to your display refresh rate (usually around 60). this plays well with the default phys.world @fixedtimestep of 60.

Wow. Thank you so much for this explanation. Crystal clear.

jit.phys tutorial video, question