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

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:

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

Hi Roland.

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

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.

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.

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.

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 Wink
Ben Supnik Wrote:no offense, but I consider ...

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

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 Big Grin 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 Big Grin

Philippe Hurbain Wrote:I prefer something that allows forbidden combinations than the inverse

I agree 1000000 percent Big Grin
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?
Roland Melkert Wrote: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
Pages: 1 2 3 4 5 6