I'm curious how different people make use of submodels, and, for those editors that support them, groups? I've read about a few different methods, all of which seem valid; is there one that's preferred, or considered more "correct" or standard?

One method I've heard is that submodels should be used similar to subparts—that is, for assemblies within models that are used frequently, or have to be repeatable for some reason, in order to reduce file size. This makes sense, although one difference I can think of is that subparts are likely to be used in more than one part, but I don't know how often you'd find a submodel being used in more than one different model.

Another recommendation I've seen is that submodels should correspond to sub-assemblies that appear in building instructions, especially if they have their own building steps shown in a callout. And yet another is that submodels are useful for keeping assemblies together that might need to be hinged, rotated, or otherwise positioned as a group—in animation, for example, or just for posing the model.

And finally, I've seen a few models of official sets where the use of submodels seems to make no sense at all; maybe those builders are using a system I just don't understand yet!

As for myself, I like to build official sets, so I use submodels to correspond to sub-assemblies shown in the instructions, especially if they are used more than once, or have more than 3 building steps of their own. In Studio I used to also use them for groups of parts that need to move as a separate unit, but since switching over to LDCad, I use the Grouping feature for that. Any collection of parts that needs to be positionable as a group, but separately from the overall model, I assign to a Group in LDCad, and I use the different grouping layers for nesting these assemblies within each other, from smallest to largest. (For example, a tire/hub and its axle might be in Layer 1, then that group plus the steering arm that rotates with it would be Layer 2, and if that whole assembly also moves up and down in a suspension, it's Layer 3, etc. I figure this may come in handy when and if I ever figure out animation, or if kinematics become a reality some day…) And since groups in LDCad can be spread across different subfiles, I use the submodels only for different stages of the building process itself.

What are other builders' experiences?

Maybe it's just me, but I find PT rather sluggish recently...

Hey,

I have wonderful news for you if you are a developer and want to create your own version of LDPartEditor (LDPE).
It is now very easy to build and run LDPE.

The project on Github uses now the brand new Github Actions feature for build automation.
The build pipeline creates artifacts for Windows, Linux and Mac OS X and is triggered on push.

Here is an example run with build artifacts for every platform:
https://github.com/nilsschmidt1337/ldpar.../368914646

You can fork the repository on Github, modify the code, push the changes to your repository and the build pipeline will create a custom LDPE version just for you.

It is also possible to build LDPE on your own Linux machine. It requires a JDK 8 and Apache Ant 1.7 or later.
Just clone the forked repository and open a terminal to run

This is intended to be a catchall thread to let Roland know about missing/problematic part snapping info.

Note: make sure that the part you are reporting is official

I produced 2 patterned unofficial parts from 3857 "Baseplate 16 x 32 with Square Corners".
Stud orientation used are the same as the official files (parallele to the 16 studs edge).

Photo found on web for [color=#000000][color=#333333][color=#000000]patterned parts [/color][/color]show the same orientation.[/color]

   
Ok, it's not very clear but i don't find better.

   
But real not patterned parts I have, show an orientation of stud parallele to the 32 studs edge.
Do you think 2 versions [color=#000000][font=Arial]exist with 2 differents stud orientation, one for patterned, one for non patterned, or an old version with an orientation (1990's) and a new version with another orientation ?  [/font][/color]

HEY so I'm new to LDraw (and part authoring, of course), and I'm having a VERY tough time wrapping my head around texture mapping and subfiles. I'm an artist much more than a programmer, so everything's really confusing for me. It took me a couple days to even figure out how to recolor polygons.

My primary issue is that I've already made a PNG and an SVG version of a custom texture of a lego torso. Converting the PNG is simple, but it has this nasty white line around the outside that looks really bad, stemming from the anti-aliasing? It's passable on lighter colors, though. Using solid would fix the border issue, but if you zoom in it'd look pretty icky, I think, unless the image size was super high.

So I was wondering if any of you could explain to me how I could work around the issue of the ugly white borders, preferably without having to scrap the art I already made and start over from scratch.

I assumed using a vector was the right way to go, since vectors don't have anti-aliasing in the first place, but I quickly ran into the issue of how to actually apply it to the model. It's really easy to texture minifigs with the stud.io part editor, but for a reason that is unclear to me (I'm sure it's a real good one) the SVG wouldn't work. If there's another file type I could use, or something, that'd be amazing, but I'm really at a loss right now! Attached are the textures I made, if that would be of any help in figuring out the issue!!


As a side note: is it OK to post completely custom textures/models in the Ldraw unofficial parts list? (As in, parts that were designed by me, and not LEGO.)

Thank you so much for the help...!

Hej,
I got a request in the Ambassador Forum, if we can create the Minifig Tails: Link to Bricklink.
Of course this is a request of another ambassador and not from TLG. 

/Max

We have reached a new quality level of our parts library:
* EVERY official part is now BFC certified.
* there are NO unofficial parts on the PT which are not BFC certified

Here is the proof:
https://www.ldraw.org/cgi-bin/ptbfcstatus.cgi

This is another great milestone in the quality of our parts.

To keep this situation,
I would like to suggest to adjust the PT now to require that an uploaded file carries the statement
0 BFC CERTIFY
in its header, and to reject submittal otherwise.

Hi,

could someone please fix the legend at the bottom of the Parts Tracker Parts List?
https://www.ldraw.org/cgi-bin/ptlist.cgi

There, the letter "X" is explained, which nowadays was replaced by "N" (which I like a lot).

The 2019-03 LDraw Parts Update has been now been released. This adds 627 new files to the core library, including 474 new parts and 24 new primitives. Update versions of the colour definition files (LDConfig.ldr and LDCfgalt.ldr) are included in this release.

After discussion on this forum we have decided to stop releasing files representing LEGO part numbers for 'Physical_Colour' parts, as other automatically updated resources (such as BrickSet), provide a better source for this information. Included in this update are more re-issued versions of many of the 'Physical_Colour' parts as obsoleted files.

Thanks are due to all the part authors who created or corrected parts for this release. The small, but dedicated, band of reviewers also play an important role in keeping files moving through the Parts Tracker and deserve just as much credit. 

You can preview the new parts in 2019-03 here, and download the zip-file update or Windows install package here. Alternatively you can use the LDView menu option File | Check for Library Updates... to install the update.

There are still a significant number of 'problem' files which fail to meet our standards and have been left on the Parts Tracker, some for several years. As a reminder, if these have remained untouched by the original author for three months, they are considered 'fair game' for any author to correct. We would welcome any effort to reduce this backlog.

Due to other 'real-life' conflicts, the planned end-of-October update was not forthcoming, but I hope this third 2019 release is a welcome increase in throughput.