Open KohmeiK opened 2 years ago
In this gif, I showcase the current behavior of how forces update when you drag a joint. Dragging a joint will only update the force's position based on a set distance away from a given joint. This logic is not correct since the user can drag a joint closer to another joint, resulting in the force coming out of the link. The desired goal should be that by dragging the joint, the force should update at a fixed ratio away from the joint.
In grid-utils.service.ts file in the dragJoint method, the force logic updates based on what is shown in the image above. Currently, PositionSolver.determineTracerForce is utilized to determine the force position. We do not want to change this function since this function is utilized to determine all force positions throughout a mechanism animation (or valid positions that a mechanism can travel). Instead, we want to create a new function in PositionSolver to determine what the new force position should be. Ultimately, this logic should capture the initial ratio before dragging the joint and keep this ratio constant throughout dragging the joint. Similar to PositionSolver.determineTracerForce, the new function will set a new value within PositionSolver.forcePositionMap map, which will be referenced shortly after making this function call (as shown above).
With a simple binary link, it is simple to know which ratio to use since there are only two joints. However, in the situation where there are multiple joints in the mechanism, it is worth exploring to know whether we should continue to utilize this ratio logic or not. In my head, this logic should only apply to the farthest joints. It is also important too to consider the cases where the link contains subsets - only joints within a subset (child) should be considered, not the link itself (parent).
Do let me know if you have any questions on anything.
It should stay the same relative distance from each point. For a binary link, if the force start point is 20% between joint A and B that ratio should be maintained, not the absolute distance. This way when the link is shortened it says inside the link.
Somewhat related to #48
The OLD version has this fixed