Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Export to STL #154

Closed
hannobraun opened this issue Feb 9, 2022 · 3 comments · Fixed by #594
Closed

Export to STL #154

hannobraun opened this issue Feb 9, 2022 · 3 comments · Fixed by #594
Labels
good first issue Good for newcomers topic: export Exporting to external file formats type: feature New features and improvements to existing features

Comments

@hannobraun
Copy link
Owner

Fornjot already supports exporting to 3MF. Since STL is also based on triangle meshes, adding support should be fairly straight-forward and not require many changes to existing Fornjot code.

The export code currently lives in main.rs. It can be extended to check the file ending of the export path, and choose the file format accordingly. I think this would also be a good opportunity to clean up main.rs a bit, and move that export code to a separate module.

There might already be libraries for writing STL files that we can use. I haven't looked into that.

Labeling as https://github.com/hannobraun/Fornjot/labels/good%20first%20issue, as this doesn't require much knowledge of Fornjot, and might be a good introduction to it.

@hannobraun hannobraun added type: feature New features and improvements to existing features good first issue Good for newcomers topic: export Exporting to external file formats labels Feb 9, 2022
@chrisprice
Copy link
Contributor

From a quick hunt around crates.io, there seem to be two popular crates for working with STL files -

I'm a little confused/concerned by the license of stl_io. According to the Cargo.toml it is GPL-3.0, according to LICENSE it is GPL-3.0 and according to the README.md it is dual licensed Apache 2.0 and MIT. A year old PR which attempts to address this has yet to be accepted. Conversely nom_stl is consistently MIT licensed.

However, nom_stl is currently only able to read/parse STL files and not write/serialize them so I went with stl_io. Is the license an issue for use in this project?

I've knocked together a branch with a first pass at an implementation and I was pleasantly surprised to find that macOS natively supports STL files in Preview -

image

I'd still like to investigate exporting to an IndexedMesh as I think it might be a simpler approach (I've done no research to back this up).

The files in the preview above were generated by running the below test script -

#!/bin/sh

cargo run -- --model cuboid --export cuboid.stl
cargo run -- --model cuboid --export cuboid.3mf
cargo run -- --model cuboid --export cuboid.unknown
cargo run -- --model cuboid --export cuboid

cargo run -- --model group --export group.stl
cargo run -- --model group --export group.3mf
cargo run -- --model group --export group.unknown
cargo run -- --model group --export group

cargo run -- --model spacer --export spacer.stl
cargo run -- --model spacer --export spacer.3mf
cargo run -- --model spacer --export spacer.unknown
cargo run -- --model spacer --export spacer

cargo run -- --model star --export star.stl
cargo run -- --model star --export star.3mf
cargo run -- --model star --export star.unknown
cargo run -- --model star --export star

Which produces the following output -

    Finished dev [unoptimized + debuginfo] target(s) in 6.54s
     Running `target/debug/fj-app --model cuboid --export cuboid.stl`
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
    Finished dev [unoptimized + debuginfo] target(s) in 0.33s
     Running `target/debug/fj-app --model cuboid --export cuboid.3mf`
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s
    Finished dev [unoptimized + debuginfo] target(s) in 0.23s
     Running `target/debug/fj-app --model cuboid --export cuboid.unknown`
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
Error: Extension not recognised, got "unknown"
    Finished dev [unoptimized + debuginfo] target(s) in 0.23s
     Running `target/debug/fj-app --model cuboid --export cuboid`
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s
Error: No extension specified
    Finished dev [unoptimized + debuginfo] target(s) in 0.24s
     Running `target/debug/fj-app --model group --export group.stl`
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s
    Finished dev [unoptimized + debuginfo] target(s) in 0.22s
     Running `target/debug/fj-app --model group --export group.3mf`
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s
    Finished dev [unoptimized + debuginfo] target(s) in 0.24s
     Running `target/debug/fj-app --model group --export group.unknown`
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s
Error: Extension not recognised, got "unknown"
    Finished dev [unoptimized + debuginfo] target(s) in 0.25s
     Running `target/debug/fj-app --model group --export group`
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s
Error: No extension specified
    Finished dev [unoptimized + debuginfo] target(s) in 0.24s
     Running `target/debug/fj-app --model spacer --export spacer.stl`
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
    Finished dev [unoptimized + debuginfo] target(s) in 0.24s
     Running `target/debug/fj-app --model spacer --export spacer.3mf`
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s
    Finished dev [unoptimized + debuginfo] target(s) in 0.26s
     Running `target/debug/fj-app --model spacer --export spacer.unknown`
    Finished dev [unoptimized + debuginfo] target(s) in 0.06s
Error: Extension not recognised, got "unknown"
    Finished dev [unoptimized + debuginfo] target(s) in 0.25s
     Running `target/debug/fj-app --model spacer --export spacer`
    Finished dev [unoptimized + debuginfo] target(s) in 0.06s
Error: No extension specified
    Finished dev [unoptimized + debuginfo] target(s) in 0.24s
     Running `target/debug/fj-app --model star --export star.stl`
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
    Finished dev [unoptimized + debuginfo] target(s) in 0.22s
     Running `target/debug/fj-app --model star --export star.3mf`
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s
    Finished dev [unoptimized + debuginfo] target(s) in 0.23s
     Running `target/debug/fj-app --model star --export star.unknown`
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
Error: Extension not recognised, got "unknown"
    Finished dev [unoptimized + debuginfo] 
target(s) in 0.23s
     Running `target/debug/fj-app --model star --export star`
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s
Error: No extension specified

Attached are the STL files.

@hannobraun
Copy link
Owner Author

Thanks for looking into this, @chrisprice!

I'm a little confused/concerned by the license of stl_io. According to the Cargo.toml it is GPL-3.0, according to LICENSE it is GPL-3.0 and according to the README.md it is dual licensed Apache 2.0 and MIT. A year old PR which attempts to address this has yet to be accepted. Conversely nom_stl is consistently MIT licensed.

However, nom_stl is currently only able to read/parse STL files and not write/serialize them so I went with stl_io. Is the license an issue for use in this project?

That's an unfortunate situation. The license would indeed be an issue. Fornjot is licensed under 0BSD, basically the most permissive license there is, and that's deliberate. Using a GPL-licensed library would completely change the requirements we put on people that want to use Fornjot libraries, or distribute anything from Fornjot.


I just did a quick search and fount stl (crates.io, GitHub). Seems to support reading and writing, and seems to be better maintained (more recent activity, no outstanding pull requests). Maybe that will work for us.

If, for some reasons, it doesn't, I suspect that rolling our own STL export would be practical as well. I haven't looked into STL in detail, but from what I know, it's a simple format. And for writing, we wouldn't even need to support all of it, just the subset we need. 3MF wasn't much of a problem, after all.

@chrisprice chrisprice mentioned this issue May 16, 2022
@chrisprice
Copy link
Contributor

I skipped over stl originally because of the low download count. However, I really hadn't appreciated just how simple the STL format was. The implementation of stl is very straightforward and as you say if it ever needs replacing then rolling our own would be fine.

I've created a PR covering the stl implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers topic: export Exporting to external file formats type: feature New features and improvements to existing features
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants