This repository has been archived by the owner on Jun 15, 2023. It is now read-only.
Cura WASM Version 2 #11
Unanswered
Wakeful-Cloud
asked this question in
Ideas
Replies: 2 comments 1 reply
-
I would say that the setting files could be left out of the WASM binary so long as it would be possible to push slicing configurations in to the virtual file system. |
Beta Was this translation helpful? Give feedback.
1 reply
-
I was thinking that being able to write my own JSON files to the file
system for it to use.
…On Sun, May 23, 2021 at 1:23 PM Wakeful-Cloud ***@***.***> wrote:
Would you want definitions to be supplied by Cura WASM or would you want
to *bring your own* definitions (Basically writing JSON files to the
virtual filesystem)?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#11 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABREGXBLF56TNZWWUEJNBHLTPE2Z5ANCNFSM45LN2WKA>
.
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
FAQ's
What
This is a thread to get some ideas going for Cura WASM Version 2.
When
Version 2 is targeting release in late summer (2021).
Why
Because the Cura WASM API could be better and it could expand beyond the JS/TS ecosystem.
Overarching Goals
1: Clean up the API
This could be accomplished by allowing API consumers to mix overrides and CLI arguments. This could also be accomplished by splitting Cura WASM into a core repository (Which would include a virtual filesystem, minimal output processing, and multithreading) and a higher-level API repository (Which would take care of definitions, common object transformations, and other features people new to Cura Engine would appreciate).
2: Add support for common transformations
This would add support for easily transforming (Translation, rotation, and scaling) objects. Currently, translation and scaling should be easy to do but rotations require computing a rotation matrix and feeding that to Cura Engine. If the matrix computation were to be included with Cura WASM, this would greatly reduce the amount of code API consumers would need to perform rotations on objects (Including for Cloud CNC itself).
3. Convert Cura WASM to a WAPM package
This would allow people to use Cura WASM outside of the JS/TS ecosystem since the Wasmer runtime has a bunch of language bindings. Internally, Cura WASM would actually use the JS Wasmer integration to interface with Cura Engine. This would have no impact on the exported Cura WASM API.
4. Improve file support
Although this is more related to
unified-3d-loader
, it would be nice to have better support for various 3D formats (Chiefly.3mf
,.amf
,.ply
, and maybe.obj
). This would NOT include adding additional formats but simply improving the existing ones. If you'd like to see more formats supported, feel free to open a PR.Beta Was this translation helpful? Give feedback.
All reactions