Currently, NTRTsim arbitrarily selects the "width" and "height" dimensions for tgBox. This means that (a) box orientation is not deterministic, which causes segfaults randomly in e.g. ForcePlateModel, and also does not allow specification of boxes that are rotated around the "length" axis.
Possible fixes include...
Provide a constructor with a unit vector for the direction of "height." We'll need to make some design decisions here, though: for example, what happens when the "length" axis an the "orientation" unit vector are not orthogonal? Does the simulator quit with an error message, try to find the closest orthogonal coordinate system, or revert to the default behavior?
Provide a "rotation" scalar parameter, similar to tgRod. This requires some implied assumptions about what is "width" vs. "height." That could be, for example, "at rotation=0, the width direction is always parallel to the X-Z axis, e.g. horizontal with respect to the world."
Currently, NTRTsim arbitrarily selects the "width" and "height" dimensions for tgBox. This means that (a) box orientation is not deterministic, which causes segfaults randomly in e.g. ForcePlateModel, and also does not allow specification of boxes that are rotated around the "length" axis.
Possible fixes include...
Provide a constructor with a unit vector for the direction of "height." We'll need to make some design decisions here, though: for example, what happens when the "length" axis an the "orientation" unit vector are not orthogonal? Does the simulator quit with an error message, try to find the closest orthogonal coordinate system, or revert to the default behavior?
Provide a "rotation" scalar parameter, similar to tgRod. This requires some implied assumptions about what is "width" vs. "height." That could be, for example, "at rotation=0, the width direction is always parallel to the X-Z axis, e.g. horizontal with respect to the world."
Other thoughts?