Change physics accuracy

I can’t find a way to change the physics accuracy. I tried continuous collision detection, but instead of falling through walls, my character just gets slowed down or gets stuck in walls instead.
So the best way to fix this would be increasing the update frequency, but I can’t find, where to do this.
Changing the field timeStep in the bullet physics class to 1/120 for example seems not to help. This file probably doesn’t even get loaded, when I edit it.
So how can I change this time step?

1 Like

Try timeScale >

It kind of works, but doesn’t help. When setting body.physics..timeScale = 0.25;, I can set the speed four times as high without running through walls, but additionally, the character moves with slower speed, so it doesn’t help.

Yeah, sorry, it was shot in the dark :slight_smile: . Still u can study that code, and try to figure out… or file a FR, if nothing helps.

New Armory 3D physics with CDD is pretty solid, 3D molels behave correctly and does not pass through walls.

I got similar issues using the pre made character system.

It’s just my opinion, but better make your own character system the common way ( capsule based physics using velocity and a raycast for floor detection ).
It should work correctly against geometry environment.

1 Like

What’s CDD? (maybe CCD for continuous collision detection? I tried this in 0.6 and and doesn’t work)

The mesh, my character collides to, is a non-convex mesh for a landscape (with caves).

I’m writing my own character controller anyway, based on the third person controller, you can rotate using arrow keys and accelerate in four relative directions using WASD without becoming faster than some specified velocity.
Raycasts are not used yet, but they won’t solve the problem, that I can’t get too fast without passing through walls.
I just want to be able to change the timeStep in physics world. Probably this should be made public in that file?

You mean it does not work for the character controller only ?

( I tested a lot CDD and i got projectiles high velocity always stopped by walls, but perhaps there is some new bugs in 0.6 ? )

Raycast is accurate and not dependent on physic collisions between two models or velocity, useful to detect character on floor and manage jumping.

Did you tried to make some capsule collider physics and control it with velocity ? It should not pass through walls.

I think character physics issue is related to the character controller code, you should not have to change timeStep (because small projectiles with high velocity work correctly and don’t pass through walls).

Good luck with your character controller lol

I think for any normal character movement speeds you shouldn’t need CCD or any special collision detection. I have a public character controller that you can use as a base if you want to try it out. Making a character controller that works solidly can actually be pretty difficult. You run into a lot of unforeseen issues ( I did at least, I guess it was my first character controller :slight_smile: ).

You might want to try that out. I haven’t had any issue getting it not to go through things yet.

Also returning to what you were asking about the physics accuracy, I think that it is pretty much hard-coded at the moment, but it would be an easy fix to make it customizable from the blender interface. I might look into that. Here is the line that loads the simulation step. If I get the time I’ll check to see if I can get it configurable through the interface.



When enabling continuous collision detection, the problem is, when running on ground using velocity, I don’t fall through the walls, but instead I get slow or stuck, so it’s different to projectiles, which should stop.

Using raycast may help to get it work, but it won’t fix the real problem.
When the character collider has radius of 1m and the walls have no thickness, running with a speed of 60m/s will not work.
When raycasting too far, I will stop too early, when raycasting directly in front of me it just acts like a slightly larger collider, when changing the raycast distance depending on velocity, it may work, as long as I don’t collide with moving objects.

I didn’t try capsule collider, but I don’t think, changing the collider makes any difference.

I know it’s possible to work around that, and in most cases even preferable, but when the workarounds don’t work, having this option (which Unity also has), should also be possible.

I want to make something like an open world Sonic game, so the maximum speed should be very high, and I’m not sure if the maximum allowed velocity will be large enough for me.
And with open world, the problem should be fixed generally, not through level design and fixing special cases.

Well that is a bit of a special case isn’t it. :slight_smile: It shouldn’t be hard to let you configure the sim step time, it should be just a small UI change mostly. I’ll let you know if I get it working.

I didn’t mention yet, I was able to change the code of the physics world to use a smaller time step, but it was even worse. The movement didn’t seem continuously anymore.
I also checked, that preUpdate (;) didn’t get called more often than update, but I assume, it should.

You think that preUpdate should get called more often than update? You think it should run that as fast as the physics update then? I guess that might make sense. I’m not sure, this isn’t my specialty.

I assume, that’s what the physics preUpdate is for. Else I don’t see a reason, why it exists.

I’m not 100% sure what it is for but the update order is as follows:

  1. Update
  2. Physics Pre-Update
  3. Late Update

I know that you need Late Update if you want to do collision checking. If you try to check collisions on update, or pre-update you will actually be checking the collisions from the last frame because update and pre-update actually run before the physics simulation is stepped.

I had a problem once where my bullets were detecting collisions with walls one frame late because I was doing the collision check on update instead of late update.

it would be more interesting, where between these rendering occurs.
But even in this case, there are only two states, where these update functions can be called: after rendering and before physics or after physics but before rendering

  • Update is called before physics, before rendering.
  • Pre-Update is called before physics, before rendering ( but after update ).
  • Late update is called after physics, before rendering.

Then rendering happens and Update is called again to restarting the cycle.

so there’s no real difference between update and preUpdate when preUpdate does not depend on physics update time. There may be special cases, where one script depends on another script being called, but in these cases it would be more useful to have some way of ordering scripts (which unity does) or just multiple updates, which are not bound to physics.

Yes there was some discussion about ordering update callbacks:

You can run on some physics issues, i’m not sure changing physics update will solve it, but worth to try.
(Changing physics update could also alter game performance)

Perhaps CDD values could be tweaked to have greater range prediction for collisions ?

Checking with some forward direction raycasts will work before updating model position.
Or if Armory would support it volume raycast like sphere raycast in forward direction.
It’s how i would do it for such special high speed controller need.
Well… i don’t have others ideas lol