djeedai / weldr Goto Github PK

Ldraw has an MPD extension for embedding multiple files in the same file. The extension is documented here: https://www.ldraw.org/article/47.html.

While files using the MPD extension typically use the .mpd extension, it's also common to see .ldr files containing multiple embedded files. This seems to be the standard way to define submodels in a single ldraw file or embed custom parts.

The current parsing implementation assumes all subfile commands come from the resolver like DiskResolver, which won't be the case for embedded files. This causes resolve errors. The spec doesn't make any requirements on how to handle embedded filenames "masking" the filenames of actual parts on disk. This could theoretically be handled by just parsing and adding all the embedded files to the source map before recursing into the subfiles themselves. This would ensure the embedded submodel file gets loaded before we try and resolve the command 1 ... submodel.

This may also require changes to the return type of the parse commands. Returning a single SourceFile may not adequately capture that the file could have embedded files. This depends on whether a SourceFile should represent the list of commands in a single ldraw file or the file "blocks" as represented in the MPD extension. It still makes sense for parse_raw to return the SourceFile. The recursive version parse could return all commands in a single SourceFile, return a collection of SourceFile, or not return a SourceFile at all.

I'm currently working on reworking the file loading to try and support this extension as described above. Let me know if you have any suggestions or concerns.

See https://github.com/djeedai/weldr/pull/27/files#r1127095741

It would be safer to let bytemuck handle those conversions, the maintainers have put a lot of thinking into making sure their implementation is safe.

See what Rust version bytemuck supports; they say 1.34 for base without feature, but do we need any feature?

cgmath is kind of old and unmaintained, and missing a lot of utility methods. This makes the code pretty verbose/ugly.

Logging to remember:

• wrong LICENSE-APACHE(2) link
• wrong Cargo.toml snippet version

CHANGELOG also missing reference to fix of #21

I was looking for robust and efficient ldraw parsers in Rust and found this crate. From my initial experience, the library has been very well documented and easy to use. I noticed in #2 that the code likely hasn't been run against the entire parts library yet. I've already found some panics.

I'm getting the error Utf8Error { valid_up_to: 10, error_len: Some(1) } at this section of code. Rust doesn't seem to complain about the formatting when I trying and convert the file to utf8 with std::fs::read_to_string. This happens on the recently downloaded ldraw as well as bricklink studio parts libraries. I can upload the dat file if needed.

weldr

• Implement all basic LDraw commands (1 to 5) (aae85ec)
• Implement sub-file resolution and recursive parsing (7cc74c6)
• Add error handling (5758d20)
• Expose iterators (1d5eac6):
  • for all non-sub-file commands (default behavior; iter()), transparently descending into sub-files
  • for all commands local to a file (local_iter()) including sub-file commands, without dereferencing
• Implement common meta command extensions
  • !HISTORY - File Changes History
  • !COLOUR - Colour Definition (372ef24)
  • BFC - Back Face Culling
  • !TEXMAP - Texture Mapping
  • !CATEGORY (afe45eb)
  • !KEYWORDS (afe45eb)
  • Multi-Part Document (#26)
• Add basic filesystem-based resolver (possibly in examples/ only)
• Add source map cache to avoid re-loading and re-parsing the same sub-files
• Benchmark : entire LDraw official catalog (speed + correctness)

weldr-bin

• Handle parts catalog location configuration (5db56b9)
• Fix bug with some round parts looking truncated (e.g. 6143.dat) (94fd91f)
• Merge duplicate vertices
• Handle various primitives : line, triangle, quad (instead of current all-triangle discard-lines) (lines: efaa14a)
• convert gltf: Output glTF buffer inline inside JSON to allow stdout output

See the discussion at https://forums.ldraw.org/thread-13787-post-13790.html