Welcome! Log In Create A New Profile

Advanced
Re: Feedback Request: Table of Offests for Related Parts
February 07, 2013 03:00PM
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.
SubjectAuthorViewsPosted
Feedback Request: Table of Offests for Related Parts Ben Supnik489January 30, 2013 01:48PM
Re: Feedback Request: Table of Offests for Related Parts Roland Melkert215January 30, 2013 02:20PM
Re: Feedback Request: Table of Offests for Related Parts Ben Supnik355January 31, 2013 01:33PM
Re: Feedback Request: Table of Offests for Related Parts Roland Melkert325January 31, 2013 01:41PM
Re: Feedback Request: Table of Offests for Related Parts Michael Heidemann248February 01, 2013 07:57AM
Re: Feedback Request: Table of Offests for Related Parts Ben Supnik222February 01, 2013 12:51PM
Re: Feedback Request: Table of Offests for Related Parts Roland Melkert216February 01, 2013 12:58PM
Re: Feedback Request: Table of Offests for Related Parts Roland Melkert214February 01, 2013 12:56PM
Re: Feedback Request: Table of Offests for Related Parts Michael Heidemann229February 01, 2013 02:11PM
Re: Feedback Request: Table of Offests for Related Parts Ben Supnik215February 01, 2013 05:16PM
Re: Feedback Request: Table of Offests for Related Parts Ben Supnik209February 01, 2013 05:20PM
Re: Feedback Request: Table of Offests for Related Parts Steffen215February 02, 2013 05:43PM
Re: Feedback Request: Table of Offests for Related Parts Michael Heidemann222February 03, 2013 12:58AM
Re: Feedback Request: Table of Offests for Related Parts Steffen191February 06, 2013 04:58PM
Re: Feedback Request: Table of Offests for Related Parts Steffen188February 06, 2013 04:59PM
Re: Feedback Request: Table of Offests for Related Parts Roland Melkert180February 07, 2013 09:52AM
Re: Feedback Request: Table of Offests for Related Parts Michael Heidemann195February 08, 2013 10:17AM
Re: Feedback Request: Table of Offests for Related Parts Ben Supnik189February 03, 2013 09:11AM
Re: Feedback Request: Table of Offests for Related Parts Orion Pobursky230February 02, 2013 12:47AM
Re: Feedback Request: Table of Offests for Related Parts Steffen194February 06, 2013 05:02PM
Re: Feedback Request: Table of Offests for Related Parts Travis Cobbs206February 07, 2013 09:19AM
Re: Feedback Request: Table of Offests for Related Parts Roland Melkert180February 07, 2013 10:14AM
Re: Feedback Request: Table of Offests for Related Parts Sergio Reano268February 07, 2013 03:00PM
Re: Feedback Request: Table of Offests for Related Parts Allen Smith197February 08, 2013 09:00AM
Re: Feedback Request: Table of Offests for Related Parts Sergio Reano218February 08, 2013 02:21PM
Re: Feedback Request: Table of Offests for Related Parts Ben Supnik233February 12, 2013 06:59PM
Re: Feedback Request: Table of Offests for Related Parts Sergio Reano213February 13, 2013 02:29PM
Re: Feedback Request: Table of Offests for Related Parts Ben Supnik217February 17, 2013 11:11AM
Re: Feedback Request: Table of Offests for Related Parts Sergio Reano296February 17, 2013 01:59PM



Sorry, only registered users may post in this forum.

Click here to login