| Welcome, Guest |
You have to register before you can post on our site.
|
| Online Users |
There are currently 238 online users. » 0 Member(s) | 233 Guest(s) Applebot, Baidu, Bing, Google, Yandex
|
|
|
| New header METAs proposal |
|
Posted by: Orion Pobursky - 2025-08-07, 21:04 - Forum: Official File Specifications/Standards
- Replies (11)
|
 |
Starting this as a separate thread since I think Peter had some good suggestions:
Quote:Getting back to the original topic; I wanted to discover some way of annotating official parts with a tag that states what would need to be fixed if a part for some other reason is being edited. IMHO, the "needs work" sounds appropriate although it is not currently used or even intended for such use.
Maybe !NEEDSWORK could be added as a meta instead of being appended to the description and/or comments/!HELP.
Why not create a !BRICKLINK meta specifically for taking care of the mapping? Or a !LINK meta with two arguments - one for the authority (e.g. BrickLink), and the other for the ID?
|
|
|
| Implementation of chord primitives |
|
Posted by: Peter Blomberg - 2025-08-07, 20:14 - Forum: Parts Authoring
- Replies (5)
|
 |
16-sided chords come in two types; 1-8, 3-16, 1-4, 5-16, 3-8, 7-16, and 2-4 are made of mostly quads while 5-8, 3-4, 13-16, and 7-8 are made of only triangles. I get that the final triangle count is the same no matter how the triangles are organized.
Nevertheless, the triangle-only solution has a lot of narrow triangles and they are concentrated to the same area. Why is that? I would understand it if the chords were created additively (previous chord + one triangle = next chord), but they aren't.
Should we do something about it?
|
|
|
| Needs Work and Help |
|
Posted by: Orion Pobursky - 2025-08-06, 21:56 - Forum: Official File Specifications/Standards
- Replies (12)
|
 |
For Needs work parts the header spec says:
Quote:If the part is good enough for public use, but has some deficiencies that need to be addressed, the text " (Needs Work)" (without the quotation marks) can be added to the end of the description. If the description includes "(Needs Work)", a comment must be added to the file immediately after the header that explains the work that needs to be done
However, while most parts have comments, some parts use !HELP. What standard should we enforce?
|
|
|
| 4x2 curve slope wedge 6929 right/6930 Left |
|
Posted by: Ryan Hicks - 2025-08-06, 20:52 - Forum: Part Requests
- Replies (2)
|
 |
Think these were first seen on the 2025 F1 sets from March. Did a cursory scrub through the parts tracker, a search there and here in forums to be sure... (Swear I thought I saw these float by but can't find them now, seems this is the year for left/ridge compound curve wedge slopes with 2x2, 4x1, etc)
Limited colors for builds yet but look to be pretty interesting to design with:
Cheers. Hope you're all well,
Ryan
|
|
|
| ARM64 Release? |
|
Posted by: tom alphin - 2025-08-05, 2:10 - Forum: LDraw Editors and Viewers
- Replies (3)
|
 |
I have noticed that the 64 bit LDraw installer is especially slow when running on my current-generation ARM-based Windows PC (Surface Laptop, Copilot+ PC, Snapdragon® X Elite / 12 cores). The actual apps x64 run pretty well on the ARM device (via emulation), but I am sure an ARM compiled version of apps like LDview would be even better.
I was wondering if anyone has explored creating a native Windows ARM version of the LDraw suite, or even just the installer?
Sincerely,
---Tom
|
|
|
| MLCad Source Code - x64 / ARM, multithreading optimizations? |
|
Posted by: tom alphin - 2025-08-05, 2:05 - Forum: LDraw Editors and Viewers
- Replies (4)
|
 |
I still prefer MLCad because I am extremely familiar with the XY/YZ/XZ/Preview format which I grew up with developing Quake levels as a teenager. I know it is pretty dated software, but I was wondering if anyone has reached out to the developer to see if they are open to releasing the sourcecode.
I am not a professsional developer, but I suspect that it would be possible to recompile an x64 and/or ARM build with minimal changes if the source code were available. I also expect that some of the worst performance bottlenecks (ex: loading the "Select Part" dialog) could be addressed with minor coding optimizations, such as keeping the partlist in memory, or optimizing the code to make use of multithreaded CPU's.
Has this been explored in the past? Is anyone else interested in helping?
Sincerely,
---Tom
|
|
|
| Duplo height of origin |
|
Posted by: Peter Blomberg - 2025-08-04, 12:27 - Forum: Parts Authoring
- No Replies
|
 |
"If the part has studs, the origin shall be the bottom of the topmost stud group."
"If a part doesn't have studs, the origin shall be the bottom of the part."
Despite the docs being very clear about the height of the origin, there are a number of exceptions.
Double curved top:
Official part 31213b has the origin at the top of the part. Sadly, the part was recently edited to correct for orientation. Since the origin height is a multiple of 48, moving the origin to 0 yields no benefit.
Official part 3664 has the origin at 24 LDU. This part should be rotated. The height can be corrected at the same time.
Bases of some kind:
Official part 13358 has the origin at 24 LDU. This was considered tolerable due to the snapping hole.
Official part 92005 has the origin at 24 LDU. The part has a snapping stud.
Official part 92011 has the origin at 48 LDU. The part has a snapping stud.
Parts 13358, 92005, and 92011 have the origin at a height which is a multiple of 24 (Duplo plate height), thus yielding no benefit from moving the origin to 0.
Official part 6405 has the origin at 16 LDU where the base is. This part should be rotated. The height can be corrected at the same time. ...or keep as is (see argument below)
Other:
Official part 4913 has the origin at 16 LDU where the base is.
Official part 4375 has the origin at 16 LDU where the base is.
Official part 4894 has the origin at 16 LDU where the base is.
Parts 4913, 4375, and 4894 have a base at 16 LDU, which could be used as an argument for not needing correction. Placing these parts would always be challenging (not a multiple of 24).
Official part 15327 (shower) has the origin at 16 LDU.
Official part 51708 (flagpole) has the origin at 16 LDU.
Official part 31925 (flag) has the origin at the bottom despite having a stud. This part is on the tracker for another reason.
There are four parts on the tracker with a hold. They have their origin at the bottom, thus following the docs.
I suggest we edit 3664 (needs to be edited anyway), keep 6405, 4913, 4375, and 4894 as they are until they are edited for another reason, and change the origin height of 15327 and 51708 as b replacement versions, and update the origin height of 31925 to the bottom of the top stud. Is this ok?
|
|
|
|