JBrickBuilder connection model

[Mario Pascucci]

Hi all.

After a (really good) ideas exchange with Ben Supnik (thanks Ben!), I partially redesign my program connection model and strategy.

I think it can be useful to other programmers/coders that works with LDraw library, so I wrote a brief manual that explain how model works.

Now, adding a connection type and an autodetect strategy using LDraw primitives don't requires to change program code, but only a configuration file.

Manual is here (PDF, english).
Here you can download the latest connection database (as a zip file).

To edit connection I built a sketchy editor, really basic:
- connection editor as a "portable" package
- connection editor source code

Feel free to comment/use this work.
I released free to LDraw community.

Mario

[Roland Melkert]

Very interesting, this setup is very similar to some of the info I use with LDCad part snapping.

The biggest difference being I'm using (cylindrical) shape description as much as possible but for the more weird things (glass, nxt connector, etc) I too fall back on group based male/female matching.

And instead of XML i use LDraw meta's in a second library tree so you can edit/add info on a loose per .dat basis.

I'm curious I choose the shape description method in order to deal with parts like 32209.dat (axle with non axle section in the middle), it's definition in LDCad is like so:

Code:

0 !LDCAD SNAP_CLEAR
0 !LDCAD SNAP_CYL [gender=M] [caps=none] [secs=A 6 18  R 8 2  R 6 8  A 6 80] [center=true] [pos=-1 0 0] [ori=0 -1 0 1 0 0 0 0 1] [slide=true]

How would JBrickBuilder define such a part?

[Jakub Trznadel]

This seems to be very interesting, as it shall allow also detection which parts can move, and which are rigid.

Just thinking about gears... is there a way to express the way their interact with each other using your model?
(yes I know, it's more complicated...)

Thanks,
Jakub

[Mario Pascucci]

Hi Roland.

Part 32209.dat requires a manual definition of connection points, because autodetect fails: it is an axle defined with axleholes primitives

So, to use my connection model, I defined two connection points:
- an axle from left end to stop ring
- an axle from right end up to end of axle groove near stop ring.

The behavior depends from "receiving" part. If you use a brick with an axlehole, axlehole "deepness" (or brick thickness) is greater than "gap" in stop ring, so part 32209 act as it was a normal 5.5L axle. Program don't checks collision between parts.

Moreover, to made connection for some parts a bit more easy, I added a sort of "near attraction" in rail type connections, so if you put an axle into an axlehole it "snaps" to hole axis when you put axle "in front" at the hole, at about 10 LDU. This feature make useless the "gap" in 32209.dat connection definition for JBrickBuilder.

I try to balance "correctness" of connection points with excessive point definitions. I.e., for part 2540.dat (plate 1x2 with handle) I defined a single bar (rail type) connection straight for whole bar length, so it is a single connection point, instead of three.

It is up to user to check "visually" that parts does not "collides" or overlapping.

Mario

[Mario Pascucci]

Hi Jakub.

If you mean "interaction" as "if a gear rotate, then linked gear also rotate", no.

But you can use a group of connections around gear's teeth to "snap" a gear with another in right position. Let me explain with an image. In red you see "slot" connections, in blue "tooth" connections, defined as connection coupling: a tooth can only connect along a slot.

Now the problems are
- you will have a connection point for every tooth and for every slot
- none of the three connection family I defined is suitable to "snap" gears in right position in every condition.

But, there isn't any problem to use same schema to define a new "interaction model".
You can define some property (like "degree of freedom" or "motion propagation") and points, vectors, hinge centers to place in "parts space". After that you can develop a model to simulate motions and rotations.

Mario

[Ben Supnik]

Hi Y'all,

@Mario, thank you for posting the updated spec!! I think your model is pretty close to the design I've been working on for Bricksmith. My design is similar to yours (and dissimilar to Roland's) in that all matching is done by male/female pairs whose data-defined type codes define them as matches; I'm not looking to do geometry fit.

@Jakub, I am curious about this too; I'd feel more secure in my proposed data model knowing that a logical extension for gears wasn't going to invalidate the universe. But I only have two ideas and they are both "not very good".

1. Model every gear tooth as being "solid" the way we would to stop bricks from colliding and let a physics package try to combine the force from the gear teeth with the constraints of pins to put gears in motion. I don't like this because it's asking a lot from the physics package and gives us no guidance for properly placing or designing gears.

2. Define a new connection type that is sort of like a "radial rail" that wraps around the tooth-bearing surface that is the gear. Thus two gears connect if their radial rails are tangent at some point; similarly a rack can be a rail that mates with the radial rail. This has all sorts of fun issues:

- It can't handle worm gears at all. :-(
- It's not even remotely obvious how male/female connections are made - unlike all other connection types, this one is really "any gear with any gear".
- Not all gears have the same connection class.

But at least we'd have the meta-data to say "if these two gears are at this distance, they mesh up (and their relative rotations must be X to avoid tooth collisions - snapping or a grid can be applied to the tooth surface connectors.

In theory this expands to belts too if they are tensioned...please, no one model a 10-speed bicycle. :-)

@Mario, no offense, but I consider "a snapping connector at every tooth and tooth gap" to also be in this category of close-but-problematic solutions. :-( Under normal operation you'd have some teeth "very close" but not snapped in a rack-and-pinion assembly, for example, and it would be not much more useful than just having solid collidable-surfaces in terms of physics analysis.

Anyway, if anyone has some idea that's much more clever, I'd love to hear it.

Cheers
Ben

[Philippe Hurbain]

Method 2 is more or less how SR3D builder meshes gears (diameter + number of teeth). Crude but effective. Yes, it does have drawbacks (eg. non beveled gears mesh at right angle) but after all the user is not stupid! I prefer something that allows forbidden combinations than the inverse (who has never been deeply frustrated with LDD throws the first stone

[Mario Pascucci]

no offense, but I consider ...

I think we doing some brainstorming, do you?
Anyway, it was a really dumb idea, I agree

Your idea of a "radial rail" can be a good starting point.

- male/female problem: this can be resolved considering gear as an "opposite" of itself. Let me explain: in my model it is mandatory that connection goes in pairs, but we can add a "degenerated" connection that has itself as opposite. It will work because when you place a new part with this connection type program will search for a connection on already placed parts, excluding new part itself.
So IMHO this can be solved easily: in connection type definition file you can place a "connection pair" with only one type.
- to define connection, you can use the two points of my model as following:
* simple gears (connect only if gears are coplanar): a vector with base in center of gear and head along rotation axis. Distance between base and head (vector module) is radius of "radial rail". Gear connects if are coplanar AND distance between base points (center of gears) are equals to sum of radius.
* differential/conical/beveled gears (connects if are coplanar and if axes are in a defined angle interval): same as simple gears, but connects if "radial rails" (circles) are tangent AND axes are coplanar AND distances from intersection point between axes and both gear centers is not less than radius of smaller gear (a bit complicated, i know).
* rack and pinion: this can be a male/female connection, where rack is a line and pinion is a radial rail. It connects when a rack is tangent to a pinion radial rail AND coplanar to pinion AND tangent point is "inside" rack segment.
* worm gear... I surrender maybe we can consider a "cylindrical rail", where male is worm gear and female is a radial rail. It connects when radial rail is tangent to worm gear cylinder rail AND axes are at 90 degree. To connect rack and worm gear we can define a couple "cylindrical rail" and "linear rail" that connects only when linear rail is parallel to worm gear axis AND at cylinder radius distance. But we need more than two points to define such "cylindrical rail" and transmission ratio.

Transmission ratio is given from ratio between "radial rail" radiuses, more or less...

Ideas, just to say

I prefer something that allows forbidden combinations than the inverse

I agree 1000000 percent

[Roland Melkert]

imho gears should snap to their companion axis only, not teeth positions. Unless you are automatically rotating / adjusting the whole assembly as a result.

So if you add a gear to some axis it 'magically' snaps to that axis but also rotates it and everything connected to force a correct tooth position. Other wise it would be pretty useless to have tooth snapping I think.

It might be more helpful to the user to only include the tooth count in the gear info, as it can be used to rotate at a 1/2 gear stepping.

Or I'm I misunderstanding your intentions here?

[Orion Pobursky]

So if you add a gear to some axis it 'magically' snaps to that axis but also rotates it and everything connected to force a correct tooth position

This is what I want as a user who has made quite a few Technic models: Automatic adjustment of the gearing. This way I can rotate the input and have, for instance, the wheels of the car turn in the correct direction with the whole gear train being adjusted. This would also allow for significantly easier animation of Technic models

[Ben Supnik]

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

[Mario Pascucci]

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 )

Mario

[Ben Supnik]

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

[Travis Cobbs]

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)?

[Mario Pascucci]

Ciao Ben.

This thread quickly escalate to a really good ideas sources

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

[Ben Supnik]

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

[Ben Supnik]

Hi Mario,

- 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".

- 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.

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. :-)

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

[Roland Melkert]

(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 can't think of any off hand but then I also couldn't name a single rigid connection.

How about the NXT connectors?

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?

[Ben Supnik]

(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.

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

[Ben Supnik]

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

[Roland Melkert]

I'm afraid I don't follow. Are you saying that we:.....

I meant any connection info format which hopes to become part of the LDraw spec should be formatted into meta lines on a per .dat basis. (imho)

Nothing wrong with Mario's storage method but you indicated you would love to see this become a standard.

[Mario Pascucci]

Ciao Roland and Ben.

I 'm wonder if embedding connection information in .dat is the best strategy.

As I say in other message, there are at least three class of information related to connections:
- snapping/joint information (connection points, orientation, ...)
- geometric/structural (bounding boxes, collision volumes, degree of freedom, ...)
- physical and mechanical (weight, frictions, rigidity, center of mass, ...)

My model cover only first class and, with some assumptions, can help to define degree of freedom. Trying to extend it to cover mechanical and physical property is anything but trivial (... and far, far beyond my programming/math/physics skills ).
Some examples:
- a "click-hinge": it is relatively easy to define a connection that accepts only multiples of 22.5 degree (it is a prismatic connection), but to limit angle excursion (normally 180 degree, but without any other part interferes in rotation), define the weight that a hinge can support before slide down, requires lot more data and math.
- a gearbox, or a group of gears: my model can help on how to connect gears and align teeth, but to define how rotation, speed and torque is transferred require lot more information. And... what if you place three gears in triangle?

Adding all these information to a .dat can easily result in a file size explosion. Take a plain 2x4 brick: it has 19 connection points (8 studs, 11 underside stud receiver, counting three tube center), that requires (with my present connection model) 38 coordinates as x,y,z floats, 19 "type" definitions: if "type" can be represented as a single integer, we have a total of 114 floats and 19 integers.

If someone isn't interested in connectivity, including it in .dat lead to more complexity in parsing and greater library size.
If you include other mechanical and physical data, it could be worse, it could be rain!

Not counting a lot of work needed to maintain library as a whole. Keep data in different places can helps to distribute the work and effort needed. File format can be same of .dat. I chose XML for my personal preferences and the universality of use in Java classes and libraries, but I can do a converter to transform in any other choice format.

Mario

[Ben Supnik]

Hi Mario,

I would say that information that is specific to -one- part should be in the part's file. We have the cost of a larger part file and information some people may not care about, but we have the benefit that an author looking at the part file will see the entire part file. There is no risk of an edit to the graphical shape of the part getting out of sync with connectivity.

We also need information about sets of parts, and I am not sure that that belongs in part files. For example, defining types of connections from families, or defining relationships between families might better be in a separate file.

Adding all these information to a .dat can easily result in a file size explosion. Take a plain 2x4 brick: it has 19 connection points (8 studs, 11 underside stud receiver, counting three tube center), that requires (with my present connection model) 38 coordinates as x,y,z floats, 19 "type" definitions: if "type" can be represented as a single integer, we have a total of 114 floats and 19 integers.

This is true -if- we "expand" all connectivity into the part. But the 2x4 brick already has 8 studs, each of which has 16 triangles, 16 quads, 16 optional lines, and 16 real lines...that's 528 floats not counting the extra goo for optional lines!

LDraw gets around this by describing the 2x4 brick as a series of primitives that factor common shapes. We can leverage this by putting a stud connector onto the stud primitive directly (once) and thus it is copied by file inclusion.

In fact, I would argue that a strong reason to have the "spatial" aspect of connections on the parts themselves is so that they can be placed on a primitive and the natural structuring of the library helps spread connectivity to a lot of parts without a lot of hand editing.

If someone isn't interested in connectivity, including it in .dat lead to more complexity in parsing and greater library size.
If you include other mechanical and physical data, it could be worse, it could be rain!

There is a question of how much physics data ends up in the library, and whose model it follows. But without a clear model for how interactions are described, I think it's too soon to worry about that; there are still some fairly tricky open issues.

For example, consider the 1x2 hinge brick and its mail/female hinge connectors. The male half of these hinges are also used in a series of plates that can be jammed into the 1x2 brick base. But the range of legal motion is a function of which -pair- of parts was used. Where does this data go, and how is it described?

Not counting a lot of work needed to maintain library as a whole. Keep data in different places can helps to distribute the work and effort needed. File format can be same of .dat. I chose XML for my personal preferences and the universality of use in Java classes and libraries, but I can do a converter to transform in any other choice format.

Right - you have gone the route that SR3D (and probably other) apps have gone, and as long as connectivity is not a public standard, it's really the only sane way to start connectivity; a side table so that you can get work done without having to hack up your library. And for an initial app where you need to make a lot of edits or describe a lot of connectivity, one big file is a win.

I think in the short term even for a public standard we need some side file format for data that will -someday- be in the .dat files so we can develop prototype software.

In the long term, however, I think that -if- the Ldraw community accepts connectivity as a native part of the format, then we really need the connectivity data to be visible to all part authors.

And if the community accepts connectivity in the library, it also sends a message to app authors that "yes, connectivity is here for you to use" and encourages app developers to leverage the data instead of rolling their own.

Cheers
Ben

[Chris Dee]

This is a tricky issue.

I think the main question to ask to decide whether supplementary information (e.g. connectivity metadata) is stored within the part file is 'How often would a correction to the part geometry affect the connectivity metadata?'. If 'hardly ever', then I favour a separate file structure for connectivity info.

That way connectivity information does not have to be repeated in patterned versions of parts with identical geometry.

I know that there has been a lot of talk about the inefficiency of a 'one file = one part' structure of LDraw but from a library management perspective this still works best. That's not to say that the conectivity library (or indeed the parts library) couldn't be distributed as a consolidated, optimised file, effectively a complied version of the library. So long as the tools understand how to deal with that.

[Roland Melkert]

That way connectivity information does not have to be repeated in patterned versions of parts with identical geometry.

In such a case the snap info should be added to the e.g. 'without front face' subpart.

I know that there has been a lot of talk about the inefficiency of a 'one file = one part' structure of LDraw but from a library management perspective this still works best.

I think it's the power of LDraw, just look at how fast Philio sometimes prepares some unofficial part after a request. That wouldn't be possible if you had to repack the whole library every time. Also the per dat solution gives authors the chance to add info from the get go which probably results in less errors as they know the shape etc in and out.

The loose files also still gives us the option to generate a higher HQ library (basically a cache file) as we discussed a while back. So we could also add the connection info to that package but personally I would prefer it in the .dat's as diskspace isn't a real issue these days and it's also easy enough to use the library from it's zip without unpacking it if needed.

[Ben Supnik]

Hi Chris,

First, I second everything Roalnd said. :-)

Second, since we don't actually have a clear definition of what the connectivity data contains, this discussion may be premature.

With that in mind:

I think the main question to ask to decide whether supplementary information (e.g. connectivity metadata) is stored within the part file is 'How often would a correction to the part geometry affect the connectivity metadata?'. If 'hardly ever', then I favour a separate file structure for connectivity info.

That seems like a slightly higher bar than other aspects of the library. For example, we don't put meta data on a part in a separate file because changing the part geometry is unlikely to change the part name or category.

My argument is that the connectivity is a -kind of- part geometry. In this case I'm definitely only arguing for including -connection location data- in the parts, and I'm not entirely sure what other kinds of data we will even ahve.

I know that there has been a lot of talk about the inefficiency of a 'one file = one part' structure of LDraw but from a library management perspective this still works best.

I think this is a strong argument -in favor- of connectivity in the part. If connectivity was in a single consolidated file, how would we manage multiple authors editing connectivity data on separate parts. That's not an impossible problem (in fact, it's just source control) but we already have -existing- infrastructure based on one part one file that works well.

cheers
Ben

[Mario Pascucci]

Ciao Ben.

Probably I'm excessively worried at this phase, when we are still talking of how to start

Mario

[Chris Dee]

When I wrote 'a separate file structure' I wasn't advocating a single consolidated file, rather a parallel file structure containing the connection info in a separate 'one file one part' hierarchy.

However, I do prefer putting the connectivity metadata in the existing part file, so long as that is expected to percolate up from the primitives and subparts (which I hadn't grapsed from the previous discussion). I would like to see a meta-statement in the header section to indicate that connectivity is included (in a similar way that BFC CERTIFY implies winding info is included).

[Ben Supnik]

However, I do prefer putting the connectivity metadata in the existing part file, so long as that is expected to percolate up from the primitives and subparts (which I hadn't grapsed from the previous discussion).

That's exactly what I had in mind. I think there are two ways this can go:

1. Annotation of existing primitives with connectivity, e.g. if you use stud.dat, you get a male stud connector 'for free'.
2. Building new specific primitives designed to create "connection combinations" that are common.

As an example of the second, under Mario's scheme, a technic connector hole that is standard to the 1xN beams has a pile of connection information for:
- Jamming studs into either end or
- Putting pins through the hole with rotation or
- Putting axles through the hole with rotation or
- Putting friction pins through the hole as a rigid (but not directionally limited) connection.

There are other ways to model connections that would recycle some of this data, but in the end we're almost guaranteed to need more than one connector annotation. (As an example of why, consider that the technic axle brick can take only an axle, while the regular technic brick can take an axle or studs in the ends.)

So someone could make a primitive that wraps up all of that "technic hole" info into one .dat file - sort of a molecule out of atoms.

The two techniques aren't incompatible.

I would like to see a meta-statement in the header section to indicate that connectivity is included (in a similar way that BFC CERTIFY implies winding info is included).

That seems pretty sane...my plan for this was:

1. Keep poking at Mario's spec until the open issues for the "design" of connectivity are sorted out.
2. Go code an actual working prototype and see how it works. I think this is pretty important for "proving" the data design in practice.
3. Come back and create a more detailed spec proposal that can then get ironed out for issues like how files are meta tagged in the library, compatibility, syntax, etc.
4. Further revise my own code to match the final spec.

(I am very willing to rewrite my own code if the spec needs to get modded. I don't know what happened with the texture extensions, but comments on the forums imply that it was delivered to the LSC "take it or leave it". I don't think that's particularly fair to the community, and it doesn't help get the best ideas into practice.)

Mind you this is a bit of a hijack or Mario's work! But it's sort of luck that he posted something that was complete and readable right as I was starting to dig into this again....

chers
Ben

[Ben Supnik]

Hi Mario,

This may not help your worrying much:

http://forums.ldraw.org/showthread.php?tid=15486

I wanted to separate out the discussion of travel limits - one possible answer is "for my program, I do not care!" - if you do not need such data then the problem you have at hand is quite a bit simpler. :-)

cheers
Ben

[Roland Melkert]

1. Annotation of existing primitives with connectivity, e.g. if you use stud.dat, you get a male stud connector 'for free'.

This is nothing new, both SR3DBuidler as my own LDCad use this approach.

2. Building new specific primitives designed to create "connection combinations" that are common.

I think it's already in the making as the discussion of an anti stud primitive came by awhile back.

As an example of the second, under Mario's scheme, a technic connector hole that is standard to the 1xN beams has a pile of connection information for:
- Jamming studs into either end or
- Putting pins through the hole with rotation or
- Putting axles through the hole with rotation or
- Putting friction pins through the hole as a rigid (but not directionally limited) connection.

I still think describing shapes is the better approach for these kinds of things

So someone could make a primitive that wraps up all of that "technic hole" info into one .dat file - sort of a molecule out of atoms.

There's connhole.dat, that's the one I use in LDCad, but that file doesn't cover all technic hole occurrences e.g. the last hole in beams etc.

I would like to see a meta-statement in the header section to indicate that connectivity is included (in a similar way that BFC CERTIFY implies winding info is included).

I agree, even if there is no additional info in the file given such an indication would be usefull as it shows it has none. This could be thre result of all the info being inherited (e.g. new minifig torsos).

(I am very willing to rewrite my own code if the spec needs to get modded. I don't know what happened with the texture extensions, but comments on the forums imply that it was delivered to the LSC "take it or leave it". I don't think that's particularly fair to the community, and it doesn't help get the best ideas into practice.)

I'm not to happy with how iit went with the texture spec as it basically was take it as a whole or leave it. I'm also a bit disappointed in the fact it's still not really used.

Mind you this is a bit of a hijack or Mario's work! But it's sort of luck that he posted something that was complete and readable right as I was starting to dig into this again....

No offense to Mario, but his method is nothing new. If anyone should be credited for setting up the basics of connection handling it should be Sergio.

We started talking about official connection models before on the forum, but for some reason it went nowhere every time. The main reason for that (i think) was people where afraid it would not be adopted by the tools. Even Sergio indicated he would never use it even if it became official. Something I did not really understand at the time. But now I also have my own format i kinda do, you own system just leaves more room to operate. On the other hand it would be very useful to use the default official info as the fallback or basis for snapping at least.

Anyhow I just wanted to get the above of my chest as it was kinda eating at me.

[Ben Supnik]

1. Annotation of existing primitives with connectivity, e.g. if you use stud.dat, you get a male stud connector 'for free'.

This is nothing new, both SR3DBuidler as my own LDCad use this approach.

Good! I would love to see a connectivity spec built entirely out of already-proven ideas!

I still think describing shapes is the better approach for these kinds of things

Should we have a serious discussion of this?

Mind you this is a bit of a hijack or Mario's work! But it's sort of luck that he posted something that was complete and readable right as I was starting to dig into this again....

No offense to Mario, but his method is nothing new. If anyone should be credited for setting up the basics of connection handling it should be Sergio.

I'm not trying to claim that Mario was the first to design a connection model of this type. I am saying that I am hijacking his work in that he designed something, wrote a spec, posted it for feedback, and then I came along and started discussing it (1) in a bigger scope (e.g. for all of LDraw and not just his app) and (2) with additional functionality (supporting at least some physical operations and not just snapping).

We started talking about official connection models before on the forum, but for some reason it went nowhere every time. The main reason for that (i think) was people where afraid it would not be adopted by the tools. Even Sergio indicated he would never use it even if it became official. Something I did not really understand at the time. But now I also have my own format i kinda do, you own system just leaves more room to operate. On the other hand it would be very useful to use the default official info as the fallback or basis for snapping at least.

I think you are referring to the previous discussion where I was looking to build "related parts" (something we shipped in Bricksmith) and was shopping it around to see if anyone else was interested. At the time I wasn't pushing for connectivity because I didn't have time to get it done in Bricksmith - related parts is a much smaller, simpler feature (simpler than snapping by a lot).

Sergio was very generous in offering some kind of extract of SR3D connectivity data as a way to "seed" community data; his not wanting to redo his work was pretty understandable too!

At this point we are rapidly approaching at least four implementations of this feature (Sergios, yours, Henri's and Mario's). I always have the option to do a fifth with Bricksmith.

My thinking is that if I have to do the design work no matter what, if I can have the discussion with the community and incorporate other people's work, then it will be more likely that the end result will be something useful to multiple programs and not just Bricksmith-specific.

Cheers
Ben

[Willy Tschager]

Mind you this is a bit of a hijack or Mario's work! But it's sort of luck that he posted something that was complete and readable right as I was starting to dig into this again....

No offense to Mario, but his method is nothing new. If anyone should be credited for setting up the basics of connection handling it should be Sergio.

I'm not trying to claim that Mario was the first to design a connection model of this type. I am saying that I am hijacking his work in that he designed something, wrote a spec, posted it for feedback, and then I came along and started discussing it (1) in a bigger scope (e.g. for all of LDraw and not just his app) and (2) with additional functionality (supporting at least some physical operations and not just snapping).

For what is worth the basics have been laid out a long, long time ago, in a galaxy ...

http://www.ldraw.org/OLD/reference/specs/lcd/

We started talking about official connection models before on the forum, but for some reason it went nowhere every time. The main reason for that (i think) was people where afraid it would not be adopted by the tools.

Guys it's in your hand. If you come up with something we just have to adopt I guess we will do just as we did with the texture thing - well, it would be nice if the community or the LSC could also throw in their 2 cents once you have presented it.

w.

[Mario Pascucci]

Hi Ben.

1. Annotation of existing primitives with connectivity, e.g. if you use stud.dat, you get a male stud connector 'for free'.

This is not always true, and I need a "visual check" for every part I add in connectivity library. At the moment, I found some parts designed using primitives as mere geometric shortcut, but ignoring the semantic meaning. Some examples:
- parts 59426.dat and 32209.dat (axle 5.5 with stop): parts are axles, but uses axlehol8.dat as primitive for axle. If you use "axlehol8.dat" (defined as "Axle hole perimeter") to detect a "female" connection for axle these two parts will becomes axle holes 5.5 unit long for connection logic.
- part 4727.dat uses a "peghole.dat" as a base. I don't know, but should be better use a stud4.dat, I think. If you use this part with autodetect, a "peghole" connection is placed in a totally wrong position
- part 3680.dat: an inverted peghole.dat to obtain central hub.
- 32556.dat: an inverted peghole.dat to obtain the flange.
just to say some.
I don't say that LDraw library is wrong, absolutely NO. But, until now, it was used as a geometric shape definition library, with defined primitives used as shape shortcut, sometime regardless the primitive meaning and defined purposes.

So, including connectivity to primitives is surely a good starting point, but at the present state of library it can lead to unwanted/weird connectivity issues: you need to delete some connections derived by primitives in final part. This is a major issue in autodetect strategy. In my connection library some parts are inserted only to avoid autodetection, that includes unwanted and wrong connection points.

This is why I take so long to add new parts in connection library: I must check every single part connection in connection editor before add to list of "correctly autodetected" or add a ".cxml" file to library.

Mario

[Orion Pobursky]

I would go so far as to say that using the specialized, non-generic primitive for something other than their intended use is wrong and were I review such a part on the Parts Tracker I'd would probably give it a Hold vote. Scaled studs at another example of what I would consider primitive misuse.

[Ben Supnik]

1. Annotation of existing primitives with connectivity, e.g. if you use stud.dat, you get a male stud connector 'for free'.

This is not always true, and I need a "visual check" for every part I add in connectivity library. At the moment, I found some parts designed using primitives as mere geometric shortcut, but ignoring the semantic meaning. Some examples:
- parts 59426.dat and 32209.dat (axle 5.5 with stop): parts are axles, but uses axlehol8.dat as primitive for axle. If you use "axlehol8.dat" (defined as "Axle hole perimeter") to detect a "female" connection for axle these two parts will becomes axle holes 5.5 unit long for connection logic.

Right - this is a risk with "primitive"-based connectivity - when a primitive's semantic meaning is abused for its geometric shape, we introduce a connectivity problem.

I agree with Orion: in my opinion the best long term option for the library is:
- Primitives have "semantic" meaning. Use stud.dat when you mean a lego stud, not just when you have a cylinder.
- Parts that have wrong connectivity due to "abuse" of primitives should be fixed by changing which primitive is used.

This is a fundamental change to the library, so the community (or LSC or SteerCo or??) would have to agree to this change in library policy as part of an implementation plan. It's not a trivial change.

But my view is that in the long term it's better to fix "abused" primitives than to have to build all connectivity data separately and check it. The power of LDraw is in the leverage the primitive system gives us*; I think the alternative is a much slower, longer process for building connectivity meta-data.

cheers
Ben

* If we are not going to leverage having primitives, we might as well just create each part out of a triangle soup and model them in a 3-d modeler. :-): -)

[Roland Melkert]

So, including connectivity to primitives is surely a good starting point, but at the present state of library it can lead to unwanted/weird connectivity issues: you need to delete some connections derived by primitives in final part. This is a major issue in autodetect strategy. In my connection library some parts are inserted only to avoid autodetection, that includes unwanted and wrong connection points.

Exactly, this is why I use the SNAP_CLEAR meta in LDCad in order to drop (some) of the inherited information in certain files in order to redo it in the local file.

Another problem might be the continuation of e.g. a hole present in a primitive (e.g. stud with hole) into a higher part. The stud with hole primitive might have the hole defined as it's used manytimes as is (so not it's only 4ldu deep). But in some parts it continues into the higher structure (e.g. a 1x1 round brick) and has to be dropped / redone.

But in the end the inheritance system is mostly very positive, you just need to 'certify' all bricks just like with BFC mechanism.

[Roland Melkert]

But my view is that in the long term it's better to fix "abused" primitives than to have to build all connectivity data separately and check it. The power of LDraw is in the leverage the primitive system gives us*; I think the alternative is a much slower, longer process for building connectivity meta-data.

Not necessary If inheritance problems are corrected on in the higher parts followed by 'certifying' the part it self it won't matter. Although new parts should just prevent it of course.

[Roland Melkert]

Guys it's in your hand. If you come up with something we just have to adopt I guess we will do just as we did with the texture thing - well, it would be nice if the community or the LSC could also throw in their 2 cents once you have presented it.

I would prefer a group effort from the start, but I do realize that would take ages But I certainly would not like it to go the way as it did with the texture extension. Proof of this is in it's (non) usage imho.

[Ben Supnik]

Guys it's in your hand. If you come up with something we just have to adopt I guess we will do just as we did with the texture thing - well, it would be nice if the community or the LSC could also throw in their 2 cents once you have presented it.

I would prefer a group effort from the start, but I do realize that would take ages But I certainly would not like it to go the way as it did with the texture extension. Proof of this is in it's (non) usage imho.

Hi Roland,

I think this -is- a group effort. There are already multiple people involved in the discussion; some day, some time later, we will somehow come up with a draft, and at that point a more formal process can take place (e.g. an elected committee will make a final decision or request mandatory changes).

What steps should we take this early on to make sure that anyone who wants to be included is included?

cheers
Ben

[Mario Pascucci]

Hi Ben.

Violation of primitive semantic meaning is one aspect. One other is how to "detect" as more connection points as possible without complex/extended math/geometric computation.

Some examples:
- stud4.dat/stud4a.dat (underside tube): I chose to assign five connection points to this primitive: one stud receiver for center hole and four stud receiver at top left/right and bottom left/right. Parts like 3062b, 4073, 15279, 2569, 3957b gets right connection points, but when a plate 6x6 is analyzed by connection detector, it gets 125 underside stud receiver, because every stud4.dat gets 5 connections, but some are duplicated: two adiacent stud4a have two coincident connection, so I use a trivial duplicate check to avoid connection duplication.
- stud3.dat (underside pin/stud): used in 1xn bricks, plates and tiles, I chose to assign three connections: two stud receiver on sides and a pin-to-open-stud connection on pin base. In a 1x4 brick there are three stud3.dat, so there are two duplicated connection on adiacent pins, that duplicate checker detects and removes, but still connection placement is wrong in lots of parts because I chose to put connections on left and and right sides (along X-axis), when in some part pin is rotated or part is designed along Z-axis, so connection are wrong placed. No easy correction is available, so I need to do a visual check and manual editing.
- 1x1 bricks, plates and tiles: no primitives can be used to place a connection, because all of them uses basic shapes, like box5.dat.

At the present status of library I didn't find a simpler and safe way to detect connections from primitives, this is why I made a connection editor and a connection library.
Surely it is a my limit, and a limit in my coding/math/geometric skills. I don't even think to propose my model as a standard for LDraw library. I released specifications, code and sample only in hope that it was useful to anyone. Nothing more.

Mario

[Roland Melkert]

I think this -is- a group effort.

Yes, but the texture extension wasn't. Something I really want to prevent in a possible connection / snapping spec.

What steps should we take this early on to make sure that anyone who wants to be included is included

I think the main thing is to get (more) part authors involved, to see what they are thinking / want.

And, less important, move the discussion to the standards forum so it's clear we are talking about a general official connection model candidate.

[Roland Melkert]

There has been talk about adding a 'anti stud' primitive which would basically be an empty primitive. If this comes through new parts using that primitive would no longer need corrections.

But like most improvements in the library it's unlikely old parts will be updated unless other defects are discovered in them. So your manual work won't be for nothing.

[Philippe Hurbain]

I agree that these parts should be fixed. We already cleaned a lot of parts that used stud primitives for capped cylinders, but a few old parts still use similar (bad) tricks.

- parts 59426.dat and 32209.dat (axle 5.5 with stop): parts are axles, but uses axlehol8.dat as primitive for axle. If you use "axlehol8.dat" (defined as "Axle hole perimeter") to detect a "female" connection for axle these two parts will becomes axle holes 5.5 unit long for connection logic.

Clearly we need to define an inside-out version of axlehol8.dat to fix these parts.

- part 4727.dat uses a "peghole.dat" as a base. I don't know, but should be better use a stud4.dat, I think. If you use this part with autodetect, a "peghole" connection is placed in a totally wrong position
- part 3680.dat: an inverted peghole.dat to obtain central hub.
- 32556.dat: an inverted peghole.dat to obtain the flange.
just to say some.

All these parts are easy to fix, but these situations are not easy to detect visually. I think we should create a special thread to report these abuses.

So, including connectivity to primitives is surely a good starting point, but at the present state of library it can lead to unwanted/weird connectivity issues: you need to delete some connections derived by primitives in final part. This is a major issue in autodetect strategy. In my connection library some parts are inserted only to avoid autodetection, that includes unwanted and wrong connection points.
That's why SR3D and LDCad (http://forums.ldraw.org/showthread.php?t...0#pid15510) offer a mechanism to clear auto-detected connectivity. But I much prefer some wrong additional connection to missing ones

Scaled studs at another example of what I would consider primitive misuse.

I don't think this is an issue connectivity wise... Or is it ?

[Mario Pascucci]

Hi all.

I released two more files:
- connection editor as a "portable" package
- connection editor source code

I didn't have time to write a manual for editor, but user interaction and functions are identical to model editor.

Program is sketchy and misses lots of design helpers, but "it works™"

(Added above link to main message in this thread, too)

Mario

[Roland Melkert]

Scaled studs at another example of what I would consider primitive misuse.

I don't think this is an issue connectivity wise... Or is it ?

It depends on the type of connection and / or the origin of the primitive. But in general scaling (and even mirroring) should not be a real problem while inheriting information into higher parts as long you multiply the information's matrix (and optionally dimensions) too.

Also as mirroring and scaling can be detected you could decide to drop the info.

In Mario's model for example a scaled stud is no longer a stud and should be dropped, an axis on the other side should just apply the scale as long it's only the Y axis which is changing.

In LDCad it will matter even less as I'm describing shapes so a stud.dat will still work when scaled it just won't snap to 'normal' anti studs anymore but only equally scaled ones.

[Philippe Hurbain]

Thanks for confirming my feeling

[Ben Supnik]

That's why SR3D and LDCad (http://forums.ldraw.org/showthread.php?t...0#pid15510) offer a mechanism to clear auto-detected connectivity. But I much prefer some wrong additional connection to missing ones

My pipe dream is that if we fix "abused" primitives there will be no need for a parent part to -delete- the connectivity of its child primitives. (For any app that uses the library "as-is" this kind of work-around is necessary because the app can't fix the problems at the library level.)

Does anyone have examples where this is necessary even if primitives are only used for their canonical purposes?

cheers
Ben

[Magnus Forsberg]

Are you allready fixing these, Philo?
If not let me know, and I'll start correcting them.
I can find about 10-12 parts using peghole.dat incorrectly.

3957a
s\777s02
4083
6140
4873
2486
4360
32556 (yes, 'Technic Pin Long' is using a peghole.dat incorrectly. Funny.)
3680

4727 is allready fixed and uploaded at PT

Is 57518 correct or also wrong?

[Roland Melkert]

Does anyone have examples where this is necessary even if primitives are only used for their canonical purposes?

It's needed with things like the axlehole primitive if you keep track of 'slide' limits. The primitive it self is open ended but it might be used in e.g. a motor drive axle which is not (e.g. 71427c01).

Also I sometimes just flush all inherited info in certain (more complicated) parts in order to redo it in a more organized / readable way. For example 43123.dat which also uses a complete pin part in a 'static' way meaning those pins should no longer connect on one side.

See attached snap info for those two parts.