Simulating physics faster than normal

[hexed rock]

HI everyone!
Im working on a small billard/8-pool game project. I want to make 'AI' opponent which will play with player. For now the 'AI' is just heuristic search which means that it shoots lots of possible shots, and checks which performed the best. I will be using it later on to train real AI. However the issue is that, the physics simulation takes way to long. If i for example make simulation that makes 360 shots, every shot will take at least 20-30 seconds to simulate and its waaaay too long.
I have tried changing Time.timeScale, but it does not seem like right option, because then simulation had lots of bugs (balls flying throught pool table or just disappearing). My second tought was to use Physics.Simulate() function, and in every FixedUpdate call make some sort of loop and invoke it 10, 100, 1000 times or something. And this also does not seem like its doing anything faster.

So how would you approach this? is there any way i can simulate shots on pool table faster? Thanks for responding!

[maiden rivet]

I feel like there was a different way in the past, but it seems like in the latest version you can do it via a physics scene:
https://docs.unity3d.com/6000.3/Documentation/ScriptReference/PhysicsScene.html

[maiden rivet]

Also physics simulate should work, but perhaps it shouldn't be in the fixed update and simulation mode should be set to script. Check the docs for more info.

[autumn elm]

Use Simulate () manually, yea

It's not any different with multiple scenes vs one scene

FixedUpdate and Update etc basically don't matter at this point. You want to just run Simulate the desired number of times as fast as possible.

You might consider using a coroutine or a timer though to make sure you don't spend too much time in one frame doing the computation.

[scarlet spear]

Increasing the timescale alone shouldn't cause bad physics, unless part of your game depends on logic that runs in Update. The amount of time per physics timestep remains the same

(this is why you have to reduce the fixed timestep when doing slow motion: otherwise, you're getting 50 physics updates per in-game second, which means you're only seeing a few physics updates per real-world second

I imagine it'll break down if it can't keep up with the number of physics ticks needed

[hexed rock]

Wow, thank you all for responding i did not expect to get response this quick very appriciate it

[hexed rock]

Well my tought was that if i in every fixed update (because in fixed update physics is calculated as far as i am concerned) i execute physics simulate in a for loop 1000 times physiscs will run 1000 times faster

Maybe i will try the other way

[hexed rock]

Yeah coroutine approach seems interesting i will give it a shot thank you

[hexed rock]

Most of my logic runs in coroutines, because its turn based game and its easier to manage in coroutines

So maybe thats way it messed up with the logic

I mean, increasing timescale to values like 5 or 10 didnt broke anything, but 100 and 1000 yes