Is it written somewhere how we should write colour names in the part descriptions?

I have noted that many different abbreviations are used:
Trans Orange
TransRed
TrLtBlue
Trans_Yellow
Trans-Green

Is anyone better than the other? Should we standardize how to write it?

Physical Colour Shortcuts must mention the colour of the part, but how? As it is now we seam to use two types.
Either written in full, Dark_Bluish_Grey, or in hard brackets [72].

Strangely we have the:

33322.dat - Minifig Crown Tiara

in the latest update but not the needed hair piece:

http://www.brickowl.com/catalog/lego-min...hair-99240

w.

I wish everybody in LDraw a very happy and bricky 2015!

I wanted to make a part to celebrate this but I got kind of occupied slash lazy so yeah. I think this is forming into a habit of sorts.

In the list of Non-BFC'd parts there is a lot of parts that only need a correct BFC statement.
Parts like physical coloured shortcuts or mirrored versions of a design (left/right).

Two of the Technic Panels Farings, 32189 and 32535, have been fixed, but we also need to add a BFC statement to the mirrored parts, 32188 and 32534. All that is needed is to add " 0 BFC CERTIFY CCW " to them, (and change from Part to Unofficial_Part).

Many files was caught in Rolands libfix update, and are now at the PT, but all the mirrored parts are still left behind in the official library and needs to be sent to Admin for recycling.

Is there a way to find them and/or correct them automagically?

Hi all.

I've got back onto LDraw and part authoring after a few year's break, and I've started with some curved surface parts, specifically 11291 (http://brickset.com/parts/6019163).

Is there any advice on methods to measuring and creating the curved edges, (rather that trying to repurpose a 2d circular primitive) and top face given that the curve on each side is different?

Thanks.

Hi Y'all,

I've been playing with the idea of connectivity for a while now, and picked it up again after poking around Moc Builder recently. The main features I'd like to support in Bricksmith with connectivity data are:
- Easy assembling of models (by having Bricksmith know how parts want to "snap" together)
- Easy manipulation of irregular shapes (e.g. hinges at odd angles and technic assemblies) by letting Bricksmith understand how an entire sub-assembly rotates around an arbitrary hinge. (This would make irrelevant the part origin or META commands to "fix" the origin - the connectivity information would specify how a given part can rotate.)
- In an ideal world, Bricksmith would be able to figure out what the "actions" of a given model are. E.g. if you make a car and the doors open, the hood can pop up, and the trunk opens, ideally Bricksmith can, from the connectivity information, derive some kind of higher level "playability" data that describes what the model does. (This goal is much harder than the first two.)

I did some experiments with LDD and found that it goes very far in most of these directions. However, it also hits limits sometimes. For example, I downloaded an LDD build of 70165 (ultra agents HQ) and found that LDD couldn't figure out that the linear assembly of ball joints effectively form a hinge. As a result, the truck walls could not be "opened". LDD does seem to understand complex technic assemblies (at least sometimes) but sometimes moves the model all over the place trying to solve the system of multiple independent hinges.

Anyway, starting with the usual straw man of connector meta-data on parts (e.g. plugs and sockets or receptors modeled after things like stud, hole for stud, technic hole, technic axle, etc.) there are a few problems I'm not quite sure what to do about. This is sort of a brain dump of where I'm at in the design.

1. Friction: ignoring wear-and-tear on your real bricks, the friction of a given hinged connection varies by part. For example, 1x4 brick hinges tend to be very "floppy" and we can almost always assume that if they've been left hanging free, it was the intention of the modeler to make an opening door, moving part, etc. By comparison, 1x2 brick hinges are relatively stiff* and can be used to simply build at a 45 degree angle, or they can show intended motion. (See also 1x2 brick hinges used in place of a 1x2 brick with studs on side before we had SNOT bricks.)

I'm not sure how to determine what is intended "playability" and what is not. One solution is to treat everything that can move as playable, but the result would be that complex bar and clip assemblies (like the carefully modeled bogies that serious train nerds build) would be interpreted as incredibly complex moving parts, when they're really supposed to just sit there looking nice.

2. Movement limits: both MocBuilder and LDD support AABB collision testing on bricks, which helps solve the "it can't rotate any more because it bonks itself" problem. But it would still be nice to get -exact- rotation limits out of a given system. E.g. every 1x2 brick can rotate 0 to 90 degrees at most. To determine this from AABB, we'd be forced to build very complex AABB models of the hinge itself. Ideally an LDraw client would be able to determine some rotation information while punting on collision detection, or be able to operate even if the entire LDraw library wasn't correctly AABB modeled. (Realistically I think we could get partial connectivity implemented relatively quickly for a subset of parts, but having an AABB on every single part is a huge undertaking.)

3. Complex movement. A series of hinged assemblies may define a single play movement because of limits to interaction between moving parts. For example, consider a train with working steam pistons. A low level analysis of connectivity would reveal a number of sub-assemblies with relationships: a linear relationship between the piston and its housing, 1-degree rotational hinges on the various piston rod assemblies, and a one-degree rotational relationship on the axle to the axle bearings.

But the net result of all of those train parts moving is a -single- movement. For example, any given orientation of the axle relative to the train itself fully defines where all of the parts will end up, and if you drive the axle in an animation, all of the parts have to move along specific paths to keep connectivity.

I don't even know how you would begin to go from low level connectivity to complex movement, but I'd like to have a connectivity spec that does not omit any needed information to be able to someday solve this problem.

Anyway, that's the end of my brain dump - if anyone is already doing this stuff in-app, I'd be curious how the problems were solved.

thanks!
Ben


* as a kid I vaguely remember a huge range of stickiness among my hinges, and having to pick the right hinge for the job due to differences in friction.

Hej,
I think, I found a rounding problem in PrimGen2.
I'll continue to check all primitives for rounding errors, correct file ending and add a "generated with primgen" comment, when comparison is successful or the file is regenerated.
Please see these lines:

Following the discussion at
http://www.ldraw.org/cgi-bin/ptdetail.cg...s/6117.dat
on the PT, I'd like to suggest a new META for specifying a "good" origin of a file.

0 !ORIGIN x y z m1 m2 m3 m4 m5 m6 m7 m8 m9

It is just the keywords "0 !ORIGIN", followed by the usual translation and matrix data.
When not present, a default of

0 !ORIGIN 0 0 0 1 0 0 0 1 0 0 0 1

is assumed.

Adding this will allow us to adjust the "suggested" origin of parts even after they have become official,
WITHOUT breaking models that users have built with it.

Software aware of this new syntax can put its rotation center etc. to that origin when the user touches the part.

I'd like a MediaWiki savvy volunteer to clean up and streamline the wiki

To continue our earlier discussion about modernizing the spec, there seems to be 2 camps. This poll is designed to see where developer sentiments lie.