LDraw.org Discussion Forums

Full Version: JBrickBuilder connection model
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6
Hi Y'all,

@Roland, I think one of the things that makes connectivity tricky is that there is clearly some kind of overlapping core information that:
1. Almost certainly belongs in the part library to be generally useful and
2. Is used by a wide variety of different applications, not all of which need all of the data.

So use cases include:
- Aiding users in creating models (e.g. part snapping).
- Validating "physical possibility" of models (e.g. detecting illegal connections or a lack of connectivity that could cause the model to fall apart).
- Simulating real-world physical behavior (e.g. "what does the technic model do when I turn the steering wheel")
- Determining legal motion for animation (e.g. "I want to capture the fact that the doors open")
- Determining legal motion for modeling (e.g. "I want to rotate the entire radar dish up 45 degrees around the 1x2 hinge brick").

So...lots of different uses, not all of which need the same stuff.

I think Mario's looking heavily at creating models; I am looking equally at determining motion for editing (so that complicated irregular-angle modeling is easier) and at determining physical behavior as a precursor to animation (e.g. the program determines movable parts of the model and key framed poses from physics, not by hand editing).

I don't think gear support is necessary in an initial connectivity spec, but I'd like to understand how it would work to avoid having to throw out the entire design later.

@Philippe, interesting that SR3D uses a "rail around the gear teeth" model for technic bricks...re-reading my original criticisms of this technique, I must admit, the only real problem is that a worm gear has to be special cased...not -that- bad for something so complex. In a previous discussion of SR3D and connectivity, Sergio said something like "it is a work, and it is a working work" - that is, he picked a pragmatic approach that allowed him to actually code a working app. Perhaps "teeth rail connectors" are the most pragmatic solution.

@Mario, I agree, other than the worm gear, all other issues with using connectors around the rails are solvable. The connection logic is more complex, but not insurmountably so.

I've also been meaning to compare your connector types to some of the other connectivity models that have been proposed; I think what you have is a strict subset of all possible connectors with less than six degrees of freedom, but I haven't had time to dig into that yet. (My goal is to have a clear mapping from connection type to the degrees of freedom, so that it's clear how to build a physics-engine model directly from connectivity data.)

@Orion, agreed; for technic models this is desirable both for doing the modeling and for any simulation of behavior later.

Cheers
Ben
Ben Supnik Wrote:I think Mario's looking heavily at creating models; I am looking equally at determining motion for editing

This!

I was a bit confused, but now it's clear (for me): in my model I defined only if a part can connect to other parts, and how. So, my connection model doesn't helps at all (or very little) to define other physical properties, like gear, rotations, moving parts, levers.

But, as Ben pointed out, "connection" means a wide range of properties and data, so it can be useful, IMHO, to define group of properties based on purpose:
- connection (connectors, orientation, angles, ...)
- structural (collision volumes, stability, ...)
- physical (rotation axes, friction, hinges, ...)
- other

So, coders and developers can choose freely what data and what model they want.

My goal (in JBrickBuilder) is to help basic user to create models of low to middle complexity, like Digital Designer do, but avoiding that program interferes in building with excessive prohibitions and restrictions, leaving more control to user, as Philippe pointed out two message before this.

I know my connection model is simplified (excessively?), but I think it satisfy my program requisites.
I never thought to made a perfect model for all purposes, but I think it can be useful to other developers, so I made available for free model and data (... and the connection editor, when I find the time to give last coat of paint Big Grin )

Mario
Hi Mario,

I finally did some reading on Wikipedia re: different types of joints, e.g. connections that can undergo motion. I think I can map your spec to all "lower" connection types (e.g. the simple ones) and we can see which ones are missing (and whether they are needed).

First, the connections you have:
Point connection = ball & socket joint. 3 degrees of freedom, all rotational. Example: tow-ball connectors

Vector connection = revolute joint. 1 rotational degree of freedom. Example: wheel on a wheel holder.

Rail connection = cylindrical joint. 2 degrees of freedom (one rotational, one translational). The rotation axis and the translation axis must be the same. Example: a technic axle through a technic hole.

There are a few types of connectors that you do not have that I think are useful for LDraw:

Prismatic. This is like a rail connector that cannot rotate. 1 degree of translational freedom. Example: a technic axle through a technic axle hole. For prismatic joints, you need more information than just two points to specify the connections, because the complete orientation of the joint matters. For example, if your technic brick with axle hole is rotated, the axle must rotate too or the connection is "wrong".

I think that -even- if your app does not care about motion, having prismatic joints (with the complete orientation of the connector) matters to ensure that oriented prisms like axle + axle-hole are matched properly.

Rigid connection - this isn't a "joint" on wikipedia. 0 degrees of freedom, e.g. the two parts are connected in exactly one way. Like the prismatic connection, you need more orientation information than you can get from two points.

HELP: I'm having trouble thinking of a -true- rigid connection off-hand. My original idea was the old (early 80s) 2-prong 4.5 plug into the 2x2 light brick. But that's sort of a prismatic joint - you can slide the plug in and out gradually. Surely there must be something that 'just snaps'?

Screw Joint. After the discussion of the evil worm gear, I was fascinated to see that Wikipedia simply lists this as a 1-degree-of-freedom lower pair joint. I have -no- idea how we'd ever specify a screw joint in LDraw, but I was heartened to know that they, um, exist. :-)

Finally, there are a few joints that I think are not useful:

Planar Joints - three degrees of freedom with a plate always in contact. If anyone can think of a part that does this, please let me know; I came up short.

It also seemed possible to me to have a 2-degree-of-freedom "universal" joint that can transfer torque, but as a part, the u-joint is really 3 parts with two revolute joints, and this is probably how we'd want to model it, not with a single "magic" connection.

In terms of possible modifications to your spec, I think I would propose the addition of prismatic and rigid connectors, both with some way to specify complete orientation. This would allow you to snap parts that either slide without rotating or snap in only one way.

In terms of how you specify the orientation, besides simply adding a third point (3 points = 2 vectors at right angles = a coordinate system, using a cross-product to find the third axis), the other choice would be to always have connectors be aligned to the XYZ coordinate system (e.g. ALL rails point up the Y axis, for example) and use a matrix to orient the connector as needed.

The "win" of this, I think, is that we already use transform matrices to orient parts, and it's necessary to take into account the entire set of transforms when dealing with connectors anyway, so this would simply give you one more matrix to multiply in, rather than special casing for which way the connector is oriented. I suppose that given 3-point representations of a connector, you could internally convert it to a matrix at load time.

Anyway, the good news is that it appears that your definitions are orthogonal as joints (e.g. you're not doing the same thing with two connector families) and you've already covered almost all of the cases. :-)

If anyone can think of some crazy connection type or motion that I didn't list, please shout loudly! Of course, this doesn't touch belts, gears, or any of that crazy technic stuff. ;-)

Cheers
Ben
Ben Supnik Wrote:Rigid connection - this isn't a "joint" on wikipedia. 0 degrees of freedom, e.g. the two parts are connected in exactly one way. Like the prismatic connection, you need more orientation information than you can get from two points.

HELP: I'm having trouble thinking of a -true- rigid connection off-hand. My original idea was the old (early 80s) 2-prong 4.5 plug into the 2x2 light brick. But that's sort of a prismatic joint - you can slide the plug in and out gradually. Surely there must be something that 'just snaps'?

Windows (like this train windscreen part pair)?
Ciao Ben.

This thread quickly escalate to a really good ideas sources Big Grin

Ben Supnik Wrote:Prismatic. This is like a rail connector that cannot rotate. 1 degree of translational freedom. Example: a technic axle through a technic axle hole. For prismatic joints, you need more information than just two points to specify the connections, because the complete orientation of the joint matters. For example, if your technic brick with axle hole is rotated, the axle must rotate too or the connection is "wrong".
...
...
Rigid connection - this isn't a "joint" on wikipedia. 0 degrees of freedom, e.g. the two parts are connected in exactly one way. Like the prismatic connection, you need more orientation information than you can get from two points.

I think it is really easy to add these two new type of connection. There's more: thinking to general LEGO parts, there are parts that have prismatic connections but with irregular angles? Let me explain: technic axle is a square base prism, with four positions, all are 90 degree multiple. An 8-teeth gear have exactly 8 positions and so on (a 24-teeth gear, 24, ....) and all positions are multiples of a given angle.

So... think a connection that have two more data:
- 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.
- 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.

But, if you see, rigid connection is a prismatic connection with only one "side", so we need only one new connection type.

There is only an assumption: that prismatic connections are all based on regular polygonal base prism, or that positions in one connection are all multiple of same angle.

Now, we have a bonus if we can derive gear connection from prismatic:
- first vector is gear rotation axis
- second vector defines "0" position and gear pitch diameter (see http://en.wikipedia.org/wiki/Gear#General_nomenclature) or the distance of connection for other gear
- integer defines number of teeth (or prismatic connection "faces"/positions)

To connect two gear:
axes (vector 1) aligned (abs(dot product)==1) AND
distance between axes == pitch_diameter1+pitch_diameter2
next, rotate gear2 to match teeth of gear1:
- 8 teeth with 8 teeth: rotate second to 1/2 of 360/8 degree relative to orientation of first gear
- 8 teeth to 24 teeth: rotate second of 1/2 of 360/24 degree or rotate first of 1/2 of 360/8
and so on...

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.

What do you think? It can be starting point?

Mario
Travis Cobbs Wrote:Windows (like this train windscreen part pair)?

Thanks Travis! I blame "daddy brain" for not being able to come up with even one snapping window example myself. :-)

This is an interesting example because it illustrates a principle of a connection system: it may be advantageous to specify the "ultimate" behavior of two parts completely rather than describe their component parts.

In other words, a window might snap in via multiple joints, all of which have some freedom, but when they are -all- snapped, the effective connection is rigid.

I think it is hugely advantageous to simply specify this kind of case as a rigid connection.

- For programs like Mario's that don't aim to do physics simulation, deriving "rigid" from lots of joints is non-trivial.
- For features like Bricksmiths' "insert related" (similar to what Mario does in that it's an aid in "correct" building) having a single joint that fully specifies the connection makes part placement a lot easier.
- Even when we have a physics engine, they tend to jitter and have floating point heebie-jeebies when collisions are involved; the quality of alignment will be better with a pre-specified rigid body.

Cheers
Ben
Hi Mario,

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
Ben Supnik Wrote:(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. :-)
imho this is mandatory if your goal is to make it part of the LDraw standard.

Ben Supnik Wrote:I can't think of any off hand but then I also couldn't name a single rigid connection.
How about the NXT connectors?


Ben Supnik Wrote: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.
This is basiclly why I choose the shape description method I'm mainly using with LDCad. As LEGO is mainly just holes and pegs describing those will automaticlly result in n on n connection / snapping without having to define every possible combination first.

For example you don't have to put 'female technicpin' info on every tehnic beam hole besides female axle hole info, and (optionally) female stud hole info. You just describe the shape of the hole once and anything with a (partial) similar shape will fit / snap to it.


ps shouldn't we move this discussion to http://forums.ldraw.org/list.php?32 if we are serious about setting up an official connection model?
Roland Melkert Wrote:
Ben Supnik Wrote:(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. :-)
imho this is mandatory if your goal is to make it part of the LDraw standard.

I'm afraid I don't follow. Are you saying that we:
- Must make the spec part of the standard to have the METAs in the dat file or
- We must make the spec use data in the .dat file (METAs) to get the data into the library or
- We must use an external table of data to get the data into the library.

Quote:ps shouldn't we move this discussion to http://forums.ldraw.org/list.php?32 if we are serious about setting up an official connection model?

Possibly! I think the discussion started as Mario describing his work-to-date (and excellent documentation of such work :-) and then I sort of hijacked it in the hope of putting together a "general purpose" connection system that could be used by multiple programs.

cheers
Ben
Hi Mario,

I think I just found an example of a 2-degree of freedom ball-joint (as opposed to the three-degree-of-freedom "simple" ball joint):

Part 32494 (Technic Wheel Spindle Driver) and part 92906 (Technic steering constant velocity joint female).

These two parts directly form a u-joint; the pins in the ball keep the ball and socket from "rolling" independently.

I'll have to think more about this, but I think this requires three points to have a complete coordinate system, but is still a 'point' connection.

Cheers
Ben
Pages: 1 2 3 4 5 6