Welcome, Guest
You have to register before you can post on our site.



Search Forums

(Advanced Search)

Forum Statistics
» Members: 1,426
» Latest member: greenycomet
» Forum threads: 3,980
» Forum posts: 34,668

Full Statistics

Online Users
There are currently 34 online users.
» 2 Member(s) | 29 Guest(s)
Applebot, Bing, Google, Max Martin Richter, N. W. Perry

Latest Threads
Lego Description Language...
Forum: General LDraw.org Discussion
Last Post: SNIPE
8 hours ago
» Replies: 2
» Views: 182
Technic 1992
Forum: Official Models
Last Post: Max Martin Richter
8 hours ago
» Replies: 24
» Views: 5,062
Official Library File For...
Forum: Official File Specifications/Standards
Last Post: N. W. Perry
9 hours ago
» Replies: 26
» Views: 624
LDraw.org Part Numbering ...
Forum: Official File Specifications/Standards
Last Post: Magnus Forsberg
11 hours ago
» Replies: 8
» Views: 579
LEGO Dimensions
Forum: Official Models
Last Post: Evert-Jan Boer
11 hours ago
» Replies: 0
» Views: 237
75275 - A-Wing Starfighte...
Forum: Official Models
Last Post: Evert-Jan Boer
11 hours ago
» Replies: 2
» Views: 258
49533, Windscreen 3 x 6 x...
Forum: Part Requests
Last Post: N. W. Perry
Yesterday, 16:54
» Replies: 8
» Views: 2,331
Architecture Theme
Forum: Official Models
Last Post: Orion Pobursky
Yesterday, 15:19
» Replies: 145
» Views: 111,016
Tile 1 x 2 with US Flag
Forum: Part Requests
Last Post: Orion Pobursky
Yesterday, 5:44
» Replies: 3
» Views: 166
20551 - LEGO Minifigure, ...
Forum: Part Requests
Last Post: Orion Pobursky
2020-06-04, 21:56
» Replies: 6
» Views: 575

  Stud color with transparency
Posted by: Leonardo Gonzalez - 2020-05-26, 17:28 - Forum: Rendering Techniques - No Replies

Following the suggestion on this thread of using fade_color:

POV-Ray: Transparency using fade_color

and after plenty of tweaking and testing, I have found a fairly satisfactory solution to transparent colors that approach the real thing. The scene in POV-Ray is setup with an area light and a white square floating above to simulate a studio lamp reflection. The part used is: 92579.dat, in Transparent Black (LDXColor40).

Here is the default values with dark and light surface as background:


It is hard to see the internal edges or the surface through the transparency. Compare that to the fade_color version:


As you can see, the part is well defined and the edges are darker than the walls (as it should be), it works on both light and dark surfaces and allows you to see what is on the other side of the part. The only downside to using fade_color is that the studs are no longer colorize and appear simply as transparent. This seems to be due to the part not having an LGEO substitution.

My question to you good people is: Is there a way to apply this fade_color technique onto the studs so that they have the same color as the part itself, even without an LGEO substitution? I am not familiar with the whole Ldraw format, so any light you can cast my way (no pun intended) will be greatly appreciated.

If you would like to test the technique for yourself, here is the fade_color modification that I settled on:

// KOYAN                     <85,79,68>
// LDRAW                     <99,95,82>
// LDRAW (DARKER)            <74,71,62>
// LEGO DIGITAL DESIGNER     <166,145,130>
// PEERON                    <191,183,177>
// CUSTOM                    <77,51,25> [http://www.flickr.com/photos/mtbin/5435835970/]
/*#declare lg_clear_brown = texture {
  pigment { color srgb <166,145,130>/255  // LEGO DIGITAL DESIGNER
  #if (lg_quality > 1)
    filter TransFilter  //TransFilter  //0.5  //0.7
    transmit TransTransmit    //TransTransmit  //0.6   //0.3
  finish  { lg_transparent_finish }
} */


#ifndef (LDXColor40)
#declare LDXColor40 = material {
    texture {
      pigment {color srgb <166,145,130>/500       transmit 0.99        filter 0      }
      finish  { lg_transparent_finish   emission 0} //srgb <166,145,130>/127.5 }
      normal  { lg_transparent_normal }
    interior {
      ior 1.6
      fade_color srgb <166,145,130>/255
      fade_distance 1
      fade_power 2

You may simply add the code block after "//COLOR TEST..." to your lg_color.inc file below the "// 40 Transparent Black..." block. Remember to comment out /* */ the initial part to keep it as backup. You can use this as a template for other transparent colors too. This does not seem to improve the neon transparent colors though, but I haven't played with those much yet.

**IMPORTANT NOTE** Certain issues may arrive from using this code as I have not been able to go through all the dependent files and code, specifically a known issue is with transparent slopes which will halt the rendering.

Print this item

  Lua scripting
Posted by: Moreau - 2020-05-26, 2:56 - Forum: Rendering Techniques - Replies (1)

This will, I hope, become a discussion for the topic of scripting in Lua programming language. Generally for sharing animations, macros, and the language itself.
There are a few specific conversations on this topic in various other places on the forum, and it would benefit everyone to have a more centralized board to share compare and learn from each other.

with the up-coming 1.7 update this should become a hot thread.

I'll start things off. There are sample scripts available from the scripts menu, and they are open-source, so you can read them and edit them. One of these is the "camera test" which led me to ask if there was a way to lead a camera in animation along a designated path through a model. A sort of walking tour which Roland made for us to play with" https://forums.ldraw.org/thread-23778.html ".

Print this item

  75275 - A-Wing Starfighter UCS
Posted by: Evert-Jan Boer - 2020-05-25, 11:20 - Forum: Official Models - Replies (2)

[Image: A-wing.png]

Missing: Minifig (Spec sticker does not render, texmap)

Uploaded model, not OMR compliant (did not add unoffical parts to the file)

Attached Files
.mpd   75275 - A-Wing Starfighter UCS.mpd (Size: 105.41 KB / Downloads: 3)
Print this item

  Part requests: 95401, 95404pb01 & bb0534
Posted by: Zoltan - 2020-05-25, 11:13 - Forum: Part Requests - Replies (2)

I'm currently making the minifigures for my Flying Dutchman MOC and I noticed that the parts 95401 (Davy Jones' tentacle beard), 95404pb01 (Maccus' hammerhead shark headpiece), and bb0534 (Hand Crab Pincer) don't exist as LDRAW parts...would anyone be interested to take up the challenge? Many thanks

.png   95401_1.png (Size: 113.55 KB / Downloads: 24)            
.png   95404pb01_1.png (Size: 56.41 KB / Downloads: 24)        
.png   bb0534.png (Size: 55.91 KB / Downloads: 25)

Print this item

  Tile 1 x 1, new variant?
Posted by: Gerald Lasser - 2020-05-25, 7:52 - Forum: Parts Authoring - Replies (4)

I just stumbled across this picture on the German Dr. Brick Forum. This is a tile that came with the new Bookshop building. Anybody else noticed this slight re-design of the Tile?

Print this item

  65753 trolls skirt
Posted by: SNIPE - 2020-05-23, 7:22 - Forum: Part Requests - Replies (4)


can we get this part (65753):
[Image: LEGO-parts-review_Trolls%2B%252816%2529.jpg]
image source: http://www.newelementary.com/2020/04/leg...parts.html

it is good for brickwork and as a 1x2 tile with stud/axle holes.

eg: I wanna use it to fill this gap using 3111.dat tubes for upside down SNOT thought it doesn't come in black yet

[Image: 640x657.jpg]


Print this item

  Instruction making rant
Posted by: Daniel R - 2020-05-22, 23:30 - Forum: LDraw File Processing and Conversion - Replies (66)

I made two instruction for reasonably complex (but not even too big) Technic models, and the process is needlessly painful. So I have a couple of questions and a rant about the future of instruction making software. This is a completely newbie post, so I hope it does not sound too offensive. As English is not my native language it is a little hard for me to write criticism correctly, but I do recognize the seniority of the forum members about these matters. I certainly do not know much about the whole Ldraw software, so I would gladly read explanation why things are done the way they are done. Also some of my nitpicks may be explained by me failing to find some features.


  1. Is there a way to use buffer exchange without pain? How do you insert the BUFXCHG line? I know that you can insert it by dragging it from LDCad part bin (which usually inserts it in a wrong place) or write it manually in the source (which requires to reload the model). What is worse, if you apply buffer exchange to a submodel, you have to copy and flatten the whole submodel later (and also ignore it in PLI).
  2. What is the relation between Studio part library and LDraw? Do they just copy it or do they contribute something?
  3. Is there a way to show model from different angle easily? Currently the only way I know is copy the whole model as a subfile, ignore all the parts in the subfile and display it as a callout without arrows. This does not scale well: suppose you have to change something in the beginning of the model, then you'll have to change all the copies too.

In my opinion, if we want to keep anyone use open software and not Studio (which is also somewhat slow, buggy, closed-source and uses proprietary format), LPub3D and LDCad should be way better. My feeling is that now all new users come to Studio, as it is actually usable.

LDCad is really great, it works very fast, even with huge models and on weak computers, its GUI is really effective and documentation is good. I have only minor nitpicks about it:
  • You can't pin compass window. I don't really need the whole compass, it is too big anyway. But I do need the the ASR/NSR switch because if ASR is enabled you can lose current orientation by switching steps, so I constantly check the switch.
  • You need to go to the outer submodel to check the flexible part length
  • Flexible nets are not supported
  • I know you can make part bin with colors (even with counts, that is very cool, much faster than Studio), but it would be useful to quickly change color bin selection to only physically available colors for the part. Maybe even make such mode default, but quickly switchable to current mode.
At the same time, LPub3D experience is terrible, some of that is due to the current implementation and some is due to general design choices (IMHO).
The worst thing is speed. It usually take more than a full minute to render an new page after the next button click. Than is on a decent hardware IMO (quad-core i7-8650U, NVMe storage, more than enough RAM). "Convert to callout" can take several minutes, and even right mouse click can take several seconds to actually show the menu. LDCad is capable of displaying models in real time with reasonably high FPS, so that is definitely possible.

The whole thing is buggy, it crashes regularly, once it deleted a whole subfile. There are a lot of minor bugs in the current implementation, to name a few:
  • Part annotations do not show in callouts
  • Output depends on platform and environment
  • Incorrect BOM with REMOVE GROUP
  • BOM looks terrible compared to official ones (I tried many sorting options, it all looks wrong and unreadable)
  • Export to rebrickable and bricklink works not flawlessly
  • LPub crops images with small camera distance, so it is not possible to pan to specific part of a model
  • LPub inserts another submodel preview on every page of multi-page submodel if the page is a multi-step
  • Part annotations are only inserted once per part
  • Submodel-level colors work not quite the same way as they do in the official manuals
The whole LPub3D automatic layout and margin management is hard to use. Even small movement makes several elements to change position, so it is very hard to place elements, especially with enormous redraw times. I end up using absolute (page) position. The whole relative element placement is very frustrating, it is hard to control.

LPub multi-step layout and margins look very wrong (compare https://imgur.com/5DYF5Cx and https://i.imgur.com/kYRTVWf)

Lack of full spec does not help (https://trevorsandy.github.io/lpub3d/ass...mands.html is partially incorrect)

I believe if I had such problems with LPub it is hard to maintain so big thanks to Trevor for doing this. I opened several issues and made some minimal contributions on the Github and Trevor provided very quick answers and edits. But I spent some time even figuring out how to build it to make minimal changes to the code. I think simpler build process and more instructions would be helpful.


As for the future of LPub and LDCad, I have some thoughts about features which would make the process easier and make some competition with Studio possible.

LPub3D default settings should follow current Lego visual language (colors, fonts, margins, rotation icon look, BOM sorting order, line width, which parts use annotations and which don't). The default output should look like 42111 instruction, not like some adhoc script output.

LDCad, preferably, should have ability to store zoom and pan steps and display them in same way in does with ROTSTEPs

Rotation icon should be inserted automatically if the next step is a ROTSTEP (with an option to suppress this default)

I'd like to make callouts with complex shape (see https://imgur.com/ixTDV8b) and more complex callout arrows (https://imgur.com/41eIKeo) easier. Also it would be nice to allow to have submodel last step and its application on same page with a divider, (see https://imgur.com/QGdf5kb)

Maybe subfile header should include part substitution info. As usually you don't need the whole flexibility of PLI BEGIN SUB, as you don't replace arbitrary subsets of a model with arbitrary parts, you only need to replace a submodel with bent part with it's original state. Moreover, even if the said submodel is used multiple times, it is always replaced with the same part. I know that LDCad has partName and partDescr metas (which are not used anyway), but this could also be used with universal joints, shock absorbers, hinges and other parts.

Both current possibilities to change assembled model, BUFEXCHG and REMOVE GROUP are hard to use (unless I am missing something) and limiting. Official instruction use them all the time, see the beginning of 42082 manual (https://imgur.com/jgzpMnd), it is quite time consuming to replicate such steps. Also sometimes you need to rotate parts of a model, move pins or connect cables or tubes. I don't have any ideas of a new syntax for this. Maybe the problem is that the current mechanism is too generic, as you really don't replace random parts with some other random parts, you only substitute the same parts with different positions, and you very rarely need to actually remove parts. I'm not saying saying it shouldn't be supported though

LDCad should have arrow generator, similar to current path generator, so that such arrows (https://imgur.com/bOJdK71) could be made easily.
Generally, there should be two kinds of arrows, "real arrows" and "sprite arrows" (I am not sure whether it is a correct name).
Real arrows should be parts, maintained and distributed officially by LDraw. As LDraw aims to make an official Lego part library with all (and only) official parts produced by Lego, it is reasonable to also maintain official design elements. Instruction designers will have a unified set of them, so they don't have to ship their custom arrows with the instruction. Big yellow arrows used to move parts of a model (https://imgur.com/D6iyDpb) should also be included as parts. Highlighting frames and circles such as https://imgur.com/Ag5Te9E could also be included.
Sprite arrows should be generated by LDCad (they could be straight, maybe aligned to relative grid or curved, exactly the same as paths like cables and tubes) and rendered by LPub in such way that the arrow always faces the camera and always has the same width.

Print this item

  Clone helmet piece
Posted by: Jesse Voncken - 2020-05-22, 9:02 - Forum: Part Requests - No Replies


I was wondering if someone could make this part

It would be really appreciated


Print this item

  Call for votes: Add !DATA to MPD spec
Posted by: Travis Cobbs - 2020-05-21, 4:32 - Forum: Standards Board - Replies (10)

Note: I directly copied this from Roland's post.

Please vote for the following update to the MPD spec that allows for binary data to be included in an MPD file.


MPD files or "Multi-Part Documents" are a way to combine several LDraw and encoded binary files into one consolidated source. This allows for ease in posting or emailing a model made up of many subparts.

A MPD file consists out of blocks of LDraw code separated by 0 FILE or 0 !DATA statements. Each block is considered a separate file and can be referenced by the other ones as needed.

Blocks starting with the 0 FILE statement are normal type 0..5 line LDraw code.

Blocks starting with the 0 !DATA statement contain binary data encoded using a multitude of 0 !: lines. Each of those lines contain a chunk of base64 encoded data which a parser must combine before decoding. No other LDraw statements may be used inside a !DATA block.

The end of each block, or just the last block in the MPD, may be marked with a 0 NOFILE line. The 0 NOFILE command is only required if the file's contents are followed by non-LDraw content (such as the poster's signature lines). LDraw parsers must then ignore all content until a new 0 FILE or 0 !DATA is found.

In order to support the inclusion of MPD files in message systems (like email), any text lines before the first 0 FILE or 0 !DATA statement will be discarded. It is considered to be an error for any LDraw code (other than comment lines) to appear before the first 0 FILE or 0 !DATA statement.

The first block in the MPD is treated as the 'main model' -- all other files in the MPD will only be rendered if they are referenced by the main model, directly or indirectly. For this reason it is recommended (but not required) to always use a 0 FILE block as the first entry in the MPD.

So far, there are no clear scoping or namespace rules on MPD files. If you put a file named stud.dat in your MPD file, don't be surprised to see your stud.dat file appear on the top of every single brick in your scene.

MPD META Statements

Format: 0 FILE <filename>
<filename> is the name of the following LDraw file.

Format: 0 !DATA <filename>
<filename> is the filename of the following encoded data.

Format: 0 !: <base64 string>
<base64 string> is a chunk of the base64 encoded data (A-Za-z0-9+/) with a maximum length of 80 characters (60 bytes of data). Each line except the last should use the same length and be a multiple of 4 characters. Padding the last line with '=' characters to complete its last group of 4 is optional.

Format: 0 NOFILE
There are no options or parameters.


0 FILE main.ldr
1 7 0 0 0 1 0 0 0 1 0 0 0 1 819.dat
1 4 80 -8 70 1 0 0 0 1 0 0 0 1 house.ldr
1 4 -70 -8 20 0 0 -1 0 1 0 1 0 0 house.ldr
1 4 50 -8 -20 0 0 -1 0 1 0 1 0 0 house.ldr
1 4 0 -8 -30 1 0 0 0 1 0 0 0 1 house.ldr
1 4 -20 -8 70 1 0 0 0 1 0 0 0 1 house.ldr

0 FILE house.ldr
1 16 0 0 0 1 0 0 0 1 0 0 0 1 3023.dat
1 16 0 -24 0 1 0 0 0 1 0 0 0 1 3065.dat
1 16 0 -48 0 1 0 0 0 1 0 0 0 1 3065.dat
1 16 0 -72 0 0 0 -1 0 1 0 1 0 0 3044b.dat
1 4 0 -22 -10 1 0 0 0 0 -1 0 1 0 sticker.ldr

0 FILE sticker.ldr
1 16   0 -0.25 0   20 0 0   0 0.25 0   0 0 30   box5.dat
0 !TEXMAP START PLANAR   -20 -0.25 30   20 -0.25 30   -20 -0.25 -30   sticker.png
4 16   -20 -0.25 30   -20 -0.25 -30   20 -0.25 -30   20 -0.25 30

0 !DATA sticker.png
0 !: 1BQsQIsoYAt6NkAYxQV/JQ7WvfuKkFTR6UmOFJzR9bJLkXTlNwyD6QymM5ju5Tl8m67KGUt3XJcz
0 !: J/yY8HZ/6C8BFvNZPoaesMF0BtMZTGcwncF0BtMZTGcwncF0BtMZTGcwnf8t0bmLh85gOoPpDKYz
0 !: mM5gOoPpDKYzmM5gunDBf3tN+/zqNKt367cbOeGUTstxf1nJZHPOx68T/u3XB5/7/zMXLTqD6Qym
0 !: M5jOYDqD6QymM5jOYDqD6QymM5jOYDqD6QymM5jOYLpwwW3t8ajBXTxtTHgwLlp0BtMZTGcwncF0

Print this item

  Documentation Fragmentation
Posted by: Orion Pobursky - 2020-05-20, 20:43 - Forum: Official File Specifications/Standards - Replies (7)

I'm starting to think we have a documentation fragmentation problem. There are simply too many places to look for requirements, especially for parts authoring. What I'm not sure about is if this is a presentation problem or that we need to start consolidating documents. Thoughts?

Print this item