VR Renderer Tag

[tparisi]

Currently done using a <renderer> tag.

Should this be in a <meta> tag or other construct instead? It's not very webby to put the rendering choice in a tag. Simple, but not elegant. Think of other ways to do it.

Also, should this just be a "VR" rendering mode instead of "Cardboard" or "Rift" ? (Probably)

[psema4]

Haven't tried using multiple renderers on a single scene (or multiple scenes on a page); I'm wondering if a renderer attribute on the scene tag would work?

<scene renderer="vr">
    <stuff/>
</scene>

[tparisi]

@psema4 yes I've been thinking about that or actually on the top-level glam element itself... it wouldn't make much sense (to me) to mix renderers in one document.

This may also end up going into a meta tag. I'm open to suggestions.

[psema4]

Edited for clarity

Hypothetical use-case for multiple renderers: combining glam with WebRTC (p2p for the web) may allow peers to act like thin-clients.

In addition to the usual renderer (say of type="vr") the browser tab on the most-powerful machine (the application host)[1] could have a non-"vr" renderer connected to an outgoing WebRTC video stream.

The browser tab acting as the application host does the actual glam work & application processing. Other users and/or browsers and/or tabs (and/or chromecasts[2]) connected to the app watch the action; they might also communicate with the host using data channels, enabling massively-p2p experiences such as games[3] or tools[4]

[1] in practice the application host would more likely be the first browser tab to open the app
[2] also uses WebRTC; see also - Chromecast apps
[3] perhaps each spectator (website visitor) increases the difficulty of a level?
[4] real time collaborative world editing à la Cloud 9, Etherpad et al

[tparisi]

@psema4 I think I would do the multi-player WebRTC scenario differently, via API. I have now folded the whole Vizi framework directly into GLAM, essentially as the "GLAM engine." We could add network components to the engine, and use those to implement synchronizing scenes. Those components could be thin-client peer or client-server. I think this is a better way to go for multi-user apps.

[tparisi]

Folks for now I'm going to put this issue into the backlog; not necessary to have it figured out for the Alpha 2-VR milestone.