Feedback Request: Table of Offests for Related Parts

[Ben Supnik]

Hi Y'all,

Some official parts have origins that favor easy rotation along their hinge but make them (relatively) difficult to place. For example:

3853 (window 1x4x3) and its shutters/panes (3854, 3856)
60596 (door frame 1x4x6) and its doors (e.g. 60623, 30178c01).

I saw that one author had written a help comment into a proposed part that stated the relative offset ot place the part in its parent. Unfortunately, the comment is not machine-readable. So my idea is to make a table of relative placements that would describe where to place the child part (e.g. the door) relative to the parent (its frame) to align the hinge mechanism. Since the parts are official, it's too late to change origins (and in some cases an origin that favors assembly would have other problems) but the table could allow a 3-d editor to insert the part directly.

A few questions:

- Has anyone already done this/is there an existing system that could be leveraged? I am sure i'm not the first person to consider this.
- Would such meta data better be stashed in the part itself or kept in a side table?
- Is there interest from other app developers in having access to relative placement table?
- How to handle parts that can be connected in multiple ways (e.g. the shutter can go to the left or right of the window)?
- Does this come too close to a "connections database"?

On that last point, my view is that even if such a scheme were stop-gap in the bigger picture, it would still be useful and could be replaced with something more thorough later. "Placement" info is simple enough that it could be done now, and it's useful even for 'fixing' a small number of part placements.

Thoughts?

[Roland Melkert]

You are talking connection information here, there is a standard in the works for that (although it seems pretty much dead at the moment).

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

On the main issue, I've setup such a db years ago for use in my LD4DStudio project. You could take a look at the coordinate information contained in the *.4sp files.

http://www.ld4dstudio.nl/

Haven't updated them to the latest LDraw library in quite some time though.


If you go on collecting this information more deeply I would be interested in it for use in future LDCad versions (I'm planning snapping for 1.3 or 1.4). Since the LCD thing seems pretty dead, I'm all open to any shared approach on this or maybe refire the LCD thing.

[Ben Supnik]

Thanks for the links; the .4sp files seem like a production version of sort of what I had in mind.

The full connection db proposal did get me thinking about how much 'more' we would want, either now or later. I updated to the latest LDD and noted that they have both positive suggestion (e.g. they seem to know when a part has 'snapped' into another, more or less) and negative (you can't overlap two bricks in space), and they seem to understand hinged vs non-hinged connections.

Let me think a little bit about how much functionality would really be useful...the LDD hinge tool is useful enough that it made me go "I wish I had that for BrickSmith". :-) At the same time, we could go so far as to make something impossible to code. :-)

Possible features:
- Identification of good connections (snap together).
- Identification of bad connections (e.g. a lack of snap).
- Identification of illegal placement (overlapping bricks).
- Identification of legal rotations (e.g. rotate this hinged thing).
- Identificaiton of illegal rotations (e.g. you can't rotate this hinge past 90 degrees).
- Identification of structural failure (e.g. if you slide the clip past this point on the antenna, the clip is no longer attached).
- Combinations of these features (e.g. if you rotate this hinge, you'll stop at X degrees because any further and part Y and Z will overlap...(!)

I'd be happy with just good connections and a hinge tool, but it would also be nice to have a file format that we won't have to throw out later if someone wants to do more.

(The hinge tool basically rotates an entire snapped together collection of parts around a known hinge, using the hinges degrees of freedom. For models that use hinges to create particular angles or shapes, this is significantly faster than doing a manual "rotate around point" by coordiante with a multi-part selection.)

[Roland Melkert]

SR3DBuilder does that so may looking at it's files give some further info.

But I would like to see an publicly thought-out / official standard like LCD supporting this kind of stuff.

[Michael Heidemann]

That would indeed great, but as long as we only have one application (SR3D) that supports these things, I fear that the consens will always be - how does SR3D solve this. And that is not what I think about our rules.

But I am very fine with adopting SR3D technology as our base standard (first step).

[Ben Supnik]

Hi,

Is there any IP problem with using SR3D as a reference for any part of a connection db spec? Would Sergio be okay with that? (Is he here on the forums? :-)

I'll take a look at SR3D later...I'll have to install it on a PC to get access to the data files.

Cheers
Ben

[Roland Melkert]

That would indeed great, but as long as we only have one application (SR3D) that supports these things, I fear that the consens will always be - how does SR3D solve this. And that is not what I think about our rules.

I agree with you on this, although it might even be better to start from scratch (even forget the lcd doc).

First step would be to gather some more people/authors interested in this and set up some basic 'must have' / 'nice to have' lists.

Second most important thing is to decide how to integrate any new information into the existing library. For example are we going to edit hundreds/thousands of official files (I doubt it) or use some kind of companion/include file system. Or maybe even a single xml.

With LDCad I'm mainly thinking / doodling about a way to generate (most) of the information from the existing parts without having to manually add info to them. If this could be done fast enough it would just become part of the loading/prepping process, if it's heavy work generate some sort of cache.

[Roland Melkert]

Although he is quite open about the format of the files, I don't think you should blindly copy any of his information without consulting him first.

[Michael Heidemann]

I think that generating from already existing files will be ok for max. 50% of the connection points. Leaves 50% . That is too much. Maybe it has been at LD3Modeler (sorry, i do not remember the name well ) where all the connection points are stored in another directory but with the same name? I like that approach. I would also be fine with a file beneth the current dat file but with a different extension (maybe ldc for ldraw connection). The benefit with the separate directory / folder will be that we do not just double the files in our main folders.

To start from scratch is in my opinion not the best way, because we have already a system that works. So we have also a lot of data already that can be used.

[Ben Supnik]

I think there are applications of a conncetion DB that can only work when the entire library is correctly and completely annotated.

But there are other applications that can provide value to users even when only a few parts are annotated.

I think this second point is important because I think the motivation for the community to work toward completing connection data will be stronger if there is at least some immediate benefit to partial completion of the work.

So I would say that technology used to "seed" a connection database would be valuable. For example, if it was possible to pre-populate 50% of the database with programatic analysis of existing parts, that's a great start. As a user of LDraw, I'd rather contribute to finish the second 50% of connection information than start from 0%. :-)

It may also be possible to get leverage by putting connection annotation on parts at the sub-part level. For example, if studs are built by referencing sub-parts (rather than hand modeling) then tagging a few sub-parts with stud connection information would effectively add studs to a large number of parts.

[Ben Supnik]

If the data starts as a "side table" of some kind, it could later be merged into the parts with a one-time batch process if desired; similarly if the data were on the parts themselves it could be extracted. My guess is that a side table would be much easier for initial prototyping - it would let a few developers get started with connection data without interfering with the main library.

Since official parts aren't going to have their coordinate origins change there isn't a risk of the connection file getting out of date if it only targets official parts.

Question:

1. Are there any pre-made lego parts that translate in more than one dimension? I can't think of one off-hand but maybe there's an obscure one out there...

It does look like there are ball & sockets where the maximum angle of deflection varies by direction, e.g. it looks to me like 63082 with 2508 can rotate more horizontally than vertically.

[Orion Pobursky]

I'd like to second this. SR3DBuilder is the defacto standard. Anything we (as in LDraw committees) should at least be compatible with that standard to start with. This avoids alienating Sergio (since he was the first to release a viable program with connection data) and allows us to possibly leverage the work that he has already been done.

[Steffen]

I do not like the side-file idea, in both of its incarnations
- 1 sidefile per part
or
- 1 sidefile for the whole library.
My reasoning is that the connection information is a genuine information coupled tightly to an individual part.
There is no better place to put that information as directly into the part's DAT implementation.
I can not imagine a more canonical place to put that.
This especially becomes important when that connection information at one day in the future will have become
an official standard. Then it needs to be reviewed / checked the same way as the rest of a part's implementation.
Not putting the information into the part's DAT file will mean evading that strategy.

[Michael Heidemann]

That is of course very true. For this approach we need a new meta tag.

my suggesting would be ldraw connection database
0 !LDCDB [some parameters]

Those entries should start after the header and before the data section.
Each connection point in the current data section should be discribed by one line.

Do we expect that each connection with other parts are always the same? How can we describe if a connection works different with different parts ?

[Ben Supnik]

SR3D uses a patch file system to be able to virtually add data to part files without having to edit the library. (This is one example of many ways to add data to the part library without touching the actual .dat files.)

My view is that the syntax and storage format for connection data is really quite moot as long as the semantics are compatible with _eventually_ putting the data into the parts directly.

As an example, consider the case of putting a connection on a stud. If stud.dat is marked with a connection (via a separate database or patch file or any of these systems that avoid touching the library), does the connection become present in every single part that references stud.dat?

If the answer is "yes" then converting the data from patch files or a separate XML table to data in the library .dat files would be straight forward because the meaning of the data hasn't changed, only where we store it.

But if the answer is "no" (e.g. the XML file describes connections for a part but not parts that use that part) could be very difficult because it would be hard to maintian the old meaning when applied to the library.

So I think it is important to have a system that _can_ work with the part library someday. But it is okay to have it not do this immediately. (E.g. Sergio's "patch file" scheme could be adequate as a way to get started.)

[Steffen]

what about this?

0 !CONNECTION 59.3 28 39 1 0 0 0 1 0 0 0 1 stud

0 !CONNECTION 59.3 28 39 1 0 0 0 1 0 0 0 1 axlehole

The last words are keywords which denonte the TYPE of the connection.
The numbers are the normal transformation data (translation and matrix).

Or maybe a shorter meta would be better?

0 !CONN 59.3 28 39 1 0 0 0 1 0 0 0 1 stud

0 !CONN 59.3 28 39 1 0 0 0 1 0 0 0 1 axlehole

[Steffen]

Directly after having written this, I wonder why we are cramming all new syntax elements into comment metas.
Like
0 !LICENSE ...
etc.

We could instead think of using linetype 6 for connection information:

6 0 0 0 1 0 0 0 1 0 0 0 1 stud

Note again that "stud" does not mean a reference to "stud.dat" here, but instead states
that a connector of type "stud" is present there.

Of course, I know that we don't do this because old tools will not know the "6",
but thinking this to its end will mean that we will never be able to add new linetypes 6,7,8,9,
and instead continue to cram everything into "comments" of linetype 0 plus a new meta each time.

[Steffen]

+1

[Travis Cobbs]

I agree here. The implementation details of SR3DBuilder may mean that some change might actually help SR3DBuilder. There was a comment earlier in this thread that SR3DBuilder uses a patch file system to allow it to virtually change the official parts without having to modify the original files. It seems to me that if connection info suddenly starts showing up in official parts, and it's in the same format as his existing connection info, it might actually cause problems for SR3DBuilder. So, I think it would be best to work with Sergio to find out what the implications would be.

There's also the question of how to get all his existing connection info incorporated into official parts. Ideally, it wouldn't require all of them to go through the full PT review process. If there's a way we could do this all at once, then my original concern above (about files with connection info interfering with SR3DBuilder's patched connection info) could probably be addressed simply via coordination. But I'm not sure how feasible it would be.

There's also the obvious question of whether or not Sergio wants his format to become the official ones, and whether or not he's willing to make his connection info public. Additionally, he probably doesn't want to have to wait on parts going through the PT review process to add connection info for use by his program, so that's a potential problem as well.

Note: even after all this apparently negative exposition, I still feel that if possible we should use Sergio's connection data if at all possible.

[Roland Melkert]

I would prefer a shorter one like !LDC followed by a sub meta keyword if more then one meta is needed. e.g.

About the 5+ type lines, I think it's mainly a legacy thing. But I also feel if we ever introduce a new 'core' linetype it should be mesh related e.g. making type 6 a cylinder or sphere or something.

[Roland Melkert]

I really have mixed feelings about that, I agree that SR3D does some amazing things with this info, but I also firmly believe if we take the LCD / public / from scratch method instead of this 'easy' route. We could setup something even more amazing.

For example I don't really like all the connection types (also present in LDC though). I would really prefer a more general way of describing 'hotspots' in ways of general shapes. If something fits something else is then deducible by: will this shape fit in this other shape?

For example if you got a cylindrical hole at some place and a cylinder pin somewhere else it will fit if the diameter is smaller or the same and it's length is shorter or equal to the depth of the hole. Same goes is one the 'pin' shape is rectangular it will still go into the other shape if it's general diameter is equal or less (technic axle in beam hole). But you don't have to tell the software connection type axle hole goes into bla bla bla bla bla.

You could also assign friction parameters to these shapes making the way they snap/stick together math based with endless possibilities. And the best thing it's to the implementing software to decide the final behavior / depth of use of this information (e.g. only snap equal diameter stuff, do full blown collision detection etc).

I would greatly prefer this: over here are coordinates and you MUST use them this way.

[Sergio Reano]

Hi everybody,

first of all let say I'm afraid to get into this discussion so later, but are some days I don't have a look to this forum.
This is going to be a long read answer with some tecnical details at the end for the ones that could be interested...

Before answering to the discussion let me tell some consideration about my application connection approach:
- it was year 2007 when I first start to manage connections in my application. My program were still not public and I had no referral into this or other community
- I were alone to solve the connections management, and alone to create my application
- when, about into 2009, I asked to lDraw community how to approach the connection in the part definition, it was told to me that modifying parts definition to include a "connection database" could requires years of work before parts could be officialized

So here is how my application manage connections:
- most important thing were to have most connection automatically detected by the application while parts are loaded from parts file definition.
- additional required information that cannot be automatically detected are currently manually added creating a file for each part with the same name of the part it refers to and stored in the c:\lDraw\Conns folder
- The sintax for an additional connection is much more simple than the ones proposed but, as you can see using SR3DBuilder it works:
C ID x y z ox oy oz where
C= keyword to indicate a connection to be added
ID = connection ID indicates the TYPE of the connection going to be added
x y z = position of the connection
ox oy oz = coordinates of the connection
- you can also find the following 2 sintax:
G n x y z where G stays for Gear connection, n is the teeth number and xyz are the position
D ID x y z where D stays for Delete connection of type ID at position xyz

To perform the connection autodetection I make deep use of the fact that many (a lot of, nearly 95%) of the connections are generated by subparts you can find in the c:\lDraw\P folder. So everytime a subpart is loaded one or more connections are created on the fly. Some tricks are used to add axle connections, mid stud connections and other connection types.
Moreover connections are hinerited, so, if a connection is defined in a part or subpart, it will be transformed and added to any parts makeing using of it.

Even if when I coded my appl I don't take care of the LCD specification, it is not too far from its contents. On the other side, I wouldn't be able to follow its specification since I could not find the time to follow them all: are too much. I was needing something easy to implement and working someway.

Now the connection engine of my application is consolidated and usually (not always ;-) ) only the manual work of adding missed connection can cause some problem. For this reason, even if the lDraw community will decide to implement some different connection encoding, my application will continue to use the actual one.

I do not want to impose my approach as a standard but there are some good reasons to support this:
- It is a done work
- It is a working work
- It is easy enough to update and align to any new part (currently everything is done by me)
- Can be better if the community works in the direction of standardize connection --> subpart
- It has been the first

I read all the discussion (up to a pair of hour ago) and I saw many intersting proposals like the possibility to let an hypotetic application recognize the shape of a connection by its geometry description and decide if it can connect to another. I say "hey, good, its fantastic!". But have you considered the ability to encode such a code routine? You can decide to find and save a lot of information about any connections but... are them so useful? Isn't a simplified approach better?
It is so easy to make things complicated later... and even with my approach they are not so simple !

Anyway I'm open to help and encourage anyone will try an approach to connections and connection detection, but please don't ask me for code parts for 2 reasons:
1) my code is deeply dependent from its contest: a copy/paste function is of no use
2) I'm very jelous of my code !! ;-)

That's all folks !!
Sergio

Following are some more detailed information about application encoding with some extraction from SR3DB source code.
The most of the connections database is not coded into any file but is computed at runtime. The following is an extraction from my application code showing recognized connections type (the ID in the above lines)

'Connection Types
Public Enum ConnType As Integer 'Type of connections
NotConnection = 0
Stud = 1 'Stud* part
ToStud = 2 'Is normally in the back of the stud and is where a Stud connection can be stored
PegHole = 3 'PegHole Part
HingeM = 4 'Hinge Male
HingeF = 5 'Hinge Female
MidStud = 6 'Centre of stud2 typical part, store BackStud connections
Belt = 7 'Belt connection (added at runtime only)
Connect = 8 'Connect* Part/subpart
Friction = 10 'Crowned connections
Axle = 11 'Axle part connection
AxleHole = 12 'AxleHole
MidStudUp = 13 'Connection among 4 studs up, can connect BackStud2
Gearc = 14 'Gear Connection (added at runtime only)
Rack = 15
ToStudNoHide = 16 'Like ToStud, but show connected studs

TowBallM = 17
TowBallF = 18

SlideM = 19
SlideF = 20

HoseM = 21
HoseF = 22
HoseF2 = 25

FixedM = 23
FixedF = 24

Fake = 26
Sticker = 27

BackStud2 = 9 'BackStud Big (Stud4 part)
BackStud = 4 'BackStud Small (Stud3 part)
End Enum

While the following is the connection interaction results. So when 2 connection come in contact they can generate different mobility types fixed, rotation, translation, roto-translation, spheric joint (towball), flex ...

'Check if connection type CT1 and CT2 can be connected each other. return mobility grade for the connection
Public Function CanConnect(ByVal CT1 As ConnType, ByVal CT2 As ConnType) As MobT
Select Case CT1
Case ConnType.Stud
If CT2 = ConnType.ToStud Or CT2 = ConnType.ToStudNoHide Then Return MobT.Fixed
If CT2 = ConnType.BackStud2 Then Return MobT.Fixed
Case ConnType.BackStud2
If CT2 = ConnType.Stud Or CT2 = ConnType.MidStudUp Then Return MobT.Fixed
Case ConnType.ToStud, ConnType.ToStudNoHide
If CT2 = ConnType.Stud Then Return MobT.Fixed
Case ConnType.Axle
If CT2 = ConnType.AxleHole Then Return MobT.Fixed
If CT2 = ConnType.PegHole Then Return MobT.RotoTransl
If CT2 = ConnType.Fake Then Return MobT.Translation
Case ConnType.AxleHole
If CT2 = ConnType.Axle Then Return MobT.Fixed
If CT2 = ConnType.BackStud Or CT2 = ConnType.HingeM Then Return MobT.Rotation
If CT2 = ConnType.HoseF Then Return MobT.Flex
Case ConnType.PegHole
If CT2 = ConnType.Connect Then Return MobT.Rotation
If CT2 = ConnType.Axle Then Return MobT.RotoTransl
If CT2 = ConnType.HoseF2 Then Return MobT.Flex
Case ConnType.Connect
If CT2 = ConnType.PegHole Then Return MobT.Rotation
If CT2 = ConnType.HoseF Then Return MobT.Flex
Case ConnType.HingeF
If CT2 = ConnType.HingeM Or CT2 = ConnType.BackStud Then Return MobT.Rotation
'If CT2 = ConnType.HoseF Then Return MobT.Flex
Case ConnType.HingeM
If CT2 = ConnType.HingeF Or CT2 = ConnType.AxleHole Then Return MobT.Rotation
If CT2 = ConnType.MidStud Then Return MobT.Fixed
Case ConnType.MidStud
If CT2 = ConnType.BackStud Or CT2 = ConnType.HingeM Then Return MobT.Fixed
Case ConnType.BackStud
If CT2 = ConnType.MidStud Then Return MobT.Fixed
If CT2 = ConnType.AxleHole Or CT2 = ConnType.HingeF Then Return MobT.Rotation
'If CT2 = ConnType.HoseF Then Return MobT.Flex
Case ConnType.Gearc
If CT2 = ConnType.Gearc Then Return MobT.Rotation
If CT2 = ConnType.Rack Then Return MobT.Translation
Case ConnType.Friction
If CT2 = ConnType.Friction Then Return MobT.Fixed
Case ConnType.MidStudUp
If CT2 = ConnType.BackStud2 Then Return MobT.Fixed
Case ConnType.TowBallF
If CT2 = ConnType.TowBallM Then Return MobT.TowBall
Case ConnType.TowBallM
If CT2 = ConnType.TowBallF Then Return MobT.TowBall
If CT2 = ConnType.SlideF Or CT2 = ConnType.SlideM Then Return MobT.Fake
Case ConnType.SlideM
If CT2 = ConnType.SlideF Then Return MobT.Translation
If CT2 = ConnType.TowBallM Then Return MobT.Fake
Case ConnType.SlideF
If CT2 = ConnType.SlideM Then Return MobT.Translation
If CT2 = ConnType.TowBallM Then Return MobT.Fake
Case ConnType.FixedM
If CT2 = ConnType.FixedF Then Return MobT.Fixed
Case ConnType.FixedF
If CT2 = ConnType.FixedM Then Return MobT.Fixed
Case ConnType.HoseF, ConnType.HoseF2
If CT2 = ConnType.Connect Or CT2 = ConnType.HoseM Or CT2 = ConnType.Axle Or CT2 = ConnType.HoseF Or CT2 = ConnType.AxleHole Or CT2 = ConnType.HingeF Or CT2 = ConnType.PegHole Then Return MobT.Flex
Case ConnType.HoseM
If CT2 = ConnType.HoseF Then Return MobT.Flex
Case ConnType.Fake
If CT2 = ConnType.Axle Then Return MobT.Translation
Case ConnType.Sticker
If CT2 = ConnType.Sticker Then Return MobT.Fixed
End Select

Return MobT.NotConnected
End Function

When placing a part in the model a snap take place everytime a connection already present in the model is in the range of a connection inside the adding part and the results mobility state is different form NotConnected.

[Allen Smith]

Sergio, thanks very much for this detailed write-up. SR3DBuilder has some of the nicest, most useful, and innovative ideas in any LDraw editor.

For connections derived from ldraw\p, have you defined those connections in external files, or are they hard-coded into your application source code?

I understand you don't want to share any of your application's source code, but are you willing to make your raw connection data available to anyone in the community? Would you ever be willing to move the connection data into a publicly-accessible source repository (like svn) where it could be improved and accessed by the public—but without any of the heavy-weight and sloooow process which made using an official LDraw Connection Database impossible for you?

Lastly, could you explain the ox oy oz parameters in more detail? Is that the direction vector for the connection?

Allen

[Michael Heidemann]

Code:

making type 6 a cylinder or sphere or something

That does not make sense in my eyes. For those shapes we have already our primitives. And defining such meshes like you suppose, what is the benefit? We also need to fit these meshes with connecting shapes. In my eyes we do not need any new shape indicator as in the 1-5 lines all can be expressed.

But the idea of Steffen sounds good to me. One question that needs to be answered is "Are files with lines 6 (or above) readable by current tools?".

Edit:
MLCad - "Error in line, should file be loaded" and the line is deleted if you proceed and save.
LDView - "Error parsing line" no effect on visual result
DATHeader - "Error using 0 comment" - strange error message. Correction of that line do not work, so it stays

[Sergio Reano]

Hi Allen,

we can follow different ways:
- If it is needed, then I can code a small routine that extracts all identified connections for each part and write them to separate files using the syntax implemented in my application. This can help anyone needing the connection database using it, but, also, any improvement made to the database can be easily reused by my application
- On the other side I can try to detail the way I create my DB connections from subparts, but this is quite tricky to explain and may cause different application identifying different connections. I suppose it is not a good solution

Anyway there are some additional considerations to do: the most important is that may connections used in the application cannot be predetermined and stored into a database. An example of them are gears: while you can pre-determine the position of the axle they will turn around, you cannot know where 2 gears will be connected to transfer motion, so this connection is added AFTER the gears are placed. This is valid also for racks, sliding parts, screw worm and a few of other parts.

About to specific details about syntax:
ox, oy , oz represents the orientation of a connection. So the axle connections present on a 135° connector (part 32192.dat) will have an approx orientation of 0 0.707 0.707

Sergio

[Ben Supnik]

Hi Sergio,

Thank you for the details!! I looked through the SR3D files (I saw all of the patch files) and have thought a bit about the mathematics of connections; one thing is not clear to me.

For the axle and peghole, does your system know how _long_ the axle is? For example, is there a requirement that the length of the vector [ox oy oz] be the length of the axle?

I do have another question: I noticed the "tire manager" file that appears to associate wheels with tires. Does SR3D know the correct position for the tires on the wheels? Or does this come from the part connection data?

I like the idea of exporting the connection DB into files that could then become the beginning of a shared connection DB. And I am very glad that your system leverages the part-subpart relationship; without this managing connections would be impossible, I think.

cheers
Ben

[Sergio Reano]

Hi Ben,
will try to answer point by point...

For the axle and peghole, does your system know how _long_ the axle is? For example, is there a requirement that the length of the vector [ox oy oz] be the length of the axle?

The orient vector just represents the connection orientation. For example all studs on untrasformed bricks and plates are normally oriented along Y (vertical) axle. In an untrasformed technic axle connections are along X axle.
More clarification point: in a technic axle (but also in a bar and other "clippable" parts) connections are at discrete positions. There is not an axle connection at some position and long x Lego Units, but a serie of single connections each one oriented ad positioned at 1 LU from previous and next all along the part (for example the axle).
Instead for sliding connections (IE in pistons, pneumatic and other parts) there is a starting and ending point of a continuos line of available connections oriented along the line.

I do have another question: I noticed the "tire manager" file that appears to associate wheels with tires. Does SR3D know the correct position for the tires on the wheels? Or does this come from the part connection data?

Tire manager does not take care of part positioning. It just show wheels tires compabilities. The FixedMale in the wheel and the FixedFemale connections in the tire do the trick of snapping at correct position.

Hope this can help...

Sergio

[Ben Supnik]

More clarification point: in a technic axle (but also in a bar and other \"clippable\" parts) connections are at discrete positions. There is not an axle connection at some position and long x Lego Units, but a serie of single connections each one oriented ad positioned at 1 LU from previous and next all along the part (for example the axle). Instead for sliding connections (IE in pistons, pneumatic and other parts) there is a starting and ending point of a continuos line of available connections oriented along the line.

Ah - does this mean that a technic axle cannot slide inside a technic brick with a hole? I would think the axle is a "fixed" connection (like the clips) for some holes (like the + shaped hole) but slide/translate for a round-shaped hole.

Cheers
ben

[Sergio Reano]

Obviously a technic axle can rotate and slide into a peg hole (or pin hole). You can easily test this by using the application.

The resulting mobility between 2 connection is computed by the function CanConnect as described at the end of my first post in this topic. So the following cases are covered with an axle connection:

Public Function CanConnect(ByVal CT1 As ConnType, ByVal CT2 As ConnType) As MobT
Select Case CT1
Case ConnType.Axle
If CT2 = ConnType.AxleHole Then Return MobT.Fixed
If CT2 = ConnType.PegHole Then Return MobT.RotoTransl