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