Best way to integrated argon and aframe

[blairmacintyre]

Right now, argon and aframe are integrated via a new scene, the ar-scene. This has the advantage that developers explicitly choose if they want VR (via a-scene) or AR (via ar-scene) and means the internal implementation and structure of the two scenes can be different.

However, separating the scenes makes a few things difficult

• it is harder to switch between AR and VR (or simply 3D-in-a-div) because the scene must change
• it makes it harder to repurpose existing A-Frame samples and demo code (perhaps this is minor)
• 3rd party components and extensions often search the DOM for an a-scene element, preventing them from working with argon (e.g., the inspector does this!)

There are two alternatives to the current implementation.

1) cause argon-aframe.js to override the methods in the a-scene object, causing it to work with argon and AR. This is perhaps the "simplest" but it means that once you load argon-aframe.js, you can no longer do VR.

2) cause argon-aframe.js to add new methods to the a-scene object, an analogous set of capabilities for AR as currently exist for VR (e.g., enterAR methods and events, etc, akin to the current enterVR ones). Additional methods/properties would allow the programmer to choose between AR and VR. If running in a browser that supports both, we could even put a second icon up beside the current "VR glasses" icon, to allow the end user to choose between AR and VR.

I'm curious what people think. I'm leaving toward implementing option 2. WebVR is moving toward supporting multiple kinds of displays, so we will eventually want AFrame to support having the user choose between different displays and modalities.

[jdbolter]

I don't understand the issues well enough to choose between 1 and 2. If you choose #2, what effect does that have on existing code that we have written, are writing for argon-aframe? Will we just have to substitute a-scene back in instead of ar-scene? Or do we have to rewrite components etc.?

[blairmacintyre]

Both (1) and (2) would require changing all ar-scene to a-scene. Both would also very likely require updating some components, but only those that depend on events that the scenes generate and other implementation specific (i.e., probably not too many).

My expectation is that whatever we do, if we integrate the ar-scene functionality back into a-scene we'll deprecate the old ar-scene. Which means, we'd keep it working for a while, but ask folks to transition to the new way of doing things.

Regardless, nobody needs to upgrade immediately, either.

For many things, just switching back to a-scene would be enough. If we go route (2), and you have custom components that rely on events like enterVR, or anything else we change the behavior of, you'd have to switch. But, we'll update all the samples as appropriate.

[speigg]

I think this issue is conflating two different things: view configuration (Magic Lens vs HMD), and the presented representation of "reality" (a virtual world vs "see-thru"). In my opinion, these things are orthogonal, and should probably not be managed together.

[speigg]

@blairmacintyre This comes back to the issue with the WebVR spec that you pointed me at earlier: https://github.com/w3c/webvr/issues/179

As I understand the WebVR api to work, the requestPresent function starts the process of getting sensor / pose updates (after getting permission from the user). The weakness in the current spec is that there is no way to ask for a particular "presentation context", i.e, (Magic Lens vs HMD), when calling "requestPresent". With AFrame, enterVR just wraps requestPresent under the hood. In other words, there isn't really a need for another method like enterAR, or at least, I don't see what it would do differently than what enterVR currently does (that is, start getting pose updates by calling requestPresent).

[blairmacintyre]

@speigg so, after talking about this all to you offline, I think we have a 3rd possibility: not changing the scene at all, and rather moving a lot of what was in ar-scene into an argon system, which replaces the a-scene.effect with a different one that deals with argon's rendering approach, and takes care of replacing the default camera (if it exists) with an ar-camera (that also follows argon's approach to managing the camera)

[irwinwilliams]

Hey @blairmacintyre just starting off in argon and aframe. It seems the inspector won't work if it's not a a-scene (VR) solution being built.

[blairmacintyre]

Yes. That is (mostly) fixed in the inspector repo, don't know when it will make it into the "standard" release. You might pull it from there and give it a try.

[blairmacintyre]

Essentially, a bunch of aframe components search for a div "a-scene" rather than looking in other ways (e.g. Aframe maintains a list of scenes). So, they fixed that for the inspector, to not look for a-scene. I still want someone to redo Argon-aframe to integrate more cleanly, I haven't have the time. But I think I know roughly how to do it.

[bossgenius54]

Hello guys?! I cannot find out a site where I could learn about argon js and how to integrity? Can you help me? please!

[blairmacintyre]

for argon.js, go to argonjs.io

for aframe and argon, all we have is what's here on this repo.