We want to allow the user to specify how much a module (single/hub) can be moved/rotated by elfin-solver.
The complete ideal solution
Allow the user to specify a ""fixation target"" (a special Blender object in elfini-ui), then use the vector between the module and the fixation target to define rotation tolerance angles. The tolerance settings doesn't necessarily need an UI because editing the exported file is probably quicker than going back and forth between UI, export, and elfin-solver (- Fabio). This will not be a problem if the UI invokes elfin-solver behind the scenes without passing files. One problem with the file editing method is that if elfin-ui overwrites this file (in a new save etc.), the user-entered values would be gone unless we also re-parse.
Counter argument
Spatial tolerances are a nice-to-have, but is really beyond v2. Since the user invariably touches up the design that elfin produces anyway, elfin should be sufficiently useful without this feature.
Another problem arises when modules have translation/rotation tolerances. Originally, tolerances were intended to be a hint for elfin-solver to decide when imperfect bridges (of 2H work areas) can be accepted without further search. If we allow modules to float/rotate around, elfin-solver needs to solve the brdige design problem plus docking with multiple parts (possibly in different order). The complexity explodes.
Proposal going ahead
Elfin-solver will support spatial tolerance between module networks and pg networks. Elfin will not attempt to move or rotate any user-defined modules, but achieve similar effect using hinge tolerances (I guess we'll call this "hinge slack"). The responsibility of fixing up unclosed loops lies in the user's hands.
Implementation guide
Free: ignore tolerance, since there's nothing to hinge on.
One Hinge: after finding best solution, "swing" the solution sequence while leaving module network stationary to achieve better score (if exists).
Two constraint: same as one hinge but one end may be unclosable, so the interface will be left open. We cannot move any of the hinges because they effect other work areas.
Related TODO: #24.
We want to allow the user to specify how much a module (single/hub) can be moved/rotated by elfin-solver.
The complete ideal solution Allow the user to specify a ""fixation target"" (a special Blender object in elfini-ui), then use the vector between the module and the fixation target to define rotation tolerance angles. The tolerance settings doesn't necessarily need an UI because editing the exported file is probably quicker than going back and forth between UI, export, and elfin-solver (- Fabio). This will not be a problem if the UI invokes elfin-solver behind the scenes without passing files. One problem with the file editing method is that if elfin-ui overwrites this file (in a new save etc.), the user-entered values would be gone unless we also re-parse.
Counter argument Spatial tolerances are a nice-to-have, but is really beyond v2. Since the user invariably touches up the design that elfin produces anyway, elfin should be sufficiently useful without this feature.
Another problem arises when modules have translation/rotation tolerances. Originally, tolerances were intended to be a hint for elfin-solver to decide when imperfect bridges (of 2H work areas) can be accepted without further search. If we allow modules to float/rotate around, elfin-solver needs to solve the brdige design problem plus docking with multiple parts (possibly in different order). The complexity explodes.
Proposal going ahead Elfin-solver will support spatial tolerance between module networks and pg networks. Elfin will not attempt to move or rotate any user-defined modules, but achieve similar effect using hinge tolerances (I guess we'll call this "hinge slack"). The responsibility of fixing up unclosed loops lies in the user's hands.
Implementation guide