Possible differences in how models are placed in 3D scenes between 3D viewers used in demos

[JulieWinchester]

In multiple IIIF 3D TSG meetings, including the meeting that happened today on July 12th 2023, a topic of discussion has been raised concerning possible differences between how models are placed within a 3D scene's coordinate system between Smithsonian's Voyager and at least some other Three.js viewer tools or viewer demos. We should explore this issue further, document details, and try to resolve it if possible.

Specifically, the issue seems to relate to this viewer demo using Voyager to display multiple models. My understanding is that @edsilv has tried to use the coordinate positions used in this demo within other Three.js-based demo harnesses, with the baseball bat model ending up in a different position compared to the Voyager demo. See the picture included for an example of this.

The most explicit documented discussion of this difference was provided by @gjcope in this issue comment. I think we need more detailed documentation of the issue, and hopefully we can try and determine whether this can be resolved? I'll also say that my understanding is that our approach for the IIIF spec manifests is also to have "child node" position determined relative to parent node position in some cases, so perhaps the Voyager behavior is the ideal behavior? But I think I need to understand the situation better before commenting further.

@edsilv : Could you provide a link to a comparative demo implementing the "bat on ground" behavior, and detail the data you're using from the Voyager demo to produce that?
@gjcope : After Ed provides a bit more detail, are you available to help us try and work through this? We can also perhaps talk more during the next IIIF 3D TSG meeting, but hopefully we can make some progress on GitHub in the meantime.

Thanks to both of you!

[gjcope]

Apologies for the delayed response, I've been away.

The difference is as documented in the link the previous comment above. In Voyager, the decision was made (before my time) for scale at the model level to be driven by changes in units rather than an explicit scale value. (You can see this in our model schema here: https://github.com/Smithsonian/dpo-voyager/blob/b1fcada3b7fb5d3a38f653ebfb0bfb418c629c0f/source/client/schema/model.ts#L53). I don't know the rationale for this decision, but my assumption is that it was because we are targeting scan data and display of objects with accurate units.

That just means that setting a specific scale, as in the case of the baseball bat, happens at a higher level in the hierarchy. That means from a world-space view, the rotation and translation are being post-scaled, hence the scaled values I provided in the linked comment.

In the end, I think this is probably just an instance of viewer-specific 'translation' that will have to happen form the IIIF spec.