What you think about creating LDraw-based addons for free games?
For example, I could recommend create LDraw-based (using free MOCs, without official LEGO sets or any copyrighted MOCs) addons for next free games (or recommend other):
SuperTuxKart - free & open-source cross-platform 3D racing game (for Linux, Windows, Mac OS, Android and other)
YSFlight - freeware 3D flight simulator, but not limited to flight simulation only (for Linux, Windows and Mac OS)
As for SuperTuxKart 0.6 there was LEGO-like addon:
Addons for SuperTuxKart and YSFlight could be created using Blender (with some Blender addons). And LDraw parts/models could be imported to Blender, so Blender is recommended for such LDraw-based game addons creating.
I am using MLCad to build train with a longer train baseplate. Though I can use small scale to create instructions, but I am not sure how to scale down baseplate in BOM.
Can I create two pages of BOM? Or can I hide baseplate in BOM? I tried to set baseplate as ghost in MLCad but it doesn't work, what can I do?
When uploading sets to BrickHub.org, it now checks for OMR compliance, and in some cases, can fix errors directly on the site. here is a video showing how to use it. The checks and fixes are currently implemented in this Javascript file: LDROMR.js and are:
Check and fix file headers so they read "0 FILE <set number> - <name>.ldr" then "0 <description>", followed by "0 Name:<set number> - <name>.ldr".
Ensure the file name is "<set number> - <name>.mpd" with optional qualifiers starting from "-1" (See discussion below)
Check and fix moved parts: If a part is named "~Moved <name>" then replace its usages with "<name>.dat"
Check and fix placements: If a large number of parts are placed with more than three decimals in the position or rotation, then round the placement to three decimals. Example: "1 16 0.0001 0 0 ..." becomes "1 16 0 0 0 ...".
Check and fix all author lines: Ensure all authors are the same and read "!Author Name [username]"
Check and fix all license lines to read "Redistributable under CCAL version 2.0 : see CAreadme.txt"
Set all "0 LDRAW_ORG" lines to read either "Model" or "Unofficial_Model".
Set the "0 LDRAW_ORG Unofficial_Part" in all unofficial parts of the file.
Ensure all unofficial parts are copied into the MPD file and named with the set number prefix in the "0 FILE" and "0 Name:" lines.
If the set is from 2007 or after and contains old colors (6, 7, or 8), then replace them with the newer colored parts.
If the set is from before 2007 and contains new colors (70, 71, or 72), then replace them with the old colored parts.
Inline textured parts according to the non-finalized spec.
Substitute parts that have been replaced by LEGO. As an example, 2470 replaced 4459 in 1990, so the parts will be checked against the year.
Verify that "Theme" lines correctly identify a theme.
Verify that "History" lines are well formed.
Verify that "History" lines are in the correct order.
Check that tyres are colored 256 instead of 0.
The purpose of this work is to make it even easier to submit OMR-compliant model file - especially for people who are not using Windows, so they can't easily use MPDCenter.
I do not expect that I have found all OMR checks, and some of my checks might even be erroneous. This is why I am creating this thread. Let's discuss OMR checks and fixes
Currently, I am trying my best to create the stickers for set 10266 (Apollo 11 Lunar Lander).
I do this to learn to work with LDPC and LDPE :-)
Since I do not own the model (yet) I can only judge online pictures and reviews, but it is my opinion that the edges are round.
Do we need to mimic this or would sharp (straight) edge be good too?
Currently, some stickers have this feature in the official library.
I could be mistaken, but I think most stickers in the newer sets nowadays have rounded edges whereas in the past most stickers had straight edges?
If they must be round, would it be an idea to create a submodel for the bottom box, since a sticker is, in fact, a box that is 0,25 LDU thick?
Attached is my first attempt at sticker nr. 5 of this set.
Also, what would be the part number for the sticker or how do we name it?
the trainbase plate 92088 (used in all train sets since 2010) has wrongly positioned square holes. The holes have a strange little offset to the middle, so it is impossible to stick plates to the bottom (see screenshot in attachment). The holes should be centered to the red plates you see in the screenshot.
So it is impossible to rebuld sets like 60198 because you have stick a plate 4 x 8 to the bottom.
Hi, I’m new to the forum! I’m mainly a digital Lego builder, with a soft spot for real space and sci-fi models. I’ve been a long-time dabbler with Lego Digital Designer, using LDraw to format models for instruction manuals and recently exploring Mecabricks and Blender for rendering. However, since Lego has confirmed that LDD will not be updated to run on MacOS Catalina (which is dropping support for 32-bit apps) and I haven’t found any alternative Mac editors that I feel comfortable using, I’m seriously looking at the possibility of creating my own Lego CAD program - a native MacOS app, coded in Swift, using the Metal 3D graphics framework.
I’ve never actually coded for the Mac before, so I am not sure how far I will get with this. But I used to play with the Dark Basic programming language and some low-level DirectX 9 commands, so I know the basics of high-level 3D object manipulation, and my day job is partly spent writing C++ programs. Would there be room for another LDraw editor in the community, any interest in having something for the Mac?
I also had a few questions after reading up on the LDraw file format. Please, please don’t take these as criticisms of the library, or think that I am asking/suggesting that anything should be changed, I am only asking to try and get a deeper understanding of how the format works.
Why do you use a right-handed coordinate system, with negative y straight up? The two main conventions are +x to the right, +y upwards, and +z either into or out of the screen (for left or right handed). So why was this one chosen?
Each brick in the library is constructed from a series of recursive primitives, so what’s the best way to manage a brick in a program? Do you consider the brick as an object with multiple child limbs (with the limb structure preserving the LDraw primitive file hierarchy)? Or is it better to combine the geometry data of all of the primitives into a single 3D mesh? And has anyone ever pursued the LDD approach of hiding studs and anti-studs once they are connected, to reduce the scene poly-count?
None of the bricks contain normal data for the vertices, so how do you go about computing this? I mean, I know it’s a vector cross-product for each triangle, but how do you work out if an edge should be a hard edge (like for sides of a 2x4 brick) or a soft edge (like the rounded surface of a minifig head)? How do you go about searching the vertex data for shared edges? (And out of historical curiosity, why wasn’t the LDraw library designed to include the normal data? Was the original intention to use flat shading only?)
What is the importance of the back-face culling commands in the file format? Polygons can be rendered as single or double sided, but single sided is the default for performance reasons, and polygons facing away from the camera can be automatically culled by the 3D render engine. So why does this need to be such a major part of the file format specification? Is this used to help determine which way a normal vector should point when creating a triangle?
For the ROTSTEP command, why does it specify three Euler angles for the rotation instead of a quaternion? And what’s the rotation order (x,y,z, z,y,x, …)? Also, am I correct in assuming that REL and ABS denote use of perspective or orthographic rendering modes?
When defining parts in a model, the file format specifies x,y,z positions then a 3x3 rotation matrix. Why isn’t a full 4x4 matrix used, so that all position, scale, rotation information could be encoded in one structure?
From looking at the Bricksmith editor, steps seem to have a default rotation of x,y,z = 31,41,21 degrees. Why is this angle chosen, does the default ever vary from program to program?
Again, please don’t take any of these questions as criticisms of the LDraw format, I really am just trying to understand how the file format has evolved and how it works currently.
Oh, and sorry for such a huge first post, it’s turned out way longer than I expected!
I'm sure I missed some sort of relevant discussion but why are the top edges rounded on the 1x1 round tile but nowhere else? It seems to me that these edges should be sharp just like every other part.
![[Image: fh4-lego-render-1.jpeg?itok=isYRhcX7]](https://www.windowscentral.com/sites/wpcentral.com/files/styles/large/public/field/image/2019/06/fh4-lego-render-1.jpeg?itok=isYRhcX7)
