Hi, am I right to assume that high training timescales can cause issues with complex physics environments? Is there any straight-forward way of testing at what timescale the physics engine can’t keep up any longer? How do you guys usually pick your timescale values? Thanks!
I need to look into this some more. Changing the timescale shouldn’t affect the fixedDeltaTime (which is what physics uses, and what ML-Agents uses by default), so unless you have any logic in an Update() method, I’m not actually sure what will break down.
1 Like
I asked the rest of the team about this, and we don’t have a good answer. Using a higher timescale will change the relative frequency of FixedUpdate to Update calls, but as long as you’re only using physics and ML-Agents (and really, what else could you possible want?!), I think they’ll behave the same at higher time scales. You’ll just need to make sure that you don’t do anything that affects the simulation outside of the FixedUpdate calls, and only do things based on Time.fixedDeltaTime (which doesn’t change with timeScale) on not Time.deltaTime.
There were some anecdotal reports of physics objects tunneling at higher timescales, but that was for cases outside of our examples, and may have had to do with other game systems running in Update instead.
2 Likes
Thank you for investigating, @celion_unity !
I guess this is more of a general physics question then. One would need to devise a stress test that’s specific to a given physics environment. For what it’s worth, I found a more general test here GitHub - DragonGround/UnityPhysicsStressTests: Unity.Physics vs Havok vs PhysX vs Box2D
Yeah! Any physics call even without fixedDeltatime must be called in fixedUpdate()
I encountered myself condition like jittering articulation body by force in every Update()
But it works smoothly in fixed update!