I have completed the lower Body of the Minion Figures. Now how to number them.

On Brickset, each body has its own DesignID and on Bricklink, there only an inventory of the standard figures and they use 67644, so this blue trousers are 67644p01.

The 67644 is embossed on the feet, which is the only visible number.

In total there must have been three injections, yellow inside, Outside trousers and the feet.

Here's a suggestion for the breakdown:
-> Should Colour1 and Colour2 be a u-number or simply another 67644 sub-part?
   

Here are the available bodies so far:
From left to right, Brickset Numbering: 68995, 69042, 69036
->Should they be numbered as 67644p0x?
   

Same goes for the heads...

Thanks
Gerald

We need images for the Cylindrical and Spherical TEXMAP projections. If you want to redo the one for Planar to make the style consistent, that's fine too. 

Here's the spec:
https://www.ldraw.org/spec/texmap.html - correct is: https://www.ldraw.org/texmap-spec.html

Discussion seems to have petered out on this 2 docs:

Official Library Part Number Specification
LDraw.org Official Parts Library Specifications

I did a proofread a few days ago and they're pretty much ready to go I think. 

I'll follow this thread and make any change you 3 propose. I'd like to finish this project out.

I've tweaked the OMR spec somewhat. There are no material changes, just some formatting and clarification.

I'm currently cleaning up the code the file format documents to unify the style amongst other things. I may make some minor editorial changes but nothing substantive.

However, are there any objections from the LSB if I fold some of the added changes into the body of the document?

Example:
Official Library Header Specification has 3 appendices. I'd like to fold them into the main document and eliminate the appendices. The revision history will be listed at the top of the document.

Additionally, this document: Official Library Policy On Embedding POV-Ray Code can be cancelled and archived since the POV metas are already disallowed in the File Format Restrictions for the Official Library

I'd like to amend the File Format regarding META commands used pretty much only by the original LDraw.exe.

Proposal:
Add the following paragraph after the first paragraph (Beginning "Meta commands (or meta statements...") in the "META Command" section:

Quote:The META commands WRITE, PRINT, CLEAR, PAUSE, and SAVE are documented here for legacy purposes only and implementation in new LDraw compliant programs is optional. 

I have posted a test release for LDView 4.4 Alpha 6 to GitHub:

https://github.com/tcobbs/ldview/release...4.4_Alpha6

This release does have some known issues, but it also has quite a bit of new functionality, as well as some significant bug fixes.

Right now, I have only provided installers for macOS and 64-bit Windows. If you would like me to create an installer other than one of those two, please let me know.

The ChangeHistory.html file that is included in the release lists all of the changes. In the macOS version, ChangeHistory.html is in the dmg. In the Windows version, ChangeHistory.html gets installed to wherever you install LDView (C:\Program Files\LDView by default). I think the most important changes are:

1. Support for SPHERICAL and CYLINDRICAL texture maps.
   
2. Support for !DATA meta-command for embedding texture maps into MPDs.
   
3. Support for DPI scaling (AKA High DPI) on Windows, as well as Retina displays on macOS.
   
4. Support for macOS Finder thumbnail generation (toggle on LDraw tab of preferences).
   
5. Support for macOS Dark Mode.
   
6. Multiple important TEXMAP bug fixes.
   

Designer Sets

Hey,

just wanted to say that I started to work on a long-term alternative for LDPE, called LDPartMaker.
This "next-gen" version is an offline web application which runs inside a modern web browser of your choice.
LDPMs main focus should be usability and compatibilty to other operating systems like Linux and Mac OS X.
My personal purpose of this project is to learn something new about modern web technologies.

The big challenge of this project is seamless integration with the local file system.
A web application can't simply read your local LDraw library files or your local subparts from a project.
But, there is currently a very interesting WC3 draft on this "native file system access" topic: https://wicg.github.io/native-file-system/

Project advantages:
- Runs fast on any modern browser (in combination with a standard graphics card).
- Does not need additional runtimes (.NET Framework, JVM, etc.).
- Benefits from hardware accelerated 3D graphics and multithreading.
- Is a web application without the need of a connection to the internet.

Project disadvantages:
- Uses 'state-of-the-art' web standards and technology. It does imply that it probably will not run on older systems.
- The access to the file system is limited. We currently have to wait for the WC3 to finish its work.

Core technology:

• WebGL 2.0 (3D Graphics API)
  
• Angular 9 (Framework)
  
• TypeScript (Programming Language)
  
• HTML 5 File API / Native File System API
  
• WebWorkers (Muticore / Multithreading)