I am trying to write a renderer and so trying to understand the document http://www.ldraw.org/article/415.html.
My first question is does a reverse matrix (determinant < 0) perform a mirroring on the part as I have seen in some places or just changes the winding as the document suggests. I wish the pseudocode at the bottom of the document also included the negative determinant part of the drawing process.

Also regarding rendering. If I open the subpart box5.dat in ldview the backfacing polygons are not rendered. But If I create a file sample.dat and in it I put the line "1 16 0 0 0 1 0 0 0 1 0 0 0 1 box5.dat" and open sample.dat in ldview then the backfacing polygons are rendered. From reading the above document I do not understand why that is the case.

Thank you for any help.

Hi all,

For those that don't know me, I am the creator of Rebrickable. I make heavy use of your LDraw library of parts for the images on my site which are rendered via L3P/POV-Ray.

I thought you might be interested to know that I've now made all the images available for easy download from the site http://rebrickable.com/downloads

Cheers,
- Nathan

Hello, i'd like to draw a model that has x1681 non-technic threads in it.
I've understood that i have to use LSynth to design it, but from the tutorial it doesn't seem it handle that particular thread type. Can anyone confirm this before i adventure into learning to use it?

Thanks

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?

Is it only me or...? At first I thought LDView was making an April joke, which was almost a bit funny too. The thing is, if you have more than one copy of a submodel, LDView will render all of them a bit smaller. And - the more you have, the smaller all of them get!

I tried this with the 64bit versions of 4.2 Beta 1 (downloaded from SF) and 4.1.1.25 that I had previously compiled for 64bit. The 32bit version of 4.1.1.25 does not show this behaviour.

Steps to reproduce - make a model with one simple submodel (a 1x1 brick is enough), copy the submodel 4 times or so into the main model, and see what happens. Then double the amount of the submodels and press F5 in LDView.
Or download the model attached to this message.

Attached Files

  LDView_test.mpd (Size: 4.05 KB / Downloads: 0)

Following the tradition of TLG sharing information regarding the brick shapes we've got a new batch of what we use to call L(EGO)Draw parts.

http://news.lugnet.com/cad/?n=14755

This time they were not provided through the LEGO Universe channel (as you can surely imagine ;-) but directly by the LDD team itself. Also the formula has slightly changed: To shorten the time between the release of a part and when it has been finally certified through the LDraw Parts Tracker for the first time TLG provided data of prototypes. Those will be available in sets only in 2014. This leaves us with plenty of time to make them fit for an official LDraw parts update.

Though we will get only parts which have already been copyrighted we are still talking about highly sensible data. Only part authors and reviewers who have signed a NDA - non-disclosure agreement will get access to the L(EGO)Draw prototypes. Chris has set up a some sort of parallel PT and you will need a second account/password. The parts will then be held in queue until they actually hit the market. If you're interested to join the team just leave a short reply to this message.

However we've got permission to share a small sample with the community to get you an idea what's all about:



As usual I have uploaded the corresponding .dat files to my webspace. Just add the part number to the follwing path with one example provided:

http://www.holly-wood.it/tmp/LEGODraw/Pr.../10652.dat

Please use the following guideline for the ownership:

0 PartDescription
0 Name: Filename.dat
0 Author: RealName [UserName]
0 !LDRAW_ORG Unofficial_Part
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
...
0 !HISTORY 2013-04-01 {LEGO Digital Designer} Original part shape
0 !HISTORY YYYY-MM-DD [UserName] File preparation for NDA LDraw Parts Tracker

Willy Tschager
on behalf of the LDraw Steering Committee

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.

All of the current year (2013) city sets should be placed here.

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.

Now with better connection to LDStructure (version 1.2.0.0 is needed).

Website