Moving controller models to a separate repo

[dmarcos]

During the WebVR spec face to face meeting we discussed about a way for developers to easily find models for the different controllers in the market, hands and other kinds of basic virtual tools. We debated whether it should be a new platform API or just an official CDN that contains all the models. A-Frame hosts the assets in the gh-pages of this repo (https://github.com/aframevr/assets/tree/gh-pages/controllers). In order for any library to benefit from those we could:

1. Move the models to a separate repo that it's not a-frame specific.
2. Define conventions for file names, model part names, format, license...
3. Decide where they should be hosted (gh-pages might fall short) and the url / domain schema to handle versioning.

What do you think? @feiss @fernandojsg @toji @ngokevin @TechnoBuddhist @machenmusik

[fernandojsg]

1. I agree, maybe we could start adding them to mozilla (mozilla/webvr-assets) account and then we could decide where to move them if we come with a nice custom organization name (webvr is already used :)?
2. I believe it would be easy to distribute the assets with a open CC license as most of the assets will be created by us or we'll encourage contributors to do so. Regarding the model part names we could follow the approach that @feiss did on the a-painter models naming them with a common prefix + lowercase + dash, like: button-a, button-b, button-trigger, button-trigger, body, ...
3. I'd start using gh-pages and then we could decide if host it somewhere else. Not everyone will use the assets through our CDN, some probably will just download and include them into their app.

[dmarcos]

We may want to decouple the repo where the assets live from the domain where they're hosted. That way it will be easy to move them around if there's need without breaking URLs

[feiss]

Everything sounds great to me 👍

1. Yup, not a-frame specific. Although I love the idea of Mozilla hosting them, maybe a new common repo for all parties would be more adequate? webvr is taken, some variation..
2. Assets could be available in most common web 3d formats (obj, xml, json, gltf..), and also maybe in different levels of detail (high/med/low?).

Folder structure could reflect both versioning and level of detail:

controllers/vive/1/low/
controllers/oculus/2/high/

about filenames, they could have all the same information, in case somebody downloads the file:
controllers/oculus/2/high/webvr-controller-oculus-2-high.json

About part names, they could be as most generic as possible, so it can be easily programmable:

body
body-detail1
body-detail2
button-primary
button-secondary
button-menu
button-system
...

It's difficult to find a common denominator for all parts, but it could be interesting to have many of them with the same name.

We may want to decouple the repo where the assets live from the domain where they're hosted. That way it will be easy to move them around if there's need without breaking URLs

Agree. webvr.info could be the baseurl, for example

[cvan]

Might want to take a look at these:

• https://github.com/posthtml/posthtml-urls
• https://github.com/skozin/webpack-path-rewriter
• https://github.com/bholloway/resolve-url-loader
• https://github.com/whitescape/uploadcare-loader
• https://github.com/mediocre/electricity
• https://github.com/lbovet/popsicle-rewrite
• https://github.com/seedalpha/express-url-rewrite
• https://github.com/benbria/aliasify

[TechnoBuddhist]

Naming conventions I’d go a bit further for future scope and make the convention controllers / platform / manufacturer / product-name / detail-level this allows for different controllers from different manufacturers for differing target platforms controllers/oculus/oculus/touch/low controllers/oculus/oculus/touch2/low - future version of touch from oculus(whatever they may call it) controllers/vive/thrustmaster/thrustyvr/low - new controller from thrustmaster this would cause dupes if the “thrustyvr” works on both oculus and vive! controllers/oculus/thrustmaster/thrustyvr/low controllers/vive/thrustmaster/thrustyvr/low possibly solved by linking or just leave as dup!? But it has future scope for open standards controllers/open/thrustmaster/…. Naming parts following from Diego’s thoughts, body-?? button-?? stick-?? dpad-?? touch-?? I agree having common names would be good, but taking a contra position the manufacturer has already named them so should we not just stick with their names? e.g. https://developer3.oculus.com/documentation/game-engines/latest/concepts/unity-ovrinput/ <https://developer3.oculus.com/documentation/game-engines/latest/concepts/unity-ovrinput/>

…

On 13 Jan 2017, at 20:04, Diego F. Goberna ***@***.***> wrote: Folder structure could reflect both versioning and level of detail: controllers/vive/1/low/ controllers/oculus/2/high/ about filenames, they could have all the same information, in case somebody downloads the file: controllers/oculus/2/high/webvr-controller-oculus-2-high.json About part names, they could be as most generic as possible, so it can be easily programmable: body body-detail1 body-detail2 button-primary button-secondary button-menu button-system ... It's difficult to find a common denominator for all parts, but it could be interesting to have many of them with the same name.

[machenmusik]

this would cause dupes if the “thrustyvr” works on both oculus and vive!

wouldn't the manufacturer of thrustyvr be (whatever non-oculus, non-htc company makes it) and nothing to do with oculus and vive? this is not about vr platform, this is about generic controller models right?

i.e. isn't it just controllers/thrustmaster/thrustyvr/low ?

[TechnoBuddhist]

Yup! My bad! Which makes it controllers / manufacturer / product-name / detail-level

[machenmusik]

you may want product version in the case where a later revision changes physical packaging slightly...