Since some years we have beneth the designid.dat files also itemid.dat files in our /parts folder.
This will be ok if there is never a conflict between design id number and item id number.

Joshua Delahunty now identified such a bad situation.(Please read his comments: http://www.ldraw.org/cgi-bin/ptdetail.cg.../74333.dat).

We need to stop immediately the usage of item-id.dat files in our standard /parts folder.

Any suggestion how to solve this issue is highly wanted.

Is there a limit on how many part I can have in a Shortcut?

I've put together the Horntail Dragon, but think is just too many.
I dislike the idea of all ready-made part shortcuts in the library. I have noticed the attempt from Steffen to add wheel and tyre shortcuts, but have been ignoring them so far. What do you think?

The idea of lego is the fun of putting them together yourself.

Attached Files

  52258c01.dat (Size: 2.07 KB / Downloads: 0)

So I was working on my little parts authoring tool (ldforge) again and ran into a little problemo: is there required to be a whitespace after the numeric code for comments? Is a line like "0// edge lines" valid or are they considered errorneous?

I would assume it's illegal but assuming is bad, so yeah. The specification doesn't seem to mention anything about this, maybe I am blind as usual?

Hi Y'all,

I'm sorry to start a third thread on part smoothing, but I wanted to step back and ask a process question; I haven't been involved in LDraw long enough to know how this gets sorted out.

There are a few ideas that have been thrown out on how to solve part smoothing problems, but they involve different groups of people and perhaps different standards bodies:

1. We might say that no change to the LDraw format or any parts or any change to authoring guidelines will happen, and programs need to take the most drastic steps while smoothing, e.g. code for the worst case.

2. We might intentionally modify the parts library, perhaps with mechanical transformations (E.g. run a program that splits T junctions over many parts). This would require some kind of approval.

3. We might intentionally introduce new syntax features into the LDraw file format (and then apply them to some parts) to simplify the process of smooth rendering.

Where do we go from here? Would it be useful for me to write up an RFC, just so we have a straw man?

I can continue coding assuming case 1, but such code will be non-optimal (e.g. we'll have to put in a part cache that we don't otherwise have just to make things performant) and such code would be obsolete if either 2 or 3 happen. If either 2 or 3 are on the table, it would be nice to plan for them.

cheers
Ben

The recent activity regarding automatic calculation of surface normals in order to produce smooth rendering in other programs (similar to how LDView has behaved for a long time, but via a different, better algorithm) has made me investigate places where LDView's current smoothing is failing, and this has led to this post, a revisit to the subject of T-Junctions.

The point is that, while I never thought about it before, T-Junctions prevent smooth shading from working. If you don't know what T-Junctions are, please see this article. I just updated that article to point out that T-Junctions on curved surfaces prevent smoothing algorithms from working on those surfaces.

Since, as far as I know, this has never been mentioned before, I don't think parts authors in the past have had any particular impetus to go to the significant extra work needed to avoid T-Junctions on curved surfaces. However, given that they prevent just about any reasonable smoothing algorithm from functioning, I think they should be avoided more strongly.

If someone can come up with a simple smoothing algorithm that works with T-Junctions, I will gladly stand corrected, but any such algorithm would also require per-pixel lighting in order to work with T-Junctions, and I think even with per-pixel lighting, the algorithm would end up being downright nasty.

The only alternative I can think of is to detect the T-Junctions during file loading, and automatically split the geometry involved. That doesn't seem very easy either, though. Does anyone know of a good, fast algorithm to do this? If so, we could potentially recommend that in all LDraw renderers, and remove the recommendation against T-Junctions in parts entirely.

Hey guys,
the leader of the German LUG 1000steine.de posted an actual colour chart in the www.


/Max

Hello everyone I am new to this aspect of lego and for a very long time I've wanted to build something of my own MOC.
I have an architecture model I built in college that I would like to legolize.

The physical model I have is at a scale of 1/8"=1' and as I mentioned I would like to recreate it.
I have seen very larger and complex models which even the smallest details are modeled with bricks. I imagine that all custom lego project start with the creation of the smallest element and goes from there? or the most natural approach would also be to use the lego man as as element of scale?

I would appreciate some pointers from the pro builders.

We have currently 372 parts on hold on the PT. This value is now nearly for half a year constant.
I would like to see that number decreasing

Everybody is invited to help to minimize that number !

Edit:
I just tried to identify those file, but sadly the question "Which files are on hold" are not answered by any function I tried on the PT.

This topic will be for LOTR models. A lot of parts is missing, but I think they will be completed.

Attached Files

  30210 - Frodo with cooking corner.mpd (Size: 3.08 KB / Downloads: 3)

My first shot at the Lego Mindstorms shooterbot base

Attached Files

  shooterbot_base.mpd (Size: 3.74 KB / Downloads: 3)