Thinking again about this post (from Philo) about Studio:

(2024-06-21, 8:24)Philippe Hurbain Wrote: Is it possible to create an MPD embedding ALL official and unofficial parts? My use case is to render (or create BIs)  a model with Studio without fiddling with all part incompatibilities, libraries not in sync causing missing subparts and so on...
The complete scenario would be to embed all parts, add a prefix to avoid any conflict with existing Studio parts, extract these parts from MPD with MPDwizard, and place them in Studio CustomParts folder. After that, the model _should_ import flawlessly in Studio.

Hi, I'm trying to create a Christmas themed build using studio and I'm missing part number 1622pb01 (bricklink)
https://www.bricklink.com/v2/catalog/cat...&idColor=3
The combined hat/hair piece that the holiday elf is wearing in collectable minifigure series 23.


  1622pb01.png (Size: 209.63 KB / Downloads: 78)

I would appreciate it if someone could author it and add it to the parts library. You might be able to use the already existing elf hat and ears (in the parts library) and just add the hair, but I don't know. I think its quite a difficult part to create and I don't have any experience with this.

Thank you,
Kay

  4121723c.png (Size: 332.78 KB / Downloads: 45)
As you can see, even LEGO was too lazy and didnt use a curved sticker in the instructions...
Parts are 4121723c.dat (and 4121723d.dat on the other side)
Do we need that curvature? it goes partially on 6081/6091.

Hi,

I have a CSV with list of parts. I imported the CSV to LeoCAD, Stud.io. LDCad but as I didnt use any x y z reference all pieces are in the same coordinate.

Is there a way in any of the programs to select all pieces and automatically arrange separated one from other?

Thanks!

The present LDraw library is divided into primitives, subparts, and parts. Each part can be assigned to a category and have zero or more keywords to aid searching. However, there is not yet any coherent structure for organizing similar parts.

Patterned versions of parts are primarily identified by a part number extension, while distinct underside reinforcements may be indicated with a letter (a, b, c...), a different part number, or some other extension to the part number. How would a prospective digital builder known which version to use without getting lost in the jungle of similar parts?

I propose using an ontology where the different versions of a brick are organized in a hierarchical manner. It could for example be possible to define a 'generic' brick and all its known variants of underside reinforcements in a consistent manner. This ontology could then be used to filter the library to produce different official subsets of the library for different stakeholders.


Reusing dat files is an efficient way of constructing complex structures out of modular subunits while maintaining editability on all levels without redundancy. However, each additional subpart requires its own review and approval on the parts tracker before becoming eligible for inclusion into the library. The low number of part reviewers effectively limit the realistic number of subunits of a part, thus hindering adequate reuse of subunits in different bricks. Consequentially, subunits tend to be large and highly specialized, thus of little use in other parts. Additionally, I would prefer having access to box primitives where the origin is at the end of the box rather than the middle and understud primitives with the origin at the bottom end of the primitive rather than the top to simplify scaling and placement.

The above can be achieved in at least two approaches; 1. allowing subparts within a file and 2. by expanding the 'primitives' library with structures that are repeatedly constructed in part after part. Examples of the latter include boxjcyl, a halfway truncated stud8, and all-edge versions of some boxes.

Solution 1 would enable more consistent parts as modular intermediates can be constructed in a "for this part only" manner. Solution 2 would enable more broader reuse of modular subparts. Neither excluding the other.


I would also prefer more standardized naming of parts, consistent part orientation, regularized primitive sizes, and circular segments other than those starting from a 0 or 90 degree angle.

Thread for 1997 Technic models

6020 Magic Shop (1993)

  6020 - Magic Shop.mpd (Size: 3.76 KB / Downloads: 2)
   

First model upload - MPDCenter claims it's OMR compliant, not sure if it's true.
Missing items: none

Ich habe eine Frage an Sie, weiß jemand, wie man die Teile zur Bibliothek der neuen Teile hinzufügt. Denn ich habe es immer wieder versucht, aber irgendwie funktioniert es nicht. Muss ich auf etwas oder etwas achten. Denn im LDraw.org habe ich neue Teile, die ich gerne hinzufügen würde, aber irgendwie funktioniert es nicht. ...

I'm working on part 35965 and it has an underside periferal wall of thickness 4 LDU and multiple perpendicular branches. At worst, the 4 LDU side branch is 160 LDU away from the corner, thus making the sharp angle 0.0349 degrees (0.0006 radians). This is larger than the minimum angle of 0.025 degrees specified in the official requirements, but it is really long and narrow triangle!

How accurate/tested is this minimum specification?

What makes something work having the 4 LDU side branch up to 189 LDU away from the corner, but suddenly stops working at 190 LDU from the corner?

Can I as a part author choose to allow T-junctions when the sharp angle is less than 1.43 degrees? This corresponds to a 4 LDU high object 160 LDU away from the corner. Interestingly, that angle is 0.025 radians!

Hi, there’s a problem with the decor on this part: some triangles are in White instead of 16, adding a square in the $.



(Sorry, I’m confused with the procedure to correct recent parts….  And the forum doesn’t seem to like my image.)