#1140 Hinge/Rail parts do not account for objects rotational transformation

[Stephen]

As I understand the mechanism the largest axis of the bounding box of a specifically named part (g) is used to determine the axis of the rotation or translation for the opening_on parts.

The hinging and rails are broken for any object where the hinge/rail component is rotated away from one of the world axis'. It seems the objects rotational transformation is not taken into account when moving the opening_on parts. Sometimes you're lucky and the hinge/rail lines up with a world axis in your model. If not, you get weird movements. I can see this even without doing an import/export: Add the "Slider window" to a 45 degree wall. Now try and move the panel. It will snap to one of the world axis and move in/out of the frame, instead of sliding relative to the frame. Applying the objects transform to the translation might fix this simple case.

I suspect this is even more complicated in the case of a roof object created using walls, then exported and reimported. Here the object may not have a transform, so the rail or hinge may be misaligned, and the object will not give a useful transform.

Rather than using this largest axis of the bounding box method, could we not simply us two vertex to define the hinge/rail axis? This would be far more flexible.

[Emmanuel Puybaret]

The axis direction is defined from the location and dimensions of the hinges or rails, and simplified to X, Y or Z axis depending on the largest dimension in these directions.
Being able to use any axis direction would make it more difficult to guess the axis. Tell be how to compute the axis direction along the larger dimension of any 3D shape, and I may try to implement this.
Anyway, it's not a bug but an improvement, the reason why I move this ticket to feature requests.

[Emmanuel Puybaret]

Ticket moved from /p/sweethome3d/bugs/1150/

[Stephen]

First time I read this, I think I didn't understand. My idea was to not use part of the visual objects structure to define the hinge. Instead have a separate group (as in obj group) that only consists of two 3D points - also with a special name following the existing scheme. These two points define the axis of rotation for the other sub-parts. The points/axis is rotated by the furniture's main rotation, and then are applied to the hinged sub-parts. My 3D geometry is somewhat basic, and maybe I don't understand the reason for making the hinge an actual 3D component of the furniture object. Or maybe there is some other problem I'm not seeing. The existing heuristic just seems a bit fragile when it is so easy to confuse.

[Stephen]

OK, so I can export a .obj file from blender containing (the "g" naming is irrelevant as this was just a test):

... (snipped cube) ...
g Axis_Plane
v -1.036215 -0.870979 0.409455
v 1.036215 0.870979 -0.409455

I can import this into SH3D without error, but it looks like SH3D is cleaning the geometry, and removes them. But anyway, that is how I would suggest determining the axis - it would just need SH3D to use them instead of nuking them.

I searched "how to rotate in 3d around an arbitrary axis" and found some pages, but then there was this sudden roaring noise as the information whooshed right over my head. The gist of it seems to be a big ugly 3x3 matrix, and a bunch of math that looks somewhat similar to my experiments with 2D rotation matrices.

[Stephen]

Another thought is to have an actual g group with only a single face (using an invisible material/texture) with only three vertices. Find the longest distance between the three, and that becomes the arbitrary axis for rotation, or vector for translation if it is a rail.
This face does not get "cleaned" by SH3D, and would prevent needing changes elsewhere handling stray vertices.

[Emmanuel Puybaret]

Thanks for proposing solutions :)