[FEATURE] 3D viewers integration

[markusweigelt]

• Add middleware for embedding installed 3D viewers via iframe
• Adjust current implementation and remove unnecessary files
• Implement error handling to account for multiple scenarios
• Documentation (Setup, configuration and creating custom viewers)
• Bugfixes of NPE and loading METS/MODS documents

[sebastian-meyer]

I like the improved documentation and more robust integration via middleware, but I think we should provide a default configuration which works out-of-the-box. So, there should be at least one default viewer pre-configured and all necessary files bundled with Kitodo.Presentation. I'd prefer three.js as default, but that's up to you!

Also, the default in documentation and configuration should be for all viewers to host their components (third-party libraries, configs, styles, etc.) locally with Kitodo.Presentation, because there are multiple users which run Kitodo in a controlled environment without access to the internet.

[markusweigelt]

I like the improved documentation and more robust integration via middleware, but I think we should provide a default configuration which works out-of-the-box. So, there should be at least one default viewer pre-configured and all necessary files bundled with Kitodo.Presentation. I'd prefer three.js as default, but that's up to you!

No problem, we can provide a default implementation, but we should discuss the default viewer. Three.js is a framework (sometimes described as a full game engine) with multiple options, such as lights, texture rendering, and loaders for different model types. However, it is not a fixed viewer. With Three.js, you can implement a viewer for specific cases, but this could lead to a maintenance burden that could hinder further development of the DFG-viewer. (In general, I think we should move such complexities to separately versionable components.)

That's why I think the model-viewer (based on Three.js) is more suitable because the maintenance effort is very low. In the best case, only the version number needs to be adjusted, and in the worst case, some attributes of the HTML tag might need updating. The disadvantage is that only glTF/GLB 3D models are supported.

Also, the default in documentation and configuration should be for all viewers to host their components (third-party libraries, configs, styles, etc.) locally with Kitodo.Presentation, because there are multiple users which run Kitodo in a controlled environment without access to the internet.

All our current viewer implementations at https://github.com/slub/dlf-3d-viewers can run locally. Otherwise, I believe it is the responsibility of our implementation repository and not part of this PR.

Only the Kompakkt Viewer itself can be explicitly installed on a local system. I will add an option to set your own instance there. By default, it uses the University of Cologne's Kompakkt instance.

If I misunderstood anything, we can certainly discuss it further to clarify. :)

[sebastian-meyer]

That's why I think the model-viewer (based on Three.js) is more suitable because the maintenance effort is very low. In the best case, only the version number needs to be adjusted, and in the worst case, some attributes of the HTML tag might need updating. The disadvantage is that only glTF/GLB 3D models are supported.

Perfect! Then let's use the model-viewer as a default. Since glTF/GLB is the most common 3D format, I think it's reasonable to only support those with our default configuration.

If I misunderstood anything, we can certainly discuss it further to clarify. :)

What I meant is, that all files should be hosted on the Kitodo server and not loaded from their original source or some kind of CDN. The Kompakkt viewer is special, because AFAIK it's the only viewer which needs its own server-side backend.

[markusweigelt]

What I meant is, that all files should be hosted on the Kitodo server and not loaded from their original source or some kind of CDN.

This is taken into account with the implementation repository. There is an installation script that downloads the respective resources and adds them to the viewer as a module folder.
For the default viewer, I will include it in the Kitodo.Presentation installation instructions or should the library be added to the source code?

[sebastian-meyer]

Please add the default viewer to the source code (in its own sub-directory of Resource/Public/JavaScript/) so we can exclude it from automatic static code analyzing. Installing Kitodo.Presentation should be as easy as possible. Thank you!

[sebastian-meyer]

Thank you very much!