Algodoo

Overall, very nice work on the scene! It looks good and it seems to function quite well with just one exception:

When I press any of the throttle increase keys (1 ~ 4) some other part of the scene continuously forces scene.my.throttle = 0. That makes the throttle somewhat erratic. Maybe add a line of script that holds off setting scene.my.throttle to zero as long as keys 1 through 4 are being pressed? That should eliminate the erratic throttle action. Just a suggestion.

OR, maybe just eliminate the script that automatically sets the throttle to zero? Just let the user set it to zero with the zero key if he/she wants to.

@Xray

Sure. The throttle is no longer set to 0. But! it will load the engine if throttle is not at 0 because it will rev from idle to 1500+ rpm in like 5 frames.

Also, cylinder wall springs are forceDirectSolve now.

Edit: You can also press the down arrow key @ 0% throttle to return to idle.

I'm familiar with the forceDirectSolve parameter but I never learned what it does for how the scene operates. Could you please explain it?

Xray, I actually just learned about the function from The Linkage the other day. He (or she ) suggested it would improve my "spring bearing" stability (holding a circular gear in place with springs instead of hinges) under high loads. It did! It also improved the piston lateral wandering in this high stress design.

From my current understanding, the springs will be solved instantaneously and at a single point in the physics code instead of iteratively through the simulation process/algorithm. I have no idea how it actually works though, just my first uneducated guess.

I did a basic test where the simulation does not have enough frames to accurately solve the movement of a sprung mass (spazzing some circles out on a spring with low damping and high constant)

I then compared acceleration graphs of the two circles flying around at 1000+ m/s and bouncing into the ground.


It seems that the sprung mass with foceDirectSolve == True is MORE stable and reduces its speed, which is correct since both springs have slight damping.

The other sprung mass with forceDirectSolve == False is UNSTABLE. Its velocity is still increasing even though its damping is a positive value to over 3x the velocity of the other in the same frame.

We're talking extreme cases but on a micro level it adds up because the process is the same. Hopefully I didn't waste our time figuring this out. I have long been familiar with the pitfalls of forceDirectSolve == False springs with high constants and/or damping, so I know exactly where to look.

Wow, Ky13harbor9, you are very smart! Thank you for that excellent explanation!