Insert Related Database
2013-03-31, 20:35 (This post was last modified: 2013-12-12, 5:22 by Steffen.)
2013-03-31, 20:35 (This post was last modified: 2013-12-12, 5:22 by Steffen.)
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.
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.