Ben Supnik Wrote:But awkward parts is a really really limited problem...general connectivity (and general connectivity with animation or movement) is significantly more complicated!
This is why I've started out with basic one on one point matching/snapping, which as you can see in my above youtube clip actually works quite well on the smaller parts.
Ben Supnik Wrote: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.
This is also how I see it, if we we're to add info to the library it has to be generic. Otherwise software developers still need to add stuff to it if they want to do something a bit different.
Ben Supnik Wrote: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.
I basically started implementing my thoughts as described here:
http://forums.ldraw.org/showthread.php?t...73#pid8173
It's using 4 different shape describing meta's at the moment, and some additional support ones (like include and reset). I'll probably have to add one or two more for the very exclusive part shapes.
Ben Supnik Wrote: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.
This is exactly what I'm experiencing in my current setup, even unoptimized it's almost a non issue for modern processors to do a couple of thousand (far/near) ray intersection tests. And on top of this it's a very good candidate for multithreading.
Ben Supnik Wrote: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.
I'm always interested, my current setup is evolving almost daily tough, but basically it works with extendable parameters on a one meta per shape basis.
The cylinder one for example basically lists the varying radius's along a line like so:
0 !LDCAD SNAP_CYL [ gender=M ] [ caps=one ] [ secs=R 6 10 A 6 5 ] [ pos=0 0 0 ] [ ori = 1 0 0 0 1 0 0 0 1 ] [ center=true ]
This says: There is a one open ended male cylindercal shape existing out of a radius 6 round section of length 10 and a radius 6 axle shaped section of length 5 at 0,0,0 using identity rotation and the position is it's center.
There are more optional parameters (sliding behavior, friction, rotation limits, what do when scaled/mirrored by type 1 references etc) but those are far from set in stone.
These meta's are currently read from a mirror library tree which acts like an auto include location. The information will be inherited by higher referencing parts so currently all studs have info like you described. The real problem with inheritance are shapes like the 'anti studs' because those live in empty space and thus don't share a primitive reference.
I have been thinking about adding the info indirectly e.g by adding 4 anti studs to the commonly used middle under stud of bricks. But this introduces a whole new set of problems (e.g unwanted ones, duplicates, etc).