coderofsalvation
/
xrfragment
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

main: update documentation

This commit is contained in:
Leon van Kammen 2024-09-25 10:55:11 +02:00
parent f865c22694
commit 91b08014fa
5 changed files with 59 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
doc/RFC_XR_Fragments.html
View File

@ -86,6 +86,9 @@ XR Fragments allows us to better use existing metadata inside 3D scene(files), b
XR Fragments views spatial webs thru the lens of 3D scene URI&rsquo;s, rather than thru code(frameworks) or protocol-specific browsers (webbrowser e.g.).</p>
<blockquote>
<p>XR Fragments is a <b>Meta scene format</b> which leverages heuristic rules derived from any 3D scene or well-established 3D file formats, to extract meaningful features from scene hierarchies.<br>
These heuristics, enable features that are both meaningful and consistent across different scene representations, allowing <b>higher interop</b> between fileformats, 3D editors, viewers and game-engines.</p>
<p>Almost every idea in this document is demonstrated at <a href="https://xrfragment.org">https://xrfragment.org</a></p>
</blockquote>
<section data-matter="main">
@ -1517,13 +1520,13 @@ For example, GLTF has the <code>OMI_LINK</code> extension which might overlap wi
<p>Priority Order and Precedence, otherwise fallback applies</p>
</blockquote>
<p>1.Extensions Take Precedence: Since glTF-specific extensions are designed with the format’s
<p>1.<strong>Extensions Take Precedence</strong>: Since glTF-specific extensions are designed with the format’s
specific needs and optimizations in mind, they should take precedence over extras metadata
in cases where both contain overlapping functionality.
This approach aligns with the idea that extensions are more likely to be interpreted uniformly by glTF-compatible software.</p>
<ol start="3">
<li>Fallback Fall-through Mechanism:
<ol start="2">
<li><strong>Fallback Fall-through Mechanism</strong>:
If a glTF implementation does not support a particular extension, the (XRF) extras field can serve as a fallback. This way, metadata provided in extras can still be useful for applications that don&rsquo;t handle certain extensions.</li>
</ol>

7
doc/RFC_XR_Fragments.md
View File

@ -98,6 +98,9 @@ The specification uses [W3C Media Fragments](https://www.w3.org/TR/media-frags/)
XR Fragments allows us to better use existing metadata inside 3D scene(files), by connecting it to proven technologies like [URI Fragments](https://en.wikipedia.org/wiki/URI_fragment).<br>
XR Fragments views spatial webs thru the lens of 3D scene URI's, rather than thru code(frameworks) or protocol-specific browsers (webbrowser e.g.).
> XR Fragments is a <b>Meta scene format</b> which leverages heuristic rules derived from any 3D scene or well-established 3D file formats, to extract meaningful features from scene hierarchies.<br>
These heuristics, enable features that are both meaningful and consistent across different scene representations, allowing <b>higher interop</b> between fileformats, 3D editors, viewers and game-engines.
> Almost every idea in this document is demonstrated at [https://xrfragment.org](https://xrfragment.org)
{mainmatter}
@ -963,12 +966,12 @@ For example, GLTF has the `OMI_LINK` extension which might overlap with XR Fragm
> Priority Order and Precedence, otherwise fallback applies
1.Extensions Take Precedence: Since glTF-specific extensions are designed with the format’s
1.**Extensions Take Precedence**: Since glTF-specific extensions are designed with the format’s
specific needs and optimizations in mind, they should take precedence over extras metadata
in cases where both contain overlapping functionality.
This approach aligns with the idea that extensions are more likely to be interpreted uniformly by glTF-compatible software.
3. Fallback Fall-through Mechanism:
2. **Fallback Fall-through Mechanism**:
If a glTF implementation does not support a particular extension, the (XRF) extras field can serve as a fallback. This way, metadata provided in extras can still be useful for applications that don't handle certain extensions.
> **Example 1** In case of the OMI_LINK glTF extension (`href: https://nlnet.nl`) and an XR Fragment (`href: #pos=otherroom` or `href: otherplanet.glb`), it is clear that `https://nlnet.nl` should open in a browsertab, whereas the XR Fragment links should teleport the user. If the OMI_LINK contains an XR Fragment (`#pos=` e.g.) a teleport should be performed only (and other [overlapping] metadata should be ignored).

54
doc/RFC_XR_Fragments.txt
View File

@ -28,6 +28,14 @@ Abstract
rather than thru code(frameworks) or protocol-specific browsers
(webbrowser e.g.).
XR Fragments is a <b>Meta scene format</b> which leverages heuristic
rules derived from any 3D scene or well-established 3D file formats,
to extract meaningful features from scene hierarchies.
These heuristics, enable features that are both meaningful and
consistent across different scene representations, allowing <b>higher
interop</b> between fileformats, 3D editors, viewers and game-
engines.
Almost every idea in this document is demonstrated at
https://xrfragment.org (https://xrfragment.org)
@ -41,14 +49,6 @@ Status of This Memo
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 March 2025.
@ -58,6 +58,13 @@ van Kammen Expires 29 March 2025 [Page 1]
Internet-Draft XR Fragments September 2024
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 March 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
@ -99,13 +106,6 @@ Table of Contents
15.1. including/excluding . . . . . . . . . . . . . . . . . . 23
15.2. Filter Parser . . . . . . . . . . . . . . . . . . . . . 24
16. Visible links . . . . . . . . . . . . . . . . . . . . . . . . 25
17. Text in XR (tagging,linking to spatial objects) . . . . . . . 25
17.1. Default Data URI mimetype . . . . . . . . . . . . . . . 28
17.2. URL and Data URI . . . . . . . . . . . . . . . . . . . . 29
18. Importing/exporting . . . . . . . . . . . . . . . . . . . . . 30
19. Reflection Mapping . . . . . . . . . . . . . . . . . . . . . 30
20. Transclusion (broken link) resolution . . . . . . . . . . . . 30
21. Topic-based index-less Webrings . . . . . . . . . . . . . . . 31
@ -114,6 +114,13 @@ van Kammen Expires 29 March 2025 [Page 2]
Internet-Draft XR Fragments September 2024
17. Text in XR (tagging,linking to spatial objects) . . . . . . . 25
17.1. Default Data URI mimetype . . . . . . . . . . . . . . . 28
17.2. URL and Data URI . . . . . . . . . . . . . . . . . . . . 29
18. Importing/exporting . . . . . . . . . . . . . . . . . . . . . 30
19. Reflection Mapping . . . . . . . . . . . . . . . . . . . . . 30
20. Transclusion (broken link) resolution . . . . . . . . . . . . 30
21. Topic-based index-less Webrings . . . . . . . . . . . . . . . 31
22. URI Templates (RFC6570) . . . . . . . . . . . . . . . . . . . 32
23. Additional scene metadata . . . . . . . . . . . . . . . . . . 32
24. Accessibility interface . . . . . . . . . . . . . . . . . . . 33
@ -156,13 +163,6 @@ Internet-Draft XR Fragments September 2024
5. the gap between text an 3d objects: object-names directly map to
hashtags (=fragments), which allows 3D to text transcription.
| NOTE: The chapters in this document are ordered from highlevel to
| lowlevel (technical) as much as possible
van Kammen Expires 29 March 2025 [Page 3]
@ -170,6 +170,9 @@ van Kammen Expires 29 March 2025 [Page 3]
Internet-Draft XR Fragments September 2024
| NOTE: The chapters in this document are ordered from highlevel to
| lowlevel (technical) as much as possible
2. Core principle
*XR Fragments allows controlling 3D models using URLs, based on
@ -218,9 +221,6 @@ Internet-Draft XR Fragments September 2024
van Kammen Expires 29 March 2025 [Page 4]
Internet-Draft XR Fragments September 2024
@ -1914,14 +1914,14 @@ Internet-Draft XR Fragments September 2024
| Priority Order and Precedence, otherwise fallback applies
1.Extensions Take Precedence: Since glTF-specific extensions are
1.*Extensions Take Precedence*: Since glTF-specific extensions are
designed with the format’s specific needs and optimizations in mind,
they should take precedence over extras metadata in cases where both
contain overlapping functionality. This approach aligns with the
idea that extensions are more likely to be interpreted uniformly by
glTF-compatible software.
3. Fallback Fall-through Mechanism: If a glTF implementation does
2. *Fallback Fall-through Mechanism*: If a glTF implementation does
not support a particular extension, the (XRF) extras field can
serve as a fallback. This way, metadata provided in extras can
still be useful for applications that don't handle certain

9
doc/RFC_XR_Fragments.xml
View File

@ -17,6 +17,9 @@ The specification uses <eref target="https://www.w3.org/TR/media-frags/">W3C Med
XR Fragments allows us to better use existing metadata inside 3D scene(files), by connecting it to proven technologies like <eref target="https://en.wikipedia.org/wiki/URI_fragment">URI Fragments</eref>.<br />
XR Fragments views spatial webs thru the lens of 3D scene URI's, rather than thru code(frameworks) or protocol-specific browsers (webbrowser e.g.).</t>
<t>XR Fragments is a &lt;b&gt;Meta scene format&lt;/b&gt; which leverages heuristic rules derived from any 3D scene or well-established 3D file formats, to extract meaningful features from scene hierarchies.<br />
These heuristics, enable features that are both meaningful and consistent across different scene representations, allowing &lt;b&gt;higher interop&lt;/b&gt; between fileformats, 3D editors, viewers and game-engines.</t>
<t>Almost every idea in this document is demonstrated at <eref target="https://xrfragment.org">https://xrfragment.org</eref></t>
</abstract>
@ -1351,13 +1354,13 @@ Therefore a 2-button navigation-interface is the bare minimum interface:</t>
What if the functionality of those overlap?
For example, GLTF has the <tt>OMI_LINK</tt> extension which might overlap with XR Fragment's <tt>href</tt>:</t>
<blockquote><t>Priority Order and Precedence, otherwise fallback applies</t>
</blockquote><t>1.Extensions Take Precedence: Since glTF-specific extensions are designed with the format’s
</blockquote><t>1.<strong>Extensions Take Precedence</strong>: Since glTF-specific extensions are designed with the format’s
specific needs and optimizations in mind, they should take precedence over extras metadata
in cases where both contain overlapping functionality.
This approach aligns with the idea that extensions are more likely to be interpreted uniformly by glTF-compatible software.</t>
<ol spacing="compact" start="3">
<li>Fallback Fall-through Mechanism:
<ol spacing="compact" start="2">
<li><strong>Fallback Fall-through Mechanism</strong>:
If a glTF implementation does not support a particular extension, the (XRF) extras field can serve as a fallback. This way, metadata provided in extras can still be useful for applications that don't handle certain extensions.</li>
</ol>
<blockquote><t><strong>Example 1</strong> In case of the OMI_LINK glTF extension (<tt>href: https://nlnet.nl</tt>) and an XR Fragment (<tt>href: #pos=otherroom</tt> or <tt>href: otherplanet.glb</tt>), it is clear that <tt>https://nlnet.nl</tt> should open in a browsertab, whereas the XR Fragment links should teleport the user. If the OMI_LINK contains an XR Fragment (<tt>#pos=</tt> e.g.) a teleport should be performed only (and other [overlapping] metadata should be ignored).</t>

27
index.html
View File

File diff suppressed because one or more lines are too long