[x3d-public] Presentation from SVVR2017 (Leonard Daly)

[Michael Aratow]

Do we really need to have both A-Frame and X3D?  This seems to be making 
things unnecessarily complicated for VR content authors. Either one or 
the other or something that is a combination of the two?


On 4/11/17 12:57 PM, Andreas Plesch wrote:
>
>     From: Leonard Daly <Leonard.Daly at realism.com
>     <mailto:Leonard.Daly at realism.com>>
>     To: x3d-public at web3d.org <mailto:x3d-public at web3d.org>
>
>     A-Frame's VR capability (as all of its rendering capability) is
>     provided
>     by Three.js. I know that Unreal has rather extensive VR (Rift, Vive)
>     headset capability. I believe that Unity does too. Since the focus for
>     this talk was on browser-based VR, I couldn't spend the time
>     addressing
>     VR capabilities of these platforms.
>
>
> True, A-Frame only provides the declarative DOM layer, and three does 
> all the rendering.
>
> Unity can export to webgl but I do not know if or how it supports webvr.
>
>     >
>     > Did you get feedback after your presentation ? Anything you can
>     share
>     > would be interesting.
>
>     Nothing significant. There was more in discussions with other
>     attendees
>     at the conference who did not see my presentation. I'll be posting
>     that
>     over the next month or so.
>
>
> ok. thanks.
>
>     >
>     > The idea of combining of x3dom and A-Frame somehow is interesting. I
>     > think it would boil down to implementing a new x3d browser on top of
>     > A-Frame which may be quite possible. I experimented by
>     reimplementing
>     > IndexedFaceSet and ElevationGrid in A-Frame and think that geometry
>     > and material nodes could be quite straightforward. Not sure about
>     > everything else but probably possible with a lot of work. It also
>     > would mean having a SAI on top of the DOM (as being manipulated by
>     > A-Frame and custom event interfaces). Your presentation made a good
>     > argument that there is a lot of value in having a wide set of
>     > standardized capabilites.
>
>     Personally, I think putting X3DOM on top of A-Frame is a bit like
>     inverting a pyramid. A-Frame (as defined, not extended) is a rather
>     limited-capability system. I think it would be much easier to put
>     A-Frame on top of X3DOM -- except the part with A-Frame extensions. I
>     think a better choice is to merge the two keeping the most important
>     capabilities of both. I am formulating some ideas on that.
>
>
> 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.
>
> 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-'.
>
> -Andreas
>
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170413/37f17f05/attachment.html>