Does anyone of you have an executable of WINDZ available to give me?
It seems to not be downloadable anywhere anymore.
I've been BFCing parts in the past some time, always using the "manual method", i.e.,
looking at the part in LDView, identifying the wrongly oriented faces, coloring them in MLCad,
then changing their winding in LDDP, or inserting INVERTNEXT's.
When I look at parts in red/green BFC checking mode in LDView, I always thought
that the BFCing process - to a certain extent - should be easily automatable;
I think that's what WINDZ also does:
just render the part from various perspectives, and flip all faces that appear "red" during that.
Of course, if a surface gets flipped twice this way, it cannot automatically be oriented correctly,
and manual post-correction is needed. However, for a majority of parts, the described
method should trivially work like a breeze.
Does anyone of you know of software which does that?
I want to speedup my BFCing processing...
Having such a software would allow us to instantly BFC big amounts of our library,
and reduce the remaining manual work to the parts which really require attention.
My best preference would be a tool like edger, command line based,
and simply taking an input file, outputting a result file where all faces are oriented correctly,
and the file otherwise unchanged. Undecidable surfaces should be colored in a user-selected color,
so they can be taken care of manually.

Hi all,

Below is a perl script to take a bunch of angles and convert them to points on the edge of a circle primitve (ie. a 16 or 48 point polygon). The comments up top describe how to use it. It's designed to make generating rims on the bottom of curved parts relatively easy when there's only a few segments required and hand-coding makes more sense than using Philo's wonderful toys.

Tim

Currently, when you change the color of a road baseplate, the road surface changes color as well as the studded area. This is incorrect IMO, and the road surface should remain gray no matter what the color of the studded area.

My 2 cents.

Hi all,
Presently, the certification status of parts that have subparts is very blurry: there is only one yellow color tag. I think that this lack of visibility greately reduce review rate... Would it be possible to have a more detailed view, depending of status of subparts (and subsubparts and so on...)? eg.

• Yellow: at least one subpart in the tree needs more certification vote
  
• Orange: at least one subpart in the tree has a hold vote
  
• Light blue: all subparts in the tree have at least two cert votes
  
• Blue: all subparts are certified
  
• Bright Green: part has at least two cert votes, all subparts in the tree have at least two cert votes.
  
• Green: part and all subparts are certified.
  

I think the topic Chris raised about using color 16 in patterns where it makes the pattern useless for any other brick colors than the original one has had enough feedback from the general populous that we should now decide if the spec should be updated.

My personal opinion is that in cases like the fire logo, where it's clear that a specific color is required, that color should be used in the pattern file. And in cases like the gauge where it's ambiguous, color 16 should be used. Perhaps disagreements over whether or not something is ambiguous could be resolved by the part admin.

Thoughts, everyone else?

I would like to ask here if someone knows more about the status of peeron.com.
What was the last parts update integrated there?
Does anyone happen to know who will push the recent one to their site?

I see changes happen on their site everytime, e.g.
http://www.peeron.com/cgi-bin/invcgis/history
, but no integration of parts updates I can see so far.

For example, look at the famous 7740 train inventory:
http://www.peeron.com/inv/sets/7740-1
where I would hope that the MOVED-TO parts automatically get updated
when integrating a new parts release.

In forum pages like this, what does the Views count represent? Unique users or a cumulative count including repeat views by the same user? Is the count for a higher-level message incremented if you open the whole thread from the last message?

I'd prefer the former to get a feel for how many members are interested in a particular topic, even if they don't respond.

Hi,

99009 Technic Turntable Small Top
99010 Technic Turntable Small Base

Above two part didn't release even as unofficial part yet.

Anybody, any able man, please, do something for these part.

KWON

An issue has arisen on the Parts Tracker that I think deserves wider discussion than is possible there.

By convention, we only model the printed colours of patterns and use colour 16 for any unprinted areas. This allows the base part colour to "show through" when rendered. Although this is exactly what would happen if LEGO were to print the pattern on another colour of part, there is an argument that in some cases we are restricting the usability of the LDraw library by doing this.

The Fire Logo Pattern has caused most concern. By leaving the unprinted left-hand flame as colour 16, the LDraw part files that use this can only really be used in red. The second example is the Slope Brick 45 2 x 2 with Gauge Pattern, which is normally printed on black and uses the base part colour to create some of the detail. The potential benefit is shown in this rendering by Magnus Forsberg - left image = "desired" rendering on green; centre image = actual pattern on black"; right image = actual pattern on green.

I can see that the case is clear for the Fire Logo - the left flame was always intended to be red. For other patterns, including the Gauge Pattern, we would need to guess about the intent of the pattern designer. That guesswork makes it very difficult to apply any consistency, and potentially generates more controversy than the current discussion, as the implementation will depend on each person's interpretation of the design intent. The benefit of the current solution is that it is totally unambiguous, but I fear we are applying rules for their own sake and denying rendering opportunities to the users of the LDraw parts library.

For now I have certified these patterns and their parent parts as they now fit with the current convention. However, I would welcome further discussion, opinions and potential solutions.

The forum won't keep me logged in from one session to another on Firefox. It keeps me logged in on both IE and Chrome, but not Firefox. Is anyone else having the same problem? I'm guessing it's something with the configuration of one of my Firefox add-ons (like Adblock Plus or NoScript), but before I spend significant time and effort tracking down the problem, I'd like to verify that other people using Firefox are able to stay logged into the forum from one session to the next. (I already deleted all cookies that matched ldraw as a search string.)