Abner Finley brought this Kickstarter to my attention:
https://www.kickstarter.com/projects/bri...ego-bricks

Looks interesting and exports LDraw models. Any of the team lurkers here?

Currently we're naming the torso shortcut with the same suffix as the torso (e.g. 973p02 -> 76382p01). As I've come up on torsos that are used more than once I've been using suffixes from obsolete torsos (e.g. 973p01 -> 76382p01 and 76382p11) or a suffix used by a different numbered shortcut (e.g. 973p1r -> 76382p1r and 76382p0v since 973p0v uses 16360, the dual mould arm shortcut). 

Since I want to ensure that all 973pXX(X) torsos have at least one torso shortcut with the same suffix, when we run out of these overlaps I don't want to simply use the first available suffix.

Therefore, I proposed that if there is no appropriate and available suffix to take, a torso shortcut will use the pNNNN suffix using the first unused number in sequence.

I have a question for you all—does anyone have experience with the LDPart Editor and know how to scale or edit parts? The program is set up so strangely that it's hard to understand where things are or how to edit parts. Does anyone have tutorials or a guide on how the LDPart Editor works?

Attached Files

Thumbnail(s)
   

Hi, I made a quick mocup of an upcoming part, it is simular to part 6091 but withot the 1x1 plate. or a 1x1 version of part 37352

I saw it in this post: https://www.newelementary.com/2024/11/ne...e-kid.html

Here is the file, I'm not sure how to add snapping information for the clutch without modifying the ldcad shadow library.


  1x1 curved brick.dat (Size: 1.21 KB / Downloads: 7)

There is also no know part ID for it yet.

Hello everyone,

I have been wondering of this part (3938) may require an update:

   

I guess the reason for not adding the little holes in the first place was the assumption they are similar to underside pin holes?

However I don't think this should apply here:
1) It is an easily visible area NOT underneath the part.
2) The holes probably have a connection point. They can connect to 2 LDU bars (helmet feathers and such), although I am not sure this was intentional.
3) Unlike bricks/plates with underside pins, this part never appeared without the holes.

This part always looked odd to me in renders, when the holes are missing - clearly marking it as a "non real" part.

What do you think?

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: 80)

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: 47)
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.