> Also, it's too bad there is no official library of connection data
in the hinterlands of our minds there is the idea of adding this information to the library itself,
the same way as currently just the geometry.
in a way, it already is contained there implicitly, for example, stud.dat not only means
that there is something LOOKING like a stud but also SNAPPING like a stud.
and so on.
the only question is how to put this info into the library.
I strongly favor _not_ putting this into a special "connection table" as a separate file,
but instead use a per-part, i.e., de-central approach.
the connectivity information would be reviewed the same way as currently the geometry of a part.
to me, the ideal way to model that would simply be using primitives for that:
we already have stud.dat.
we can invent a new primitive which carries the meaning "fits onto a stud".
it will contain no visible geometry at all, just carry the information where a stud could snap.
a part file would place this wherever needed, for example, a 2x4 brick will have
2x4 usages of this suggested primitive on its underside.
we could even create stugs of it
,
so filesize is not really an issue.
and renderers would not be affected, as these files would not bring in _visible_ geometry.
however, for debugging/visualization purposes, they could.
a user then could _see_ where the snapping places are.
the same mechanism could be used not only for stud.dat, but also for others.
example: c-clip. it can snap for example on a long cylinder. so if a part has such a region,
it would place a "c clip snapper" primitive there, scaled properly to fully extend over the cylinder's length.
software then easily can detect that there a c-clip can snap.
the only information we need to store somewhere is which
2 primitive pairs match for snapping, e.g.
stud.dat snaps to snap-stud.dat.
c-clip.dat snaps to snap-c-clip.dat.
axle.dat snaps to axlehol.dat.
and so on.
i feel that our library is already very near to this. its logic and structure already BEG for a feature like this.
EDIT: I just found the old thread discussing ideas like this: http://forums.ldraw.org/showthread.php?t...97#pid8797
in the hinterlands of our minds there is the idea of adding this information to the library itself,
the same way as currently just the geometry.
in a way, it already is contained there implicitly, for example, stud.dat not only means
that there is something LOOKING like a stud but also SNAPPING like a stud.
and so on.
the only question is how to put this info into the library.
I strongly favor _not_ putting this into a special "connection table" as a separate file,
but instead use a per-part, i.e., de-central approach.
the connectivity information would be reviewed the same way as currently the geometry of a part.
to me, the ideal way to model that would simply be using primitives for that:
we already have stud.dat.
we can invent a new primitive which carries the meaning "fits onto a stud".
it will contain no visible geometry at all, just carry the information where a stud could snap.
a part file would place this wherever needed, for example, a 2x4 brick will have
2x4 usages of this suggested primitive on its underside.
we could even create stugs of it
,so filesize is not really an issue.
and renderers would not be affected, as these files would not bring in _visible_ geometry.
however, for debugging/visualization purposes, they could.
a user then could _see_ where the snapping places are.
the same mechanism could be used not only for stud.dat, but also for others.
example: c-clip. it can snap for example on a long cylinder. so if a part has such a region,
it would place a "c clip snapper" primitive there, scaled properly to fully extend over the cylinder's length.
software then easily can detect that there a c-clip can snap.
the only information we need to store somewhere is which
2 primitive pairs match for snapping, e.g.
stud.dat snaps to snap-stud.dat.
c-clip.dat snaps to snap-c-clip.dat.
axle.dat snaps to axlehol.dat.
and so on.
i feel that our library is already very near to this. its logic and structure already BEG for a feature like this.
EDIT: I just found the old thread discussing ideas like this: http://forums.ldraw.org/showthread.php?t...97#pid8797