Some months ago Matthew Fleming on Twitter posted instructions for a funny Donald Trump MOC (branded as the "President" model from the "Ego" company). I couldn't find the LDraw file for it, so I made it myself. I hope you like it.

Attached Files

  Trump.ldr (Size: 4.96 KB / Downloads: 7)

Hey all,

I'm looking to have these 2 parts made and added to the library.

47577 Minifig Hockey Body Armor Plain

https://www.bricklink.com/v2/catalog/cat...77#T=C&C=1

And

[color=#000000][font=Tahoma, Arial]92814 Minifigure, Headgear Cap, Graduation Mortarboard with Tassel[/font][/color]

https://www.bricklink.com/v2/catalog/cat...4#T=C&C=11

Hoping someone do this for me?
Thanks in advance.

Regards

Derek Pearce (The Brickspace)

Attached Files

  47577.png (Size: 74.89 KB / Downloads: 55)
  92814.png (Size: 65.06 KB / Downloads: 54)

Hello,

I noticed that some parts consist of one or more individual parts, e.g. "Hinge Control Stick and Base (Complete)", Design 4592c01. This part is also available in other versions where the stick has a different color. Or the upper and lower parts of mini figures, some of which are already in the library. My question now is, does it make sense or is it desirable or not to include these parts in the library?

Greeting

Manfred

Since we had only 5 confirmed nominees, no election was necessary. 

Therefore, the 2021/2022 LDraw.org Steering Committee [1] is:

Gerald Lasser
Philippe Hurbain
Max Martin Richter
Orion Pobursky
Willy Tschager

[1] Try not to confuse the LDraw.org Steering Committee (SteerCo) with the LDraw.org Standards Board (LSB). The Steering Committee sets the course for the LDraw Organization while the Standards Board deals with the LDraw File Format.

Congratulations to the reconfirmed and new members!

Willy Tschager
On behalf of the LDraw.org Steering Committee

Hi,
Creating part using subparts is a great fundamental thing in the LDraw library. However, I found that there might be a little room for improvement with respect to subpart naming.

The `snn` suffix custom incremental naming is a good starting point, but when I looked at parts and their patterned versions, I found there is quite some ambiguity. This makes reusing existing subparts sometimes difficult and even impossible (e.g. when a subpart includes a part of the patterned area).

My suggestion would be to include a best practice where subparts have naming according to their place and/or orientation of the shapes.

Note: for the basic bricks and tiles this might not be needed, since these are mostly built up with primitives anyway.

But take, for example, the door part 92262. It generally has two sides where stickers or patterning could be applied (the front and the back). So these subparts of the model should be separated to provide an easy way to make patterned versions of this part. However, in this case, a small part of the patterned area is included in the top surface of the door. There are multiple ways to correct this or create new subparts, so that's not the issue. The issue is creators of parts might forget about possible future patterning when they divide their part into subparts. This is a great chance for improvement.

Entering my suggestion for naming subparts of possibly patterned parts:

File name suffix - Description
`s01` - Subparts containing a main collection (e.g. mirrorable part)
`sfnn` - Subparts containing the front facing part of a model
`sbnn` - Subparts containing back facing parts
..etc (`u` for upward facing, `d` for downward facing, `l` and `r` for left and right facing)

Alternatively, 'though less meaningful, the practice could be to use`sNn`, where:
N =
1 for main subparts
2 for top facing
3 for bottom facing
4 for front facing
5 for back facing
6 for left facing
7 for right facing
8 for misc (e.g. handles or other unprintable details)

In this practice it is not needed to subpart all these orientations, only the significant ones for that part.

In the case of the door part above, only top, bottom, front and back subparts would be needed. Since top and bottom are always the same within a part variation and only the front and back might have patterned versions to swap in.

To be clear, this would be a best practice and not a restriction. But including it in documentation might encourage more modular subparting with patterns in mind.

What do you think?

This will bring us a whole bunch of new patterned tiles. way beyond the 37 that we can accommodate in a given theme. Looks like it will go along the lines of the Nexo Knight Tiles, so shall we adapt a similar numbering, i.e. 3068bpv000? I am not sure if 00 would be enough for a hundred tiles.

Part 73682 is the corner variant of 70681, Slope Brick Curved  1 x  3 with  1 x  2 Inverted Cutout

How shall we call this one?
   

Hello,

there are parts that use more than one colour, e.g. the "MANTLE FOR MINI FIGURE", Lego number 6063290 (design: 50231)
This coat has two different colours (new dark red, medium lilac) on the front and back.
Only one colour can currently be used.
Are you planning to adjust the LDraw specification?
The current solution that I see is that the representation consists of two parts shifted into one another with different colors.
Or a special version would have to be created.


Greeting

Manfred

For anyone who uses Sublime Text 3 for editing LDraw files:

LDraw file syntax highlighting in Sublime Text 3

   

NOTE: Not all header statements and meta commands are included yet. I might add them later.

Feel free to send improvements/tips/suggestions at the Github repo.

Hi all,

there was this post on the Studio forum about rendering errors in POV-Ray.  I’ve a déjà vu feeling with these errors.

Studio uses LDView’s code to export to POV-Ray and also uses LGEO for the exported 3D models.

I checked for 608p03: Studio’s .inc is the same I have from LGEO (which I believe is up-to-date, it’s been a while I have used it but, if I’m not mistaken, the last updates are “only” Darat’s high-def ones).

So I think it’s an error in LGEO… or it maybe something in the POV-Ray code/options but then I don’t see what it could be.

Does that ring a bell to anyone?