Welcome! Log In Create A New Profile

Re: snapping primitives
December 12, 2013 06:27PM
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.


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.

Experimental part snapping in LDCad 1.3 Roland Melkert1046December 11, 2013 12:25PM
Re: Experimental part snapping in LDCad 1.3 Michael Horvath321December 11, 2013 03:21PM
Re: Experimental part snapping in LDCad 1.3 Roland Melkert304December 11, 2013 04:15PM
snapping primitives Steffen353December 11, 2013 08:57PM
Re: snapping primitives Max Martin Richter479December 11, 2013 11:33PM
Re: snapping primitives Ben Supnik549December 12, 2013 06:27PM
Re: snapping primitives Roland Melkert593December 13, 2013 10:28AM
Re: snapping primitives Ben Supnik336December 15, 2013 05:31PM
Re: snapping primitives Roland Melkert369December 15, 2013 06:27PM
Re: snapping primitives Philippe Hurbain476December 11, 2013 11:56PM
Re: snapping primitives Roland Melkert304December 12, 2013 10:05AM
Re: snapping primitives Philippe Hurbain274December 12, 2013 10:53AM
Re: snapping primitives Travis Cobbs290December 12, 2013 11:01AM
Re: snapping primitives Philippe Hurbain298December 12, 2013 11:12AM
Re: snapping primitives Roland Melkert313December 12, 2013 11:24AM
Re: snapping primitives Philippe Hurbain287December 12, 2013 11:56AM
Re: snapping primitives Michael Heidemann290December 12, 2013 12:39PM
Re: snapping primitives Max Martin Richter309December 12, 2013 12:46PM
Re: snapping primitives Michael Heidemann294December 12, 2013 01:01PM
Re: snapping primitives Max Martin Richter301December 12, 2013 01:19PM
Re: snapping primitives Michael Heidemann339December 12, 2013 01:24PM
Re: snapping primitives Michael Horvath401December 12, 2013 03:06PM
Re: snapping primitives Michael Heidemann560December 13, 2013 07:55AM
Re: snapping primitives Roland Melkert296December 12, 2013 01:07PM
Re: snapping primitives Michael Heidemann311December 12, 2013 01:17PM
Re: Experimental part snapping in LDCad 1.3 Philippe Hurbain510December 12, 2013 12:01AM
Re: Experimental part snapping in LDCad 1.3 Roland Melkert313December 12, 2013 09:52AM
Re: Experimental part snapping in LDCad 1.3 [Version 2.0] Roland Melkert351December 28, 2013 04:33PM
Re: Experimental part snapping in LDCad 1.3 [Version 2.0] Michael Horvath310December 28, 2013 06:00PM
Re: Experimental part snapping in LDCad 1.3 [Version 2.0] Roland Melkert257December 29, 2013 12:51PM
Re: Experimental part snapping in LDCad 1.3 [Version 2.0] Philippe Hurbain313December 29, 2013 02:01AM
Re: Experimental part snapping in LDCad 1.3 [Version 2.0] Arthur Sigg355December 29, 2013 04:42AM
Re: Experimental part snapping in LDCad 1.3 [Version 2.0] John309January 03, 2014 07:17AM
Re: Experimental part snapping in LDCad 1.3 [Version 2.0] Roland Melkert293January 03, 2014 10:29AM
Re: Experimental part snapping in LDCad 1.3 [Version 2.0] John444January 03, 2014 10:41AM

Sorry, only registered users may post in this forum.

Click here to login