LDraw.org Discussion Forums
Insert Related Database - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html)
+--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html)
+--- Thread: Insert Related Database (/thread-8797.html)

Pages: 1 2 3


Insert Related Database - Ben Supnik - 2013-03-31

Hi Y'all,

I am working on "Insert Related…" in BrickSmith. The idea is simple: select a door frame, and BrickSmith can tell you which doors fit, and put them into the correct location.*

Insert Related solves two problems:

- If you haven't memorized every single Lego Part, it can be hard to find the right matched part, e.g. the right tire for the wheel, the right door for the frame, the right glass for the window. Some of these are manageable (e.g. windows), some I still don't know after tens of thousands of parts inserted (e.g. tires). Insert related is a database that "knows" which parts fit for certain special roles.

- Some parts have relative origin offsets that aren't on the major brick grid> This typically happens when a part has its origin set for easy rotation instead of easy relative placement. So even once I find the right door for the frame, how does it 'snap' in?

I have two questions:
1. Is anyone else interested in the data for other modeling programs?
2. Does anyone have any feedback on the proposed data format? (This matters mainly if anyone else wants to use the data.)

There's nothing BrickSmith specific going on, hence the inquiry.

Here's what I have right now:

122c01.dat 3641.dat -31 6 0 0 0 1 0 1 0 -1 0 0 Left Tire
122c02.dat 3641.dat -31 6 0 0 0 1 0 1 0 -1 0 0 Left Tire
122c01.dat 4084.dat -31 6 0 0 0 1 0 1 0 -1 0 0 Left Tire
122c02.dat 4084.dat -31 6 0 0 0 1 0 1 0 -1 0 0 Left Tire
122c01.dat 3641.dat 31 6 0 0 0 -1 0 1 0 1 0 0 Right Tire
122c02.dat 3641.dat 31 6 0 0 0 -1 0 1 0 1 0 0 Right Tire
122c01.dat 4084.dat 31 6 0 0 0 -1 0 1 0 1 0 0 Right Tire
122c02.dat 4084.dat 31 6 0 0 0 -1 0 1 0 1 0 0 Right Tire

Basically the format is:

<parent file> <child file> <relative transform> <placement name>

The relative transform is the matrix that a 1 directive would have for the child if the parent is at 0,0,0, unrotated, and the parts are put together according to the relationship described to the right. The relationships names help disambiguate (for UI purposes) multiple attach points, e.g. do we want to put this tire on the left or right wheel, do we want the door to open to the left or right, is this the left or right shutter?

It is intentional that the relationship name is the same for multiple lines with different parts - the idea is that the user can say two things:

"If I want to add part 3641.dat to 122c01.dat, what are my choices?"

(The answer is that 3641.dat can act as a "Left Tire" or "Right Tire", and there are different transforms to do that.)

or the user can ask:

"If I want to add a Left Tire to 122c01.dat, what parts can do this?"

(The answer is that both 3641.dat and 4084.dat fit as tires - by luck the transform is the same for both but this won't be true some of the time.)

The data is 'flat' - that is, relationships are provided only for final parts, not for sub-parts.

To create the data, I created a very simple .mpd file with the parts assembled 'correctly' (using various steps and sub-models to structure the parts) and then ran a Python script over it to get the final flat results. This means that, to create the data, I simply modeled each part once, visually checking to see if the part was positioned correctly.

Anyway, if this is of interest to anyone else working on modeling software, please let me know - I'm happy to share the data.

Cheers
Ben

* My previous post on this:
forums.ldraw.org/showthread.php?tid=8008,8025
got side-tracked into a discussion of 'true connectivity'. This is not that at all - it's just a way to insert parts. I would like to do connectivity some-day, but connectivity is an ocean-liner of a feature, and this is a rubber raft. Or something like that.


Re: Insert Related Database - Roland Melkert - 2013-04-01

I'd be interested, even with the ocean liner in place this information would be helpful.

I was thinking about something similar like this a while back but decided to push it to the next next LDCad version thinking it's part of connectivity which I'm planning for a later version.

You could probably collect some information from scanning the headers of the library, most companion parts use a identity matrix anyway and share similar descriptions or !help lines.

For example the wheel and tyre parts usually have the same diameter in their description (you could setup regex rules for this in the cfg file). The list would then automatically assimilate new parts in new library's and you only have to add information about less obvious parts to the config file.

I was also thinking about a self learning feature at some point using grouping.


Re: Insert Related Database - Philippe Hurbain - 2013-04-02

About matching parts, Bricklink contains useful data, placed at the bottom of part description. Eg. here http://www.bricklink.com/catalogItem.asp?P=6870 we learn that 6859 matches 6870 part.
You can see the database here: http://www.bricklink.com/catalogRel.asp
SR3D builder has a tire matching tool.


Re: Insert Related Database - Ben Supnik - 2013-04-02

Hi Philippe,

The tire matching tool was my inspiration. :-) :-) But since S3RD has connectivity, the tire matching list contains only parent/child and no coordinates...it doesn't need them.

Re: Bricklink, thanks -- that's really helpful for seeing if I missed combinations. Sadly sometimes the offset is not published, not in the HELP tags and not obvious. But...that's why such a related parts list might be useful. :-)

Cheers
Ben


Re: Insert Related Database - Steffen - 2013-04-14

the idea of using a mpd file to store the relationships between related parts is a great one here IMHO.

it simply allows to provide a list of part combinations,
and this list easily can be used by the tool to insert the related parts.

my suggestion would be to provide this mpd file together with the tool,
and make the tool parse that list at runtime


Re: Insert Related Database - Ben Supnik - 2013-04-14

Hi Stephen,

An email thread with Roland convinced me to use the .ldr file directly too -- this is what I have for the current format (an excerpt):

Code:
0 !PARENT
1 4    0 0 0    1 0 0 0 1 0 0 0 1 122c01.dat
1 4    0 0 0    1 0 0 0 1 0 0 0 1 122c02.dat
0 !CHILD Left Tire
1 1    -31.000000 6.000000 0.000000    0.000000 0.000000 1.000000  0.000000 1.000000 0.000000  -1.000000 0.000000 0.000000  3641.dat
1 1    -31.000000 6.000000 0.000000    -0.000000 0.000000 1.000000  -0.000000 1.000000 -0.000000  -1.000000 -0.000000 -0.000000  4084.dat
0 !PARENT
1 4    100 0 0    1 0 0 0 1 0 0 0 1 122c01.dat
1 4    100 0 0    1 0 0 0 1 0 0 0 1 122c02.dat
0 !CHILD Right Tire
1 1    131.000000 6.000000 0.000000    -0.000000 0.000000 -1.000000  -0.000000 1.000000 -0.000000  1.000000 0.000000 -0.000000  3641.dat
1 1    131.000000 6.000000 0.000000    -0.000000 0.000000 -1.000000  -0.000000 1.000000 -0.000000  1.000000 0.000000 -0.000000  4084.dat

- The comments tell the parser what the relationship names are and who is a parent-child.
- Parents can be offset from 0,0,0 to make the file more viewable.
- The file is currently 'flat' - steps and mpd sub-files are ignored - so an author can use them for organization but they are not needed to make the relationships.

Cheers
Ben


Re: Insert Related Database - Steffen - 2013-04-14

a good approach, I've some more questions/ideas/inspirations to share:

(a)
could you get rid of the unnecessary trailing zeros to save filesize and parsing time?

(b)
using LDR as file extension instead of MPD for this contents seems wrong to me.
your contents is a list of (PARENT+CHILDREN) assemblies, and the natural way to store something like that would be MPD
, as far as I can see, because LDR is/should be/should be thought of "1 assembly", not "a list of assemblies".
to word it more abstract: LDR is "an entity", and MPD is "a list of entities". you need the list. what were the reasons to use LDR instead of MPD?


Re: Insert Related Database - Ben Supnik - 2013-04-15

Hi Steffen,

Steffen Wrote:(a)
could you get rid of the unnecessary trailing zeros to save filesize and parsing time?

I think so -- the output is just what BrickSmith natively saves.

Quote:(b)
using LDR as file extension instead of MPD for this contents seems wrong to me.
your contents is a list of (PARENT+CHILDREN) assemblies, and the natural way to store something like that would be MPD
, as far as I can see, because LDR is/should be/should be thought of "1 assembly", not "a list of assemblies".
to word it more abstract: LDR is "an entity", and MPD is "a list of entities". you need the list. what were the reasons to use LDR instead of MPD?
[/quote]

Hrm - there's a few issues here.
- The file itself I think is an MPD file, because it contains multiple MPD parts.
- The extension is therefore definitely wrong - it should have been an .mpd file. I think BrickSmith auto-suggests .ldr in the file-save dialog box for all files, so I just didn't notice.
- My format may not match the "natural way" to store such a suggestion database. Since .mpd files aren't really meant to store suggestion/related part lists, the format was going to require some extra conventions or metas no matter what.

The format which I have so far (which allows mpd parts but does not depend on them for the structuring of the actual relationship data) was chosen to simplify editing and maintaining a suggestion file in-editor. The original format was a simple flat list for easy parsing and databasing; Roland suggested to me that if the file itself was an LDraw file then it would be easier for users to add part relationships. So the current format is designed to create a 'workspace', with one mpd sub-model containing several relationships, and each relationship containing whole sets of parents and children. The setup is pretty arbitrary - it's what I found to be straight-forward to work with and may not be usable to anyone else.

(In particular, I wanted to be able to work with whole sets of related parts on one screen and not have to change MPD sub-models for every single relationship.)

Cheers
Ben


Re: Insert Related Database - Travis Cobbs - 2013-04-15

Your excerpt isn't an MPD. Maybe the file at large is, but nothing in your excerpt suggests that this would be the case. Also, please see this recent decision by the LSC. It explicitly states that any LDraw file may make use of the MPD language extension (although usage of the MPD extension is forbidden in official parts). My personal opinion is that LDR should be used as the file extension for all files visible to an end user.


Re: Insert Related Database - Allen Smith - 2013-04-15

a) Removing "unnecessary zeroes" is not a meaningful optimization. This is not where the processing time is spent when opening a file. Also, filesize is essentially irrelevant. This is an aesthetic consideration(*) and nothing more.

b) The default extension for an MPD file is .ldr. (It is also acceptible to use .mpd or .dat, but in my opinion, you shouldn't.)
http://www.ldraw.org/article/218.html

(*) Bricksmith has an internal option to output formatted columns for easier reading, which is what you're seeing in Ben's file. It's off by default because LDrawers seem to hate it, so I don't know how he managed to obtain it.