You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For maximal interoperability, the <model> spec should pick a single model format for browsers to all implement. (I'm not challenging the proposed API shape, with the <source type=...> parameter: that enables future extensibility.)
If there are already multiple formats with varying capabilities, such that none of them is strictly better than all the others, the specification should still list the types that may be supported and pick one lowest-common-denominator that all implementations must support.
If the browsers can't even agree on a lowest-common-denominator format, the specification should still list a set of formats that authors can provide that's guaranteed to cover all browsers. Arguably, it should require authors to provide options in all of those formats (by refusing to display the model if one of the <source>s is missing), but since authors could work around that by putting garbage URLs into the other <source>s, I'm not sure that's worth it.
I'm aware that the image and video elements fail to follow this advice: we shouldn't repeat that mistake for <model>.
The text was updated successfully, but these errors were encountered:
Note the capabilities with Javacript and DOM integration of X3D + glTF
showcased in this recent Blog: https://www.web3d.org/blog/anitahavele/x3d-html-way
.. these muiltiple implementations and also supporting WebXR!!
So what about an 'HTML Profile' for X3D that contains this greatest common denominator?
With X3Dv4, that would include glTF 2.0 content, but not the entire X3D specification (neither all glTF extensions). A draft of such a functional profile of standardized formats has been proposed in the Web3D Consortium for a Recommended Practice and could be ISO standardized in X3D 4.2 in the future. That would formalize the GCD in the model
tag and also bring in some 3D semantics (lighting, viewing, navigating, ...) to the UserAgent, which I believe we need. https://www.web3d.org/x3d/profiles https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/concepts.html
For maximal interoperability, the
<model>
spec should pick a single model format for browsers to all implement. (I'm not challenging the proposed API shape, with the<source type=...>
parameter: that enables future extensibility.)If there are already multiple formats with varying capabilities, such that none of them is strictly better than all the others, the specification should still list the types that may be supported and pick one lowest-common-denominator that all implementations must support.
If the browsers can't even agree on a lowest-common-denominator format, the specification should still list a set of formats that authors can provide that's guaranteed to cover all browsers. Arguably, it should require authors to provide options in all of those formats (by refusing to display the model if one of the
<source>
s is missing), but since authors could work around that by putting garbage URLs into the other<source>
s, I'm not sure that's worth it.I'm aware that the image and video elements fail to follow this advice: we shouldn't repeat that mistake for
<model>
.The text was updated successfully, but these errors were encountered: