<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From: Leonard Daly <<a href="mailto:Leonard.Daly@realism.com">Leonard.Daly@realism.com</a>><br>
To: <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br><br>
A-Frame's VR capability (as all of its rendering capability) is provided<br>
by Three.js. I know that Unreal has rather extensive VR (Rift, Vive)<br>
headset capability. I believe that Unity does too. Since the focus for<br>
this talk was on browser-based VR, I couldn't spend the time addressing<br>
VR capabilities of these platforms.<br>
<br></blockquote><div><br></div><div>True, A-Frame only provides the declarative DOM layer, and three does all the rendering.</div><div><br></div><div>Unity can export to webgl but I do not know if or how it supports webvr.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> Did you get feedback after your presentation ? Anything you can share<br>
> would be interesting.<br>
<br>
Nothing significant. There was more in discussions with other attendees<br>
at the conference who did not see my presentation. I'll be posting that<br>
over the next month or so.<br></blockquote><div><br></div><div>ok. thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> The idea of combining of x3dom and A-Frame somehow is interesting. I<br>
> think it would boil down to implementing a new x3d browser on top of<br>
> A-Frame which may be quite possible. I experimented by reimplementing<br>
> IndexedFaceSet and ElevationGrid in A-Frame and think that geometry<br>
> and material nodes could be quite straightforward. Not sure about<br>
> everything else but probably possible with a lot of work. It also<br>
> would mean having a SAI on top of the DOM (as being manipulated by<br>
> A-Frame and custom event interfaces). Your presentation made a good<br>
> argument that there is a lot of value in having a wide set of<br>
> standardized capabilites.<br>
<br>
Personally, I think putting X3DOM on top of A-Frame is a bit like<br>
inverting a pyramid. A-Frame (as defined, not extended) is a rather<br>
limited-capability system. I think it would be much easier to put<br>
A-Frame on top of X3DOM -- except the part with A-Frame extensions. I<br>
think a better choice is to merge the two keeping the most important<br>
capabilities of both. I am formulating some ideas on that.<br>
<br></blockquote><div><br></div><div>Well, the idea of A-Frame is to be extensible with the hope that over time enough functionality emerges so it becomes truly easy to use.</div><div><br></div><div>A-Frame takes care of parsing html (using html5 custom elements API I believe), helps with defining nodes, and provides rendering and interaction basics. To me it does sound like a good intermediate layer between three and x3d. And it exists. Of course, then all elements have to start with 'a-'.</div><div><br></div><div>-Andreas</div><div> <br></div></div>
</div></div>