additional properties and export (3mf ...)

[hrgdavor]

Although I was slow at providing something towards 3mf export, I am curious, other than color, what properties would be useful to export.

I see material can be specified maybe like this ...

<basematerials>
  <base name="colorff0000" displaycolor="#ff0000"/>
</basematerials>

Looking at the spec I should place ref to material with the color on the <object pid="colorff0000">...</object>

My 3mf export is based on data I intercepted before going to GPU vertices and indices. Color I have there there is RGB/RGBA float values, but 3mf uses w3c html colors #rrggbbaa so exporter will convert it to w3c color and create material for each unique color.

I am placing a discussion here as I want to be aligned with manifold with 3mf, to more easily connect my jscad efforts with manifold.

There are things like PrintTicket in https://github.com/3MFConsortium/spec_core/blob/master/3MF%20Core%20Specification.md#41-meshes

...

[elalish]

That's great; I'm not really expecting 3MF to make use of most vertex properties anyway since it's for manufacturing. A print ticket is only useful if you know what printer you're sending it to. Likewise with materials - they only make sense if you've gotten some options to display from your print driver. For ManifoldCAD we can keep it simple and focus on creating geometry.

[hrgdavor]

@elalish I want to ask here cuz it is related to my 3mf effort. I took a bit of spare time to try to add 3mf to manifold but got stuck after pulling code to git.

I do not know how to build WASM, or at least download pre-build... I just want to run example web, so I can play with it and try to add 3mf export.

[hrgdavor]

after hours of getting env on a few ubuntu machines I got what I need there and then copied what is needed to run the examples.

I am doing sth wrong, but the generated fields do not look ignored on git.

extra strange is files added to public folder.

[elalish]

Yes, all good points. And yes, the public file additions are intentional, though you make a good point about adding them to git ignore. In fact probably the bypass solution you're looking for is to add just those manually; I'll have to think through the process and document it.

[elalish]

Okay, I took care of .gitignore in #474.

[hrgdavor]

I took, a look at the code, and looks like worker generates glb immediately on every execution. So I will need to delay that step, so when download is clicked it produces glb or 3mf then.

[elalish]

Well, this is a little tricky - we do need the GLB generated every time regardless because that's what we use for visualization on the page. I think we might want to keep the nodes list in memory in the worker (instead of clearing it) and have another message that causes that to be serialized as 3MF when requested, since it contains all the manifolds and a transform hierarchy. You can ignore any GLTF-specific stuff like material for now.

[napter]

Just a suggestion: I believe the easiest way to make building portable and easy for anyone is to do it in a docker container. If you create a docker file that follows the steps then building would just require the docker run command.

…

On Wed, Jun 28, 2023, 12:26 PM Emmett Lalish ***@***.***> wrote: Yes, all good points. And yes, the public file additions are intentional, though you make a good point about adding them to git ignore. In fact probably the bypass solution you're looking for is to add just those manually; I'll have to think through the process and document it. — Reply to this email directly, view it on GitHub <#456 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPYQ2P4KJHIDIURGUFEBGTXNRLK3ANCNFSM6AAAAAAZKNT73A> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[elalish]

I'm open to that - interested in contributing? I'm not really familiar with docker.

[hrgdavor]

@elalish I need to pick your brain on another related topic regarding 3mf. You have experience with the standard. I am looking to use 3mf to export a whole jscad script including:

• mesh for 3d print
• thumbnail
• jscad script (js file) that produces the mesh
• parameter values for the the mesh exported
• dependencies that script used (excl npm packages) js files stl files svg files

Mesh and thumbnail have a standardised way already. Other bits mentioned I would like at least to export in a way that is less likely to break software importing 3mf that only is interested in mesh. Would be nice to also standardise this in the future if deemed beneficial.

[elalish]

Well, a 3MF is just a zip, so it should be easy to include extra files, though I'm not sure how picky implementations are about throwing errors when they find a file they don't understand. The rest is XML, so it's easy enough to add your own custom extension for extra data. You're welcome to talk to the 3MF consortium about your ideas, but I doubt they'll be interested in anything with executable code - that's a security nightmare and a big part of why FBX was such a disaster.

[hrgdavor]

Thanks for the insights. I will need to split this to 2 different use cases.

1. Storing parameters that were used for generating a model (and maybe even camera location, and script url, and versions of dependencies ATM). This could maybe fit into some attributes and would not pose a security risk. This is a very important use-case for me, as I have some models like a bathroom towel hanger that I printed form few of my friends and each needs a bit different parameters.

2. A niche use case of archiving a project. Saving archive of project files into a 3mf format would add a benefit of it having a thumbnail like my other 3mf models have right now. And here I would not worry about compatibility with other software.

[elalish]

As I say, custom extensions are a standard part of XML, so go for it!