(2022-01-10, 8:39)Stefan Frenz Wrote: I could think of the collision detection as an indicator to end a directed move or directed rotation. This would allow something like "move/rotate in this direction until the first collision occurs, remember the colliding triangles and try to get (approximate? calculate?) the one-directional move/rotate value" as in the following examples: move green block to the right along the red line until it reaches the black block (becomes blue) or rotate the green block around the bottom left edge clockwise until it reaches the black block (becomes cyan).
Yes, that's exactly how I'd picture it working. And at least for the rotation example, the math already exists in this script. For the move example, if the movement vector is normal to the colliding plane then it's simple; otherwise I guess it's just some similar trigonometry.
And if it's user-directed, it shouldn't consume any amount of processing power (unlike e.g. scanning a whole big model for collisions). The user could simply drag or rotate a part as normal until a collision occurs, and if the "proximity snapping" option is enabled, the program would automatically snap the movement back to the collision point.
Best of all, if collisions can be detected between triangles and vertices, they can also be detected between snap objects, which could also allow for the long-desired "rotation snapping" feature! (Some tolerance would be required here, as not all real-world rotations give exact pythagorean ratios and rely somewhat on plasticity.)