Hi Mario,
Agreed - whatever the method (3 points, 2 vectors, 3 vectors, transform matrix) some connection types clearly need "complete orientation".
For applications that want to do animation, I think we might need a distinction between:
- rotational symmetry: the technic axle can go into the technic hole at any of four rotations around its axis, but once it's there it is rigid - it can't rotate to the next 90 degree legal position without pulling the axle out or breaking your bricks)
- "snapping" hinge: a locking hinge strongly prefers to stay at a 22.5 degree-interval rotational grid, but you can put force on it and snap it to the next rotational point. Thus it is good for moving parts that are going to have to fight gravity or not flop around.
For apps that simply do part placement and editing, these distinctions don't matter, but for an app that wants to animate, rotating the technic axle by 90 degrees is legal for editing but not for animating.
So naively I would suggest that revolute joints/vector connections might need both a rotational grid specification and a symmetry specification.
Right - by this logic, we really only need cylindrical joints - a prismatic joint has a rotation of 0, and a revolute joint has a maximum travel of 0; a rigid joint has both set to 0. In other words, if we have a degree of freedom but the degree of freedom has a total "range" of 0, it's not a degree of freedom at all. :-)
By this logic the vector connection is a special case of a rail connection. (Albeit, it is a special case that is necessary due to the particular representation you have picked for your format - as long as the -range- of a prismatic connection is specified in the same way as the -axis-, then you can't have a prismatic range of 0 without losing your axis.)
I don't have a strong opinion yet about whether it's better to have more connection families, with their data custom tailored to the joint type, or whether it's better to have a smaller number of more general (but complex) connection types. I think it's clear that an application can translate between them as needed (e.g. identify "locked" cylindrical joints and change them to be rigid, or simply upgrade all rigid joints to cylindrical joints with zero degrees of rotation or travel).
So I guess it's a question of who the target audience is for the data specification. One appeal of your "three point" specification scheme, is that an author could place the three control points at logical points on the part, which might make it easier for part authors to annotate connections on a part.
The only part authoring I ever did was changing the color of some baseplates, so I'm just speculating..perhaps actual part authors should chime in. :-) But to the extent that .ldr and .dat files tend to be -the- canonical form of the data, we might need a data format that lends itself to editing tools.
(I realize that your spec is based on a side-table of connectivity, but my hope is that someday we end up with the data directly in the part files for ubiquitous use. :-)
I can't think of any off hand but then I also couldn't name a single rigid connection. I'll have to think about it. I think you're right though, that such an "irregular" connection could be modeled out of multiple connection types, only one of which will "match up." But this is also tricky for apps that want to determine if a connection is "legal" - at any given time one of the two connections will be illegal since it's off by N degrees. :-( Perhaps we need a good real part example to consider our options...
cheers
Ben
Mario Pascucci Wrote:- a third optional point, that defines a vector going from first (base) point to third point, that must be orthogonal to first vector. Second vector defines an orientation for connection relative to first vector axis, defining a rigid connection where base points of two parts must be coincident and the two orientation vectors must be aligned (lying on same line). Et-voilà, rigid connection.
Agreed - whatever the method (3 points, 2 vectors, 3 vectors, transform matrix) some connection types clearly need "complete orientation".
Quote:- an integer number that defines the number of "faces" that have the prismatic connection. If number is 1, or omitted, it is a rigid connection. Starting from 2 it defines available positions for connection: 2=180 degree (up or down, left or right), 3=120 degree, 4=90 degree (axle and axlehole), 8=45 degree (an 8-teeth gear). Positions are relative to the second vector orientation, so second vector define initial position of rotation on first vector axis. Ladies and Gentlemen, prismatic connection.
For applications that want to do animation, I think we might need a distinction between:
- rotational symmetry: the technic axle can go into the technic hole at any of four rotations around its axis, but once it's there it is rigid - it can't rotate to the next 90 degree legal position without pulling the axle out or breaking your bricks)
- "snapping" hinge: a locking hinge strongly prefers to stay at a 22.5 degree-interval rotational grid, but you can put force on it and snap it to the next rotational point. Thus it is good for moving parts that are going to have to fight gravity or not flop around.
For apps that simply do part placement and editing, these distinctions don't matter, but for an app that wants to animate, rotating the technic axle by 90 degrees is legal for editing but not for animating.
So naively I would suggest that revolute joints/vector connections might need both a rotational grid specification and a symmetry specification.
Quote:But, if you see, rigid connection is a prismatic connection with only one "side", so we need only one new connection type.
Right - by this logic, we really only need cylindrical joints - a prismatic joint has a rotation of 0, and a revolute joint has a maximum travel of 0; a rigid joint has both set to 0. In other words, if we have a degree of freedom but the degree of freedom has a total "range" of 0, it's not a degree of freedom at all. :-)
By this logic the vector connection is a special case of a rail connection. (Albeit, it is a special case that is necessary due to the particular representation you have picked for your format - as long as the -range- of a prismatic connection is specified in the same way as the -axis-, then you can't have a prismatic range of 0 without losing your axis.)
I don't have a strong opinion yet about whether it's better to have more connection families, with their data custom tailored to the joint type, or whether it's better to have a smaller number of more general (but complex) connection types. I think it's clear that an application can translate between them as needed (e.g. identify "locked" cylindrical joints and change them to be rigid, or simply upgrade all rigid joints to cylindrical joints with zero degrees of rotation or travel).
So I guess it's a question of who the target audience is for the data specification. One appeal of your "three point" specification scheme, is that an author could place the three control points at logical points on the part, which might make it easier for part authors to annotate connections on a part.
The only part authoring I ever did was changing the color of some baseplates, so I'm just speculating..perhaps actual part authors should chime in. :-) But to the extent that .ldr and .dat files tend to be -the- canonical form of the data, we might need a data format that lends itself to editing tools.
(I realize that your spec is based on a side-table of connectivity, but my hope is that someday we end up with the data directly in the part files for ubiquitous use. :-)
Quote:Now: there are connection that are prismatic but irregular? I.e. two position, one at 30 degree and one at 90 degree. If a such connection exists, we need a lot more complex model. But a such connection can be reduced to TWO rigid connection with same center point.
I can't think of any off hand but then I also couldn't name a single rigid connection. I'll have to think about it. I think you're right though, that such an "irregular" connection could be modeled out of multiple connection types, only one of which will "match up." But this is also tricky for apps that want to determine if a connection is "legal" - at any given time one of the two connections will be illegal since it's off by N degrees. :-( Perhaps we need a good real part example to consider our options...
cheers
Ben