@Nagra_00_ not to say having a faster simulation would not be a good thing the issue with multithreading is how to track everything so that it acts as it should. Example is two balls (whatever's) one at 0 and the other at 100. They both are moving towards each other at a speed of 90 units a measurement and will collide in real life. In the single thread ball1 travels from 0 to 90 and is still 10 units from ball2. Now ball2 starts to be moved and can only get 10 units before running into ball1 and some type of collision occurs and the effects calculated. Now if we were to run them at the same time ball1 would travel from 0 to 90 and be 10 units from the location where ball2 started, no collision. Ball2 would start at 100 and move to 10 and be 10 units from the starting location of ball1 and still no collision. The next cycle through the movement the two objects are now 80 units apart and heading in opposite directions so will never collide. If everything moved at a constant rate it maybe possible to multi-thread, but most threads will be stuck waiting for the largest most time consuming calculations to complete before going on to the next cycle. if they moved at different rates the small fast objects might complete their travel and never encounter the obstruction slowly moving into their path. Think of it like a bullet and a car. The bullet may only require to check 50 points per cycle and can complete 100 cycles per second. The car requires 500 points and can complete only 10 cycles per second. At point (frame) 1000 the two objects car and bullet should be at the same location and cause a collision. However the bullet only took 10 seconds to get to the location and found nothing there since the car is still 90 seconds behind in calculated space.

It is issues like this and others that make trying to multi-thread very difficult.

Poser 5, 6, 7, 8, Poser Pro 9 (2012), 10 (2014), 11, 12, 13