milestone 4l. manyfold.sh: add default 3D assets/templates from XR Fragments (milestone)
This commit is contained in:
parent
a354028b6a
commit
2c981e4060
4 changed files with 22 additions and 22 deletions
|
|
@ -829,7 +829,7 @@ It instances content (in objects) in the current scene/asset, and follows simila
|
|||
<tr>
|
||||
<td><code>src</code></td>
|
||||
<td>string (uri, hashtag/filter)</td>
|
||||
<td><code>#cube</code><br><code>#sometag</code><br>#cube&-ball_inside_cube<code><br></code>#-sky&-rain<code><br></code>#-language&english<code><br></code>#price=>5<code><br></code><a href="https://linux.org/penguin.png`">https://linux.org/penguin.png`</a><br><code>https://linux.world/distrowatch.gltf#t=1,100</code><br><code>linuxapp://conference/nixworkshop/apply.gltf#-cta&cta_apply</code><br><code>androidapp://page1?tutorial#pos=0,0,1&t1,100</code><br><code>foo.mp3#0,0,0</code></td>
|
||||
<td><code>#cube</code><br><code>#sometag</code><br>#cube&-ball_inside_cube<code><br></code>#-sky&-rain<code><br></code>#-language&english<code><br></code>#price=>5<code><br></code><a href="https://linux.org/penguin.png`">https://linux.org/penguin.png`</a><br><code>https://linux.world/distrowatch.gltf#t=1,100</code><br><code>linuxapp://conference/nixworkshop/apply.gltf#-cta&cta_apply</code><br><code>androidapp://page1?tutorial#room1&t1,100</code><br><code>foo.mp3#0,0,0</code></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -910,7 +910,7 @@ Resizing will be happen accordingly to its placeholder object <code>aquariumcube
|
|||
<tr>
|
||||
<td><code>href</code></td>
|
||||
<td>string (uri or predefined view)</td>
|
||||
<td><code>#room1</code><br><code>#pos=room1&rot=90,0,0</code><br><code>://somefile.gltf#room1</code><br></td>
|
||||
<td><code>#room1</code><br><code>#room1&rot=90,0,0</code><br><code>://somefile.gltf#room1</code><br></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -1593,9 +1593,9 @@ If a glTF implementation does not support a particular extension, the (XRF) extr
|
|||
</ol>
|
||||
|
||||
<blockquote>
|
||||
<p><strong>Example 1</strong> In case of the OMI_LINK glTF extension (<code>href: https://nlnet.nl</code>) and an XR Fragment (<code>href: #pos=otherroom</code> or <code>href: otherplanet.glb</code>), it is clear that <code>https://nlnet.nl</code> should open in a browsertab, whereas the XR Fragment links should teleport the user. If the OMI_LINK contains an XR Fragment (<code>#pos=</code> e.g.) a teleport should be performed only (and other [overlapping] metadata should be ignored).</p>
|
||||
<p><strong>Example 1</strong> In case of the OMI_LINK glTF extension (<code>href: https://nlnet.nl</code>) and an XR Fragment (<code>href: #otherroom</code> or <code>href: otherplanet.glb</code>), it is clear that <code>https://nlnet.nl</code> should open in a browsertab, whereas the XR Fragment links should teleport the user. If the OMI_LINK contains an XR Fragment (<code>#room1</code> e.g.) a teleport should be performed only (and other [overlapping] metadata should be ignored).</p>
|
||||
|
||||
<p><strong>Example 2</strong> If an Extensions uses XR Fragments in URI’s (<code>href: #pos=otherroom</code> or <code>href: xrf://-walls</code> in OMI_LINK e.g.), then perform them according to XR Fragment spec (teleport user). But only once: ignore further overlapping metadata for that usecase.</p>
|
||||
<p><strong>Example 2</strong> If an Extensions uses XR Fragments in URI’s (<code>href: #otherroom</code> or <code>href: xrf://-walls</code> in OMI_LINK e.g.), then perform them according to XR Fragment spec (teleport user). But only once: ignore further overlapping metadata for that usecase.</p>
|
||||
</blockquote>
|
||||
|
||||
<h2 id="vendor-prefixes">Vendor Prefixes</h2>
|
||||
|
|
|
|||
|
|
@ -506,7 +506,7 @@ It instances content (in objects) in the current scene/asset, and follows simila
|
|||
|
||||
| fragment | type | example value |
|
||||
|----------|------|---------------|
|
||||
|`src`| string (uri, hashtag/filter) | `#cube`<br>`#sometag`<br>#cube&-ball_inside_cube`<br>`#-sky&-rain`<br>`#-language&english`<br>`#price=>5`<br>`https://linux.org/penguin.png`<br>`https://linux.world/distrowatch.gltf#t=1,100`<br>`linuxapp://conference/nixworkshop/apply.gltf#-cta&cta_apply`<br>`androidapp://page1?tutorial#pos=0,0,1&t1,100`<br>`foo.mp3#0,0,0`|
|
||||
|`src`| string (uri, hashtag/filter) | `#cube`<br>`#sometag`<br>#cube&-ball_inside_cube`<br>`#-sky&-rain`<br>`#-language&english`<br>`#price=>5`<br>`https://linux.org/penguin.png`<br>`https://linux.world/distrowatch.gltf#t=1,100`<br>`linuxapp://conference/nixworkshop/apply.gltf#-cta&cta_apply`<br>`androidapp://page1?tutorial#room1&t1,100`<br>`foo.mp3#0,0,0`|
|
||||
|
||||
Here's an ascii representation of a 3D scene-graph with 3D objects `◻` which embeds remote & local 3D objects `◻` with/out using filters:
|
||||
|
||||
|
|
@ -569,7 +569,7 @@ navigation, portals & mutations
|
|||
|
||||
| fragment | type | example value |
|
||||
|----------|---------------------------------|---------------------------------------------------------------------------------------------------------------------------|
|
||||
|`href` | string (uri or predefined view) | `#room1`<br>`#pos=room1&rot=90,0,0`<br>`://somefile.gltf#room1`<br> |
|
||||
|`href` | string (uri or predefined view) | `#room1`<br>`#room1&rot=90,0,0`<br>`://somefile.gltf#room1`<br> |
|
||||
|
||||
1. clicking an outbound ''external''- or ''file URI'' fully replaces the current scene and assumes `room2&rot=0,0,0` by default (unless specified)
|
||||
|
||||
|
|
@ -1055,9 +1055,9 @@ This approach aligns with the idea that extensions are more likely to be interpr
|
|||
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).
|
||||
> **Example 1** In case of the OMI_LINK glTF extension (`href: https://nlnet.nl`) and an XR Fragment (`href: #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 (`#room1` e.g.) a teleport should be performed only (and other [overlapping] metadata should be ignored).
|
||||
|
||||
> **Example 2** If an Extensions uses XR Fragments in URI's (`href: #pos=otherroom` or `href: xrf://-walls` in OMI_LINK e.g.), then perform them according to XR Fragment spec (teleport user). But only once: ignore further overlapping metadata for that usecase.
|
||||
> **Example 2** If an Extensions uses XR Fragments in URI's (`href: #otherroom` or `href: xrf://-walls` in OMI_LINK e.g.), then perform them according to XR Fragment spec (teleport user). But only once: ignore further overlapping metadata for that usecase.
|
||||
|
||||
## Vendor Prefixes
|
||||
|
||||
|
|
|
|||
|
|
@ -1021,7 +1021,7 @@ Internet-Draft XR Fragments September 2025
|
|||
| | |https://linux.world/distrowatch.gltf#t=1,100 |
|
||||
| | |linuxapp://conference/nixworkshop/apply.gltf#- |
|
||||
| | |cta&cta_apply |
|
||||
| | |androidapp://page1?tutorial#pos=0,0,1&t1,100 |
|
||||
| | |androidapp://page1?tutorial#room1&t1,100 |
|
||||
| | |foo.mp3#0,0,0 |
|
||||
+--------+--------+---------------------------------------------------+
|
||||
|
||||
|
|
@ -1142,7 +1142,7 @@ Internet-Draft XR Fragments September 2025
|
|||
| fragment | type | example value |
|
||||
+==========+==================+========================+
|
||||
| href | string (uri or | #room1 |
|
||||
| | predefined view) | #pos=room1&rot=90,0,0 |
|
||||
| | predefined view) | #room1&rot=90,0,0 |
|
||||
| | | ://somefile.gltf#room1 |
|
||||
+----------+------------------+------------------------+
|
||||
|
||||
|
|
@ -2002,11 +2002,11 @@ Internet-Draft XR Fragments September 2025
|
|||
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]
|
||||
| https://nlnet.nl) and an XR Fragment (href: #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 (#room1 e.g.) a
|
||||
| teleport should be performed only (and other [overlapping]
|
||||
| metadata should be ignored).
|
||||
|
|
||||
|
||||
|
|
@ -2019,9 +2019,9 @@ Internet-Draft XR Fragments September 2025
|
|||
|
||||
|
||||
| *Example 2* If an Extensions uses XR Fragments in URI's (href:
|
||||
| #pos=otherroom or href: xrf://-walls in OMI_LINK e.g.), then
|
||||
| perform them according to XR Fragment spec (teleport user). But
|
||||
| only once: ignore further overlapping metadata for that usecase.
|
||||
| #otherroom or href: xrf://-walls in OMI_LINK e.g.), then perform
|
||||
| them according to XR Fragment spec (teleport user). But only
|
||||
| once: ignore further overlapping metadata for that usecase.
|
||||
|
||||
28.3. Vendor Prefixes
|
||||
|
||||
|
|
|
|||
|
|
@ -706,7 +706,7 @@ It instances content (in objects) in the current scene/asset, and follows simila
|
|||
#cube&-ball_inside_cube<tt><br></tt>#-sky&-rain<tt><br></tt>#-language&english<tt><br></tt>#price=>5<tt><br></tt><eref target="https://linux.org/penguin.png`">https://linux.org/penguin.png`</eref><br />
|
||||
<tt>https://linux.world/distrowatch.gltf#t=1,100</tt><br />
|
||||
<tt>linuxapp://conference/nixworkshop/apply.gltf#-cta&cta_apply</tt><br />
|
||||
<tt>androidapp://page1?tutorial#pos=0,0,1&t1,100</tt><br />
|
||||
<tt>androidapp://page1?tutorial#room1&t1,100</tt><br />
|
||||
<tt>foo.mp3#0,0,0</tt></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -788,7 +788,7 @@ Resizing will be happen accordingly to its placeholder object <tt>aquariumcube</
|
|||
<td><tt>href</tt></td>
|
||||
<td>string (uri or predefined view)</td>
|
||||
<td><tt>#room1</tt><br />
|
||||
<tt>#pos=room1&rot=90,0,0</tt><br />
|
||||
<tt>#room1&rot=90,0,0</tt><br />
|
||||
<tt>://somefile.gltf#room1</tt><br />
|
||||
</td>
|
||||
</tr>
|
||||
|
|
@ -1405,8 +1405,8 @@ This approach aligns with the idea that extensions are more likely to be interpr
|
|||
<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>
|
||||
<t><strong>Example 2</strong> If an Extensions uses XR Fragments in URI's (<tt>href: #pos=otherroom</tt> or <tt>href: xrf://-walls</tt> in OMI_LINK e.g.), then perform them according to XR Fragment spec (teleport user). But only once: ignore further overlapping metadata for that usecase.</t>
|
||||
<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: #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>#room1</tt> e.g.) a teleport should be performed only (and other [overlapping] metadata should be ignored).</t>
|
||||
<t><strong>Example 2</strong> If an Extensions uses XR Fragments in URI's (<tt>href: #otherroom</tt> or <tt>href: xrf://-walls</tt> in OMI_LINK e.g.), then perform them according to XR Fragment spec (teleport user). But only once: ignore further overlapping metadata for that usecase.</t>
|
||||
</blockquote></section>
|
||||
|
||||
<section anchor="vendor-prefixes"><name>Vendor Prefixes</name>
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue