Support for 3MF files?

[jnweiger]

Is your feature request related to a problem? Please describe. I often have designs saved in 3MF format after preparing STL for printing. 3MF files are not picked up by this 3dviewer.

Describe the solution you'd like 3MF is mentioned in js/fileinfo.js but commented out. What is the state of the 3mf support? Thank you!

Describe alternatives you've considered None :-)

Additional context 3mf is actually a zip, with one component representing object meshes in XML.

[alexstocker]

Thanx @jnweiger for asking.

Yes, if adding 3MF support would help you I will have a look.

For some reason, I think libs or/and Lic. related it was, I commented out 3MF Support.

[alexstocker]

@jnweiger Added 3MF support. Please checkout 1.0-devel if you want to have a try.

Feedback on 0.1.0 UNRELEASED appreciated

[jnweiger]

Thanks for the speedy response. Unfortunately, .3mf files are still not recognized for me, using the 1.0-devel branch.

Nothing in the owncloud log, nothing in the javascript console. The problem seems to be that my ownCloud instance recognizes 3mf as a zip file.

select path,mimetype,mimepart,size from oc_filecache where name like '%xlcd_support%';
+--------------------------------------------------+----------+----------+----------+
| path                                             | mimetype | mimepart | size     |
+--------------------------------------------------+----------+----------+----------+
| files/Documents/xlcd_support_detachable_clip.stl |       11 |        7 |  1344384 |
| files/Documents/xlcd_support_detachable.3mf      |       12 |        7 |   478960 |
| files/xlcd_support_detachable.stl                |       11 |        7 |   664984 |
| files/xlcd_support_detachable.FCStd              |       12 |        7 | 11549412 |
| files/xlcd_support_detachable.3mf                |       12 |        7 |   478960 |
+--------------------------------------------------+----------+----------+----------+
5 rows in set (0.001 sec)

MariaDB [owncloud]> select * from oc_mimetypes;
+----+-----------------------------------------+
| id | mimetype                                |
+----+-----------------------------------------+
|  7 | application                             |
| 11 | application/octet-stream                |
|  9 | application/pdf                         |
|  8 | application/vnd.oasis.opendocument.text |
| 12 | application/zip                         |
|  1 | httpd                                   |
|  2 | httpd/unix-directory                    |
|  5 | image                                   |
|  6 | image/jpeg                              |
| 10 | image/png                               |
|  3 | text                                    |
|  4 | text/plain                              |
+----+-----------------------------------------+
12 rows in set (0.000 sec)

Workaround

Viewing of 3MF files works after patching the mimetype to application/octet-stream:

update oc_filecache where name like '%.3mf' set mimetype=11;

[alexstocker]

@jnweiger Great that you made it work. The need of manually changing the mimetype sounds a bit strange to me.

For testing purpose I used the 3MF Consortium examples https://github.com/3mfconsortium without observing this behavior, but others ;-)

I will go into investigation on this behavior. Can you provide a sample file and additional informations like

• application used to create 3MF files?
• customized mimetypes at your oc instance?
• OC Version?

[alexstocker]

@jnweiger It turns out, mimetype application/zip does not exist on default at OC 10.13.4. I'm pretty sure that the behavior you described can be reproduced if additional mimetypes are added or modified. Will see if I can find a suitable solution.

[jnweiger]

The oc_mimetype table gets populated on the fly. I cannot reproduce the zip behaviour with a fresh owncloud/server:10.13.4 docker. Everything works fine there, and the 3mf mimetype is application/octet-stream as expected. First uploading a zip file so that the application/zip entry is created; then uploading a 3mf, still assigns application/octet-stream to the 3mf. I'll try to scratch my head to reproduce that weirdness in my other instance ...

Example https://github.com/3MFConsortium/3mf-samples/blob/master/examples/core/cube_gears.3mf also fails for me in this other instance.

---

The files I used for testing were saved by prusaslicer 2.7.2 Example attached.

test-3mf.zip

[jnweiger]

3mf files work fine in general.

Note to self: The exception is, when ownCloud is installed with its primary storage on an S3 server using the file_primary_s3 app. In my cas it is a scality S3 server. I can check with s3cmd info, that the S3 server identified the mimetype actually as model/3mf

s3://oc-primary/urn:oid:38 (object):
   File size: 478960
   Last mod:  Mon, 18 Mar 2024 09:41:54 GMT
   MIME type: model/3mf
   Storage:   STANDARD
   MD5 sum:   eac2925b39c45f98ce141f58bf17be0c
   SSE:       none
   Policy:    none
   CORS:      none
   ACL:       owncloud: FULL_CONTROL

In this case oc_filecache lists it as application/zip -- I'd need to further investigate where exactly that decision is made between application/zip and application/octet-stream.

@alexstocker as the mimetype seem to depend somehow on the type of storage used within ownCloud: can you make your code less dependant on mimetypes, and maybe more on the suffix?

[alexstocker]

@jnweiger Thanx for investigating and yes, good point, I will take it into account.

[alexstocker]

@jnweiger Replaced mimetype by using file type extensions instead. Give it a try and please tell me. Thanx