Hi Guys,
I implemented "insert related" in Ldraw to solve the 'awkward parts' problem - it lets you do things like put the glass door in a frame where the origins of the two parts are off by a goofy number of LDUs 9 so that the door can rotate around its axis. I've been pretty happy with the results in that it was quick to code the feature, quick to add to the 'related parts' dictionary, and it's quick to model with it. (I've been meaning to post notes on the final format in the bricksmith tree for the wiki but it took a while to get a wiki login and then I got distracted.)
But awkward parts is a really really limited problem...general connectivity (and general connectivity with animation or movement) is significantly more complicated!
With that in mind, I really would like to see a general-purpose connectivity scheme in LDraw someday - there are some editing and analysis functions you just can't write without it.
Sergio explained quite a bit about his connectivity system; I thought his model was a pretty good prototype for what LDraw needs -- there are a few cases where I might suggest elaboration, but his tech would be a great starting point. And he seemed (to me) amenable to us using a similar idea in LDraw and/or even seeding some connectivity data from an sr3d export.
Here are his sets of posts from a while back.
http://forums.ldraw.org/showthread.php?t...84#pid8184
http://forums.ldraw.org/showthread.php?t...15#pid8215
http://forums.ldraw.org/showthread.php?t...55#pid8255
http://forums.ldraw.org/showthread.php?t...32#pid8332
Re: in the library or out of the library, I suggest we hedge:
- Design a conceptual data model for connectivity that is agnostic of how the data is stored (side table or in-part).
- If we have to start with side tables, so be it.
- Maybe we move the data into the parts later once the tech is proven.
In particular, I think that it's important that meta-data for connectivity be "compose-able" - in other words, if you put meta-data on stud.dat (saying that stud.dat connects in such-and-such way) then that meta-data is implicitly spread to every stud in every part everywhere.
If we don't do this, then it will be hard to move the data into the parts themselves in the long term because parts have the semantics of fully including sub-parts.
Finally in terms of performance, I don't think we'll have a scalability problem with an LDraw part set that has tons of connections. Connections exist at small locations in space (e.g. they are typically points or lines). Therefore when you bring a 1x1 brick into Datsville, while there might be a million or more _total_ connections, there are going to be a very small number of nearby connections. Dump the connections in a spatial index (e.g. an R-tree or something) and you can have a very fast search even in a huge model.
(By comparison, _drawing_ parts is a real scalability problem because the user can always put more parts on screen and we must draw them all. This is why I would like to have low-vertex-count alternates, so that parts can be 'dumbed down' when they are small in total pixel size.)
Roland, if you have any interest in moving toward general connectivity and a shared file standard, please let me know -- I can send you my notes from when I last looked at this and/or review prototype connectivity data if you have built it.
Cheers
Ben
I implemented "insert related" in Ldraw to solve the 'awkward parts' problem - it lets you do things like put the glass door in a frame where the origins of the two parts are off by a goofy number of LDUs 9 so that the door can rotate around its axis. I've been pretty happy with the results in that it was quick to code the feature, quick to add to the 'related parts' dictionary, and it's quick to model with it. (I've been meaning to post notes on the final format in the bricksmith tree for the wiki but it took a while to get a wiki login and then I got distracted.)
But awkward parts is a really really limited problem...general connectivity (and general connectivity with animation or movement) is significantly more complicated!
With that in mind, I really would like to see a general-purpose connectivity scheme in LDraw someday - there are some editing and analysis functions you just can't write without it.
Sergio explained quite a bit about his connectivity system; I thought his model was a pretty good prototype for what LDraw needs -- there are a few cases where I might suggest elaboration, but his tech would be a great starting point. And he seemed (to me) amenable to us using a similar idea in LDraw and/or even seeding some connectivity data from an sr3d export.
Here are his sets of posts from a while back.
http://forums.ldraw.org/showthread.php?t...84#pid8184
http://forums.ldraw.org/showthread.php?t...15#pid8215
http://forums.ldraw.org/showthread.php?t...55#pid8255
http://forums.ldraw.org/showthread.php?t...32#pid8332
Re: in the library or out of the library, I suggest we hedge:
- Design a conceptual data model for connectivity that is agnostic of how the data is stored (side table or in-part).
- If we have to start with side tables, so be it.
- Maybe we move the data into the parts later once the tech is proven.
In particular, I think that it's important that meta-data for connectivity be "compose-able" - in other words, if you put meta-data on stud.dat (saying that stud.dat connects in such-and-such way) then that meta-data is implicitly spread to every stud in every part everywhere.
If we don't do this, then it will be hard to move the data into the parts themselves in the long term because parts have the semantics of fully including sub-parts.
Finally in terms of performance, I don't think we'll have a scalability problem with an LDraw part set that has tons of connections. Connections exist at small locations in space (e.g. they are typically points or lines). Therefore when you bring a 1x1 brick into Datsville, while there might be a million or more _total_ connections, there are going to be a very small number of nearby connections. Dump the connections in a spatial index (e.g. an R-tree or something) and you can have a very fast search even in a huge model.
(By comparison, _drawing_ parts is a real scalability problem because the user can always put more parts on screen and we must draw them all. This is why I would like to have low-vertex-count alternates, so that parts can be 'dumbed down' when they are small in total pixel size.)
Roland, if you have any interest in moving toward general connectivity and a shared file standard, please let me know -- I can send you my notes from when I last looked at this and/or review prototype connectivity data if you have built it.
Cheers
Ben