Recently I've tried to append some 3D objects as resources to our museum objects in Museum Digital, but only the "black grid" picture appeared as a preview. It was .obj file in zip, less than 20GB.
Where I can find samples of attached 3D objects in the Museum Digital database?
How to correctly attach a 3D object to a museum exhibit in the Museum Digital database?
What about .glb files?
Thanks in advance


17 days later

I looked into it a bit further now. Apparently the descriptions in musdb are not entirely correct. As stated there, a ZIP file with a .obj and optionally .mtl files are required. What I missed before and what is not documented thus far is that the .mtl file may reference an image file for retrieving texture information. JPG files (.jpg, not in any other spelling) are allowed in the ZIP for that.

Furthermore I found a small bug in the library we use for rendering the 3D objects from the ZIP. In effect it seems to work fine if all three file names are aligned. Say you have three files in the ZIP:
01.obj
01.mtl
01.jpg
In this case, the ZIP file would need to be named 01.zip.

If the .mtl references a file that does not exist in the ZIP, the object cannot be rendered.

Note that hidden files or subfolders are not allowed in the ZIP file.

    Hi Joshua Enslin , thank you for taking a detailed look at it! I've also noticed that the files of 3D objects I attempted to upload typically include three or more image files for retrieving texture information, which complicates following the same naming structure. Even if I name them as "01 (01)," "01 (02)," etc., the upload still doesn't work. Additionally, using just one JPG file still results in the error message "Disallowed file 0 in the ZIP archive. Aborting." 🙁

      Hi, file 0 means that it's the first file in the ZIP archive that causes problems. That may be anything, but a good guess would be that it's likely one of two problems:

      The validation of the ZIP happens on the root level of the archive. If you packet a whole folder, the root level constists only of a directory (hence the directory would be the first entry and not a valid file of any of the accepted extensions).

      My second guess would be a hidden file arising from not selecting the files individually before packing. Windows tends to put hidden files thumbs.db in a folder, Mac OS does the same with files named .DS_STORE.

        Oleg Mitiukhin

        No, only a zip with one .obj and optional .mtl and .jpg files.

        I must say I also don't see that changing anytime soon. For all types of media files, we have thus far only allowed one format (converting to that if necessary, but on md the primary image format is jpg, pdfs are pdf, videos are mp4, etc.). That makes handling the files a lot easier. If we were to introduce .glb at some point, we'd have to do away with the existing solution. In effect that would mean to convert everything that has been uploaded thus far.

        .glb looks promising and I can see that happening at some point in the future. But certainly not anytime soon (unless somebody volunteers to implement it all the way, including the conversions).

          One more small question. If we put the .obj file, do we need to manually insert the preview image of the object? It looks like the preview is not automatically generated.

            Joshua Enslin thanks for the suggestions! I too thought the problem might be hidden files (encountered during the migration) and additionally checked that no other files were there. Also, I made the archive now not in automatic mode but "manually" adding files after the other one, but I always have the jpg file first, for some reason I can't change that. Maybe that's the problem right there? And with that, I'm still only uploading 1 jpg file out of three, while all three are needed for 3D to function.

                Ekaterina Malygina nah, just tried to upload just 01.mtl and 01.obj in 01.zip - still "Disallowed file 0 in the ZIP archive. Aborting."... So it's probably not the image, but the 3d wouldn't work properly without those 3 jpgs, I suppose...

                  Ekaterina Malygina
                  Very briefly, I created a 3D model by scanning in Polycam, exported as .obj, then edited the names of the correspondent files and made corrections to the 1.obj file (third line).
                  Also, I made the preview image for this object and add it to 3D object.

                  It was a test 3D model, so I will delete it from Museum Digital tomorrow.
                  If you have some 3D obj file, I may try to fix it for you.

                    Oleg Mitiukhin

                    Yes, musdb can only enter a placeholder there. The rendering of the 3D object is done entirely on the client side (say, the browser), and for generating the thumbnails we would need rendering capabilities on the server side. But rendering may take a long time and a lot of resources (say, chance it it would cause a timeout with larger files) and of course introduced a whole lot of code to maintain. In summary I don't think the benefits outweigh the costs.

                    But I just had an idea that may be useful. Maybe we could determine a fixed file name in the zip archive so that you could pregenerate the thumbnail. Say, if an image thumb.jpg existed in the root level of the zip, that could be used as the thumbnail and then automatically removed from the zip archive so as to save bandwidth for people viewing the object. Would that help?

                        Aye, that one's implemented now. The file needs to be named thumb.jpg and be in the root level of the zip archive, then it will be extracted from the archive, deleted in it, and used for the thumbnail instead.

                          Joshua Enslin
                          Import of 3D objects was successful!
                          I created a 3D object in Polycam (Samsung Galaxy S10), exported it in .obj format, added a preview file to the created archive. Everything was imported into the Museum Digital database correctly.

                              Ekaterina Malygina Thank you )
                              Yoga is only for example, it will be deleted shortly, I plan real 3D models for our objects.
                              We have made some models, for the previous project, but these models are huge (>100MB).
                              It will be a challenge for me to reduce it.

                                Don't worry too much about the file size. While 100 MB is certainly a bit much, the 20 mb maximum file size stated in the upload menu are due to an outdated translation variable. I guess a warning before the downloading of overly large models would be another feature to add (especially for users on mobile devices)...