I have a very primitive example, but we should take a look at reusing others' previous solutions.

Maybe vr-carpet?

Enables devs to add models to their scenes.

Can specify:

• URL of model
• Scale (default is 1)
• Material (default is to display model's own materials. In future we might want to enable dev to specifying a different material to the template, which is copied to all children of the loaded object)

Most model scales are too large for VR. In the original vr-model component, the solution was to multiply the user-specified scale with an internal value. This was set to 0.01. This approach may not be correct, however. We may instead want to evangelize that devs model their scenes in units that work directly with VR's meter scale, without modification (1 to 1).

Can use pre-refactor vr-model component as one reference: https://github.com/MozVR/vr-components/blob/d455bfbfb60bb048906853f615f5af3431aa5bfb/core/vr-model.js

It would be nice to allow the color to be specified via attribute on the vr-text tag.

Moved from https://github.com/MozVR/vr-markup/issues/18 in vr-markup repo.

false by default. When set to true it inserts the hidden vr-objects into the DOM. Simulates collapsing / expanding the shadow DOM.

Enables devs to add skies to their scenes.

Dev can specify:

• URL of textures
• Radius (default should be very large (eg 5000) but less than default camera far clipping plane distance)
• Segments (number of times skybox box geometry is divided. Am not sure we need this).
• Color
• Effected by fog (boolean, default false)

URL of textures works as follows:

<a-skybox url="images/city/city">

The template then looks inside the directory specified for six images with the city filename and ending with top, bottom, left, right, front, back, respectively. Am not married to this implementation, but it worked well in the original pre-refactor skybox component.

By default the color is transparent, so that a PNG with transparency will appear comped against the background. When then user specifies a color value, the image instead appears comped against this color. The color is also visible while the image is being loaded, or if an image is not specified.

Same as #40, but for flat videos, so developer should also be able to specify width and height of the video.

We have core components as well in vr-markup. What about 'standard' components instead of core?

Enables devs to add images to their scenes.

Feature set is analogous to pre-refactor component. Dev can specify:

• URL of image to load
• Width / height (default is empty, and matches image width/height ratio, with max of 1m)
• Color (default empty (transparent))
• Opacity (default 1)

By default the color is transparent, so that a PNG with transparency will appear comped against the background. When then user specifies a color value, the image instead appears comped against this color.

While the image is loading, nothing is visible (can look at adding preloaders and/or placeholders in the future).

Enables devs to create 360° video players.

Features should be in line with what we had in pre-refactor <vr-video> and <vr-video360> components, and with the HTML5 <video> spec.

Dev can specify:

• Video source
• Autoplay boolean
• Looping boolean
• Height
• Width
• Muted boolean
• Controls boolean (shows or hides controls for playback)

Please add anything missing from the above. Looking at the <video> element spec, I'm not sure how important autobuffer, crossorigin, and poster are, for example.

While the image is loading, nothing is visible. Should look at adding preloaders and/or placeholders in the future.

My CC on file with npm changed. I updated with a new card, and npm shows me a success page and says everything's working. But when I go to npm publish after doing npm login with the mozvr account, no 🎲.

npm ERR! You need a paid account to perform this action. For more info, visit: https://www.npmjs.com/private-modules (2KB)

Here's a workaround until I hear back from npm support folks:

Simply git pull both projects and run these two npm link commands.

Enables devs to add cylinders to their scenes.

Dev can specify:

• Radius (default 0.5)
• Height (default 1)
• Radius segments (default 36)
• Height segments (default 4)
• Open ended (determines whether caps are added to the cylinder. Default true)

Enables devs to add audio to their scenes.

User can specify:

• Source URL
• Position of sound
• Bounding box and falloff (not sure how to articulate this in values)
• Loop / play-once
• User triggered (true/false. If true, sound is played when user enters bounding box)

@nickdesaulniers created a component for this under the original architecture. We may be able to re-use some of that logic?

Is dependent on (or related to?) https://github.com/MozVR/vr-markup/issues/255

Support this use case:

<vr-bigcubes>
  <vr-saturn></vr-saturn>
</vr-bigcubes>

Compenentise VRLoader — and possibly make it a third-party dependency.

Originally MozVR/vr-markup#138

Need to figure out a way to do this:

<template>
  <p>Hi, my name is ${name}.</p>
</template>

```js
var t = document.querySelector('template');
var newHTML = t.innerHTML.replace('${name}', 'seavan');  // This is equivalent to where we do string replacements for variables.

var d = document.createElement('div');
d.innerHTML = newHTML;
document.body.appendChild(d);

Code in <template> elements is not supposed to get executed (i.e., is not live). But because the <template> code has to be parsed to do string replacement.

Tried troubleshooting for quite some time but keep experiencing some race condition or something.

just need to do this:

THREE.ImageUtils.crossOrigin = '';

MozVR/vr-markup#151 needs to get fixed for this to work correctly (without hacks).

Enables devs to add skies to their scenes.

Dev can specify:

• URL of texture (equirectangular 2:1 will be the best practice)
• Radius (default should be very large (eg 5000) but less than default camera far clipping plane distance)
• Horizontal segments (lower priority. Can provide sane default initially)
• Vertical segments (lower priority. Can provide sane default initially)
• Color
• Effected by fog (boolean, default false)

By default the color is transparent, so that a PNG with transparency will appear comped against the background. When then user specifies a color value, the image instead appears comped against this color. The color is also visible while the image is being loaded, or if an image is not specified.

And reuse the same <video> element. Don't keep injecting new ones into the page. 👍

We should generate signed distance fields for crisp font rendering at all magnifications and orientations.

How it works today:

vr-components/examples/_templates/skysphere/vr-skysphere.html

<template is="vr-template" name="vr-skysphere" radius="5000" url="default.jpg">
  <vr-object geometry="primitive: sphere; segments: 54; radius: ${radius}" material="url: ${url}"></vr-object>
</template>

vr-components/examples/skysphere/index.html

<vr-skysphere position="0 0 0" url="../_images/panos/city.jpg"></vr-skysphere>

How it should work:

vr-components/examples/_templates/skysphere/vr-skysphere.html

<template is="vr-template" name="vr-skysphere" radius="5000" url="../../skysphere/default.jpg">
  <vr-object geometry="primitive: sphere; segments: 54; radius: ${radius}" material="url: ${url}"></vr-object>
</template>

If a url is passed from <vr-skysphere> instance, we use that URL relative to the location of the HTML document. That's what we're today, and that's fine.

But if a url is not passed and we use the default url defined in the import source, we should resolve those URLs from the location of the HTML import document.

I'm on the fence about making this change because it's kind of weird and inconsistent from a default vs override passed POV, but it is probably a more sane expected default. Perhaps we could accept some type of basepath attribute that would change the base root path of any URLs used inside the template definition. Thoughts?

So I don't have to manually add some HTML import. I just drop in the vr-components.js script, and they're magically there.

https://github.com/polymer/vulcanize is probably the best bet (fastest without HTTP/2) for now.

To aframe? Probably need to rename vr-markup to like aframe-core or something.

Also see MozVR/vr-markup#238.

/cc @jcarpenter

Enables devs to simply define an image with src and get a nice result. They can then either use scale or size attributes to adjust as desired.

Currently the defaults are:

var width = this.getAttribute('width', 10);
var height = this.getAttribute('height', 10);

We should wait until the image is loaded, derive the dimensions, create the geometry, then add to the scene.

It's almost ready:

https://github.com/mattdesl/budo/tree/next
https://www.npmjs.com/package/budo

Enables devs to add cubes to their scenes.

Dev can specify:

• Width (default 1)
• Height (default 1)
• Depth (default 1)

Enables the dev to add a grid to their scenes.

Dev can specify:

• Color (default is gray)
• Size (width and height of grid in meters. Default is 10)
• Density (number of horizontal and vertical segments in the grid. Default is 10).

Enables devs to add cylinders to their scenes.

Dev can specify:

• Radius (default .5)
• Horizontal segments (default 36)
• Height segments (default 18)

<vr-scene>
  <vr-box color="green" position="0 2 0" rotation="-45 45 0"></vr-box>
</vr-scene>

<vr-element name="vr-box">
  <template>
    <vr-object mixin="cube" position="${position}" rotation="${rotation}" material="color: ${color}"></vr-object>
  </template>
</vr-element>

results in this composed (rendered) DOM:

<vr-scene>
  <vr-box color="green">
    <vr-object mixin="cube"  position="0 2 0" rotation="-45 45 0" color="green"></vr-object>
  </vr-box>
</vr-scene>

<vr-element name="vr-box">
  <template>
    <vr-object mixin="cube" position="${position}" rotation="${rotation}" material="color: ${color}"></vr-object>
  </template>
</vr-element>

with shadow DOM, it could be:

<vr-scene>
  <vr-box color="green">
  </vr-box>
</vr-scene>

<vr-element name="vr-box">
  <template>
    <vr-object mixin="cube" position="${position}" rotation="${rotation}" material="color: ${color}"></vr-object>
  </template>
</vr-element>

this bug is to toggle the subtree not to use shadow DOM (which requires quite a hefty polyfill for non-Chrome browsers):

<vr-scene>
  <vr-box color="green" subtree="false"></vr-box>
</vr-scene>

<vr-element name="vr-box">
  <template>
    <vr-object mixin="cube" position="${position}" rotation="${rotation}" material="color: ${color}"></vr-object>
  </template>
</vr-element>

compared with the following:

<vr-scene>
  <vr-box color="green" subtree="true">
    <vr-object mixin="cube"  position="0 2 0" rotation="-45 45 0" color="green"></vr-object>
  </vr-box>
</vr-scene>

<vr-element name="vr-box">
  <template>
    <vr-object mixin="cube" position="${position}" rotation="${rotation}" material="color: ${color}"></vr-object>
  </template>
</vr-element>

Imported from vr-markup.

https://github.com/MozVR/vr-markup/issues/156

Please close if irrelevant.

In the vr-hemispherelight component, there's only a createdCallback, not a attributeChangedCallback.

ngokevin/aframe-core#237 introduced a new browserify transform for .glsl files.

Because our browserify build isn't using that transform, stuff breaks:

% npm start                                                      /opt/vr-components (master)

> @mozvr/[email protected] start /opt/vr-components
> npm run dev


> @mozvr/[email protected] dev /opt/vr-components
> npm run build && budo index.js:build/vr-components.js --debug -v --port 9000 --onupdate 'semistandard -v $(git ls-files '*.js') | snazzy' -- -s 'vr-components' -t browserify-css | garnish -v


> @mozvr/[email protected] build /opt/vr-components
> mkdir -p build/ && npm run browserify -- --debug -o build/vr-components.js


> @mozvr/[email protected] browserify /opt/vr-components
> browserify ./index.js -s 'vr-components' -t browserify-css "--debug" "-o" "build/vr-components.js"


/opt/vr-markup/src/shaders/pbrFragment.glsl:4
#define PI 3.14159265359
^
ParseError: Unexpected character '#'

[email protected] gets compiled 3 seperate times.
[email protected] twice
[email protected] twice

I think there's a way to share/squash deps on semver matches.

Enables a template dev to not have to define position, rotation and scale manually on their template definitions, reducing code bloat and eliminating a big foot gun for developer error.

Enables users of templates to rely on position, rotation and scale always being available, as fundamentals of our system.

Enables devs to add planes to their scenes.

Dev can specify:

• Width (default 1)
• Height (default 1)

Planes render "standing up", that is along the X any Y axes. To lie the plane down, the user must rotate it 90°.

May want to enable users to add segments also. eg:

• Horizontal segments (default 1)
• Vertical segments (default 1)

When I did that getAttribute patch, I made autoplay default to false for <vr-video> + <vr-video360>. The examples should at least be autoplay="true" instead of just autoplay. Should fix that.

https://github.com/MozVR/vr-components/blob/d455bf/core/vr-skybox.js#L41-L48

Should somehow pass in the patterns via some attributes on <vr-skybox>.