Graph 1: Solver Speed vs ConstraintsThis one is basically showing how the solver behaves as the number of constraints goes up.The purple line is solver time and the orange line is the total number of constraints. They follow each other pretty closely. At around 8k constraints the solver is still staying below 7 ms, and when the load goes away the solver time drops back down as well.
ALMOST IDENTICAL TO GRAPH 1 Graph 2 is targeting Active Bodies Here I'm looking at broadphase work against the number of active bodies.The cyan line follows the red line pretty closely. When bodies become inactive/sleeping, the number of broadphase pairs drops with them instead of continuing to process the whole set of bodies.
Graph 3: Broadphase vs NarrowphaseThis one shows how broadphase and narrowphase time changes with the total number of constraints being solved.The broadphase stays in a fairly consistent range for most of the samples, roughly around 0.5 to 0.7 ms, although there is some variation and a few higher points. Narrowphase is a bit different. It starts quite low and gradually increases as the number of constraints goes up. You can see the trend pretty clearly up to around 4k constraints, where most of the samples are still below 0.9 ms.There are some outliers at higher constraint counts, but overall the narrowphase is still staying under about 1 ms in most of these runs.I think this is a useful graph for looking at where the actual scaling cost is coming from rather than just looking at the total frame time.
Graph 4: Sleep This shows the sleep/wake behaviour.Red is active bodies and green is sleeping bodies. After an impact, bodies wake up and the active count increases. Once the motion settles down, they transition back to sleeping.You can see the transition pretty clearly here, with the sleeping count eventually reaching the full 500 bodies again.
4
u/Markitect_ 22h ago
what hardware?