| Welcome, Guest |
You have to register before you can post on our site.
|
| Online Users |
There are currently 604 online users.
» 0 Member(s) | 600 Guest(s)
Applebot, Bing, Facebook, Google
|
|
|
| Both 3626b and 3626c patterned heads? |
|
Posted by: Magnus Forsberg - 2013-04-06, 10:25 - Forum: Parts Authoring
- Replies (3)
|
 |
This year there seems to be many "old" patterns printed on the new head, 3626c, and perhaps we need to decide how to treat them.
Must there be both a 3626b and a 3626c version of every re-released pattern?
Should all b-heads be renamed to "...with Blocked Stud"?
Should all c-heads be named "...with Hollow Stud"?
I don't think that's necessary.
The "c" in the partnumber, 3626cpXX.dat, tells me that it is a new head, with hollow stud.
Howard Lande has made a number of new heads, both as b- and c-heads.
3626bpb122, 3263bpb322, 3626bpb366, 3626bpb411, 3626bpb471, 3626bpb633, 3626bpb719
3626cpb122, 3263cpb322, 3626cpb366, 3626cpb411, 3626cpb471, 3626cpb633, 3626cpb719
(btw, they all need renumbering too)
Is that really necessary?
|
|
|
| Insert Related Database |
|
Posted by: Ben Supnik - 2013-03-31, 20:35 - Forum: Parts Authoring
- Replies (26)
|
 |
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.
|
|
|
|
| Busy until May 2013 |
|
Posted by: Nils Schmidt - 2013-03-27, 21:41 - Forum: Off-Topic
- Replies (3)
|
 |
I will be extremely busy until May and I am looking forward to release a new version of my pattern creator (with reference lines!) in June. Furthermore, I will try to release a first alpha version of the part creator in July.
|
|
|
|
| Proposal: Fast Track Parts Tracker Parts |
|
Posted by: Orion Pobursky - 2013-03-24, 7:36 - Forum: Standards Board
- Replies (2)
|
 |
A number of people have mentioned that minor edits should be fast tracked on the PT. I agree. Here's my proposal:
Code: The Parts Tracker (PT) Admin may, at his discretion, fast track a part on the
Parts Tracker if it is considered by him to be a minor edit. The term "fast track"
is defined to mean any system where a part is required to have less votes
than normal. This may include unilateral approval by the PT Admin. In all cases
the PT Admin must approve the part. All fast tracked parts must appear on the
PT until the next regular update.
Examples of minor edits (note this list is not all inclusive):
- Any header modification including part renaming
- Creation of Moved To and Aliases
- Modification for greater decimal precision
- BFC certification
- Elimination of errors such as bowtie quads, colinear points, or T-Junctions
Thoughts?
|
|
|
|
| Point matching Re: Question about edges |
|
Posted by: Tim Gould - 2013-03-23, 22:17 - Forum: Parts Authoring
- Replies (23)
|
|
I'm going to split this off as a new thread since the old one is unwieldy...
When we develop a list of points (via check and snap), there will be (hopefully only a few) remaining points that have not been snapped to each other and remain with only _one_ tri or quad accessing them. We can exploit this as these points must be: - Part of a t-junction
- A point that has not been snapped properly
- An edge point (but this should be illegal in an LDraw part)
There is absolutely no other reason for a point not the be shared amongst at least two tris/quads. We can store the number of facet prims accessing the point via a simple count on the list of points.
So here's the deal:
Code: SnapPoints
foreach Point not in TwoTris/Quads
# Check if the point is part of a t-junciton
If CheckForTJunction then SplitTJunction
# Check for nearby points with a larger (eg. 0.05) tolerance
DoNearbyCheck(TOLBIG)
SnapToPoints
endfor
If, at the end of this code, there are points that are still not shared then the part can probably be flagged as bad.
Tim
|
|
|
|
|
![[Image: L%28EGO%29Draw_prototypes.jpg]](http://www.holly-wood.it/tmp/LEGODraw/Prototypes/L%28EGO%29Draw_prototypes.jpg)
