Based on experience, without much looking into it my first response is that it can be bone.
Given that it is expensive (especially 2.B. mentioned below), IMHO that should come together with settings pane to toggle behaviour (apps can have publish settings under settings/admin/, save them in DB etc.)
It begs the question - do you see that thumbnails are generated for (A) files that have been opened using this app at least once or (B) for any/all files.
A The first would use context / buffer that is created in browser when opening file to get pixels back to CPU and save it to thumbnail data.
B The second IMHO should be implemented via server side head/browserless texture rendering (albeit maybe one could hijack browser when opening directory and do client side offscreen thumbnail generation that IMHO would stall the browser and thus I do not take this option seriously), that I have some experience with, but in node.js world. I feel hesitant about idea of PHP + client-side HTML5 app with attached background node.js daemon, also, given that I see more direct enhancements that this app needs https://github.com/WARP-LAB/files_3dmodelviewer#todo.
Idea itself is logical 😄 2.A. is smth that I might look into.
Is your feature request related to a problem? Please describe
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.