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

Leonard Daly Leonard.Daly at realism.com
Thu Apr 13 20:02:21 PDT 2017


On 4/13/2017 6:55 PM, Michael Aratow wrote:
>
> 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?
>

[Usual caveats apply here -- this is a discussion of displaying 3D in a 
web browser environment using a declarative HTML-like language.]

Only one will end up surviving.

A-Frame is simple, easy to understand, and supported by some very large 
and influential organizations

X3D is complex, fully declarative, rich environment and is frequently 
never heard of or ignored.

A-Frame is not currently capable of handling (without coding) 
Geospatial, volume, CAD, metadata, and 3D printing (though it is usually 
the just the models that are printed).

A-Frame's component system isolates individual elements of the scene. It 
is difficult to impossible to build up a composite structure of multiple 
elements. In X3D this is done as a Transform containing another 
Transform containing ... So far, I have not found a way to even Group 
elements together; however, it may be beyond where my detailed reading 
has taken me so far.

So far, I believe that it is difficult (or impossible) to have your 
model in X3D and express it in A-Frame. I believe that it is possible to 
have a separate file that is just a model and load that (as geometry or 
geometry+texture). I think traditional X3D (rigid-body, key-frame) 
animation cannot be done in A-Frame on pieces of X3D models.

I am trying to get at the basic philosophy of X3D and A-Frame and see 
what use cases each cover and not cover.

A-Frame appears to put each element in a box. The elements can only 
change in pre-defined manners and two elements cannot merge. X3D is far 
more flexible in this regard. I don't know how I would handle certain 
types of visualization or user-controlled on-the-fly geometry changes or 
arbitrary network updates in A-Frame.


Leonard Daly



>
> 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
>
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org


-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170413/1b67ea0b/attachment-0001.html>


More information about the x3d-public mailing list