17-05-2026, 12:02 PM
(17-05-2026, 09:21 AM)josemendez Wrote: If I understood your code correctly, you're calculating velocity from the solver's world space positions in the previous/current frame (totalVelocity), then calculating its velocity in local space (velocityFromLocal) and subtracting them to get velocity due to the parent's movement (velocityFromParent).
Unless I'm missing something, this means that in addition to moving due to the parent-child relationship between the solver and an object driven by an ECS rigidbody, the solver is also moving in that object's local space and you need to scale inertial forces due to that as well? Not sure anymore what you are trying to do, but if it works for you it works!
Yes, I think you fully understand.
My goal is to drastrically reduce the inertia forces from velocityFromParent and angularVelocityFromParent.(17-05-2026, 09:21 AM)josemendez Wrote: The solver's linear velocity is transform.position - prevTransform.position. To be consistent we have to calculate angular velocity using backward finite differences as well, and that means using an r vector that's also expressed in the previous frame's space.
So you mean this is just possible inaccuracies because how we are stepping in time?
Are you sure we should not use prevFrame here instead when we get wPos? It feels weird to express the point in the current frame, but then use previous frame center to get the vector.
Code:
float4 wsPos = inertialFrame.frame.TransformPoint(positions[i]);Thanks


