I'm just starting with LDCad, and so far I'm loving. But I'm having trouble trying to manage groups. I can create them and move them and rotate them, but when I want to group together sub groups, then things get messy. Once I group groups together, I can no longer find a way to select the sub groups. All that I can select is the main top-level group. If I remove the top level group, then I can access the individual groups again. However, I can no longer access the top level group unless I regroup all the groups again. This is not ideal especially when working with large models. Also, if I hover over a group, I can see in the bottom a group name like "Group 1" etc... but cannot find where I can edit that to name the groups. Surely, I must be doing something wrong?

Can someone help me figure out how to manage all these groups?

P.S I know about Group Layers, but this isn't what I'm looking for. If I group together a bunch of groups, I should be able to move / rotate that top level group, then also be able to select a sub group from a list or tree and rotate just that part too. Is there a way to do that?

Thanks!

Guys,

in response to this post:

https://forums.ldraw.org/thread-24732.html

the majority of the SteerCo is in favour to add helper parts to the library but before a final vote we would like you to define a standard for these parts such as:

Naming convention
Category
Edges Yes/No on 2D helpers
Edges Yes/No on 3D helpers

The general idea would be to add these to the main library as the separate Alias and Physical parts library hasn't worked very well. In addition these parts shouldn't go through the PT for certification but be usable in all editors. Any input from your side is welcome.

Some example of helpers can be found here:

http://www.holly-wood.it/ldraw/helper-en.html

w.

Hello,I was repairing my crappy 15068px0  when I noticed that there are gaps in this part.

The subfiles don't match at the vertices 20 -4 -20, -20 -4 -20, -20 -16 20 and 20 -16 20 (aka the top corners) the 48\1-8cyli.dat don't match the s01, and inside the s01, the 48\1-8chrd.dat don't match the top corner either.

1 1 -20 24.9719 20 0 1 0 -40.97 0 0 0 0 -56.57 48\1-8chrd.dat
1 2 20 25 20 0 -1 0 -40.97 0 0 0 0 -56.57 48\1-8chrd.dat
1 4 20 24.972 20 0 -40 0 -28.9719 0 -28.9719 -40 0 40 48\1-8cyli.dat

I didn't check all the printed parts, but the problem is present on p01 for instance.

Should this part been reworked or should it be left like that ?

Please vote on adding the following clarifications to the LDraw.org Official Parts Library Specifications. The quoted text would be added verbatim.


Clarification to Sticker Geometry:

Quote:For stickers printed on a transparent medium, the type 1, 3, and 4 lines that comprise the pattern shall be preceded by a 0 BFC NOCLIP statement. If there is non-pattern geometry after the pattern geometry, the pattern geometry shall be ended by a 0 BFC CLIP statement.

The sticker should be oriented such that the top of the pattern aligns with the +Z axis. Exceptions to this rule may be made on a case by case basis.

Quote:All stickers and sticker shortcuts should, at a minimum, include at least one !KEYWORDS entry in the form of Set <set number> where <set number> is the number of an official LEGO set in which that sticker appears. Only one set need be listed, but more may be if desired.

Since !DATA was added to the MPD spec, it turns out to be quite hard to track down. If you look at the Documentation page, it isn't mentioned, so unless you know in advance that it is in the MPD spec, it's hidden. (And since "data" is so generic, a Google search for LDraw data doesn't even include the MPD spec on the first page of results.)

I would suggest adding a parenthetical to the MPD link indicating that !DATA is included there.

I made a dae file of a Bionicle MOC I had made on Stud.io. It does not show up on LDraw when I try to import it but instead crashes it. Is there any reason for that? I want to turn my MOC into a 3D model but I don't know if I can because it keep crashing LDraw. Any help you can give?

Attached Files

Thumbnail(s)
   

Hi,

I am rendering Lego parts using Blender and https://github.com/TobyLobster/ImportLDraw (using "p" "48" ldraw geometries).
Some of the very basic and simple parts take forever to render, and other parts contain artefacts.
Is there a good place to raise a list of parts that are unnecessarily complex or that display render artefacts?

Examples of parts that render extremely slowly (20x slower than complex parts), some of which are the most basic bricks and plates.

2419
2445
2454a
2456
2730
3001
3006
3007
3020
3027
3030
3031
3032
3034
3035
3036
32525
3297
3702
3738
3832
3857
3865
3867
3895
3958
4204
4510
60479
6111
6112
6179
91405
92438

Examples of bricks with artefacts:

• many domed bricks
  
• some bricks that have clearly been assembled from subparts with noticeable gaps/ discontinuities
  

Hi. I'm an occasional visitor to this site; pardon me if this question has been addressed elsewhere. I can't find it. I've just started to figure out how to use the keyboard entry method of positioning a part as well as how to set a custom rotation point. (It took me a while to figure out that the Rotation Point tool is universal and not specific to the part! Oh well. I can deal with that.   )

There seem to be three preset grid settings. I might have the angles wrong but let's say they correspond to 90, 45, and 30 degrees. Is there a way to rotate a part to any angle I choose?

Just wondering... I have some custom part files and I have added connectivity and conflict information in Stud.io by using part designer. Is there any way I could import that connectivity of these custom parts but in LDCad? 

Any help would be appreciated.

It seems more common now that different SKU numbers are used for sticker sheets in US sets vs. RoW sets.

For example, these two appear equivalent:
134071A / 24744 / 6142623 at Bricklink: https://www.bricklink.com/v2/catalog/cat...75870stk01
140413A / 24743 / 6142622 at Brickowl: https://www.brickowl.com/catalog/lego-st...4743-24744

Should we create aliases for all 23 stickers 6142623a => 6142622a, etc., or is this overkill? How else might a user know that the stickers for 6142623 already exist in the library as 6142622?

We have done this for older stickers where the design appears on multiple sheets, e.g. 003437b.dat => 003340a.dat.