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

STL codec: should use binary file format #29

Open
drayde opened this issue Feb 9, 2024 · 3 comments
Open

STL codec: should use binary file format #29

drayde opened this issue Feb 9, 2024 · 3 comments

Comments

@drayde
Copy link
Contributor

drayde commented Feb 9, 2024

I suggest to use the binary format for STL generation, or make it configurable

@jmwright
Copy link
Member

We'll need to figure out how to add this option. For formats like gltf you can determine whether a binary or ASCII version is desired based on the file extension, but with STL that is not possible since the same file extension is used for both. Maybe there could be an --encoding command line parameter that accepts binary, ASCII, utf-8 etc, which is then passed through to the codec, which can decide how to use that information.

@drayde
Copy link
Contributor Author

drayde commented Feb 10, 2024

I would opt for always saving binary STLs in a first step, as in most use cases this is what you would want

@jmwright
Copy link
Member

Arguments for keeping ASCII as the default, or at least giving the user the option to revert back to ASCII.

  1. Defaulting to binary would change existing behavior and could break existing systems that integrate cq-cli if they upgrade.
  2. When CQ changed from ASCII to binary as the default for STL, it broke some things downstream. Nothing major, but it did cause some confusion.
  3. cq-cli is designed to be used in pipelines for text transformations as well, which would be broken if defaulting to binary without a way to revert to ASCII.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants