[x3d-public] X3DOM and Three.js

yottzumm at gmail.com yottzumm at gmail.com
Tue Apr 11 16:01:47 PDT 2017


Here are my modifications to three-x3d-loader.  The only new feature is JSON loading and some bug fixes.  This is my first loader which does not go through DOM first, so beware! https://github.com/coderextreme/three-x3d-loader  It requires a git client, and node (installing with npm and running JavaScript applications).  Instructions are near the bottom of the README.md

John

Sent from Mail for Windows 10

From: Andreas Plesch
Sent: Tuesday, April 11, 2017 5:08 PM
To: Leonard Daly
Cc: X3D Graphics public mailing list
Subject: Re: [x3d-public] X3DOM and Three.js

Date: Tue, 11 Apr 2017 11:10:49 -0700
From: Leonard Daly <Leonard.Daly at realism.com>

...
There is an X3D loader for Three
(https://github.com/jonaskello/three-x3d-loader); however, it's node set
is very limited (e.g., no animation) and it does not appear to provide a
DOM interface.

There is also a vrml parser and  loader: https://github.com/mrdoob/three.js/pull/10371

John Carlson mentioned he had one, but I am not sure if
it meets the DOM interface requirements. Johannes mentioned that they
looked into Three as a renderer, but at the time there were too many
differences between X3D and how Three handled the scene graph and
rendered the result.

Initial Requirements
1) Use Three.js for all rendering
2) Provides DOM interface to X3D scene
3) Handle most X3D nodes
4) Easy to add new nodes or features (see A-Frame for an example of "easy")

 
The application needs to be able to run in the DOM and construct a scene
graph using Three from X3D tags (nodes) in the HTML file. In general all
tags and attributes (nodes and fields) need to be accessible from DOM
(both read and write). Internal animations (TimeSensor --> Interpolator
--> TargetNode) need to work.

So far my preliminary investigation indicates that the problem is
doable. The difficult part appears to be parsing the nodes In the HTML
file and keeping the DOM reference from the node to the Three object.

Hm, sounds like a job for A-Frame which does the parsing (or registration of new elements with the browser) and linking from DOM to Three.
 
I
have no idea of the performance would be, though it does need to be near
90 fps (browser willing).

Three is well optimized but it may come down to limiting geometry and using shaders well.
 
Does anyone have any insights, comments, or thoughts on such an application?

A lot depends on the time frame and available resources/man power. 
Starting from scratch using modern JS and web APIs, repurposing pieces from x3dom, cobweb, or a-frame, building on top of a-frame, or trying to incrementally adapt x3dom to three.js are all options. I would favor the last two if relatively fast results (< one year) with limited resources are expected but x3dom is aging somewhat and using a-frame will require non x3d node names (or a a-X3D spec.).

-Andreas

--
*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/20170411/6a50e9c7/attachment-0001.html>

------------------------------

Message: 4
Date: Tue, 11 Apr 2017 14:22:56 -0400
From: <yottzumm at gmail.com>
To: Leonard Daly <Leonard.Daly at realism.com>, X3D Public
        <x3d-public at web3d.org>
Subject: Re: [x3d-public] X3DOM and Three.js
Message-ID: <58ed1efe.9468370a.a7d9d.2cf4 at mx.google.com>
Content-Type: text/plain; charset="utf-8"

My plan for X3D JSON is to use the Proxy object and avoid the DOM.  I suggest we add an attribute that says ?SETTABLE? and ?GETTABLE? as two fields of each object so that we don?t overload the Proxy object with a bunch of changes.

If you want something that interacts with the DOM, go for it.  I will report on modifications to three-x3d-loader later.  It uses another variety of JSON, but converts the JSON to DOM.   I don?t know if it has observers or not.

John
Sent from Mail for Windows 10

From: Leonard Daly
Sent: Tuesday, April 11, 2017 2:11 PM
To: X3D Public
Subject: [x3d-public] X3DOM and Three.js

I would like to have an application that merged X3DOM and Three.js. The specific requirements are below. I would like to use this to easily handle X3D declarative data and the ability to investigate additional capabilities that are included in Three (animation, shaders, rendering, VR, etc.). There are also many tools that work in conjunction with Three that would be nice to use at various times. I also want to have the DOM interaction provided by X3DOM.
There is an X3D loader for Three (https://github.com/jonaskello/three-x3d-loader); however, it's node set is very limited (e.g., no animation) and it does not appear to provide a DOM interface. John Carlson mentioned he had one, but I am not sure if it meets the DOM interface requirements. Johannes mentioned that they looked into Three as a renderer, but at the time there were too many differences between X3D and how Three handled the scene graph and rendered the result.
Initial Requirements
1) Use Three.js for all rendering
2) Provides DOM interface to X3D scene
3) Handle most X3D nodes
4) Easy to add new nodes or features (see A-Frame for an example of "easy")
The application needs to be able to run in the DOM and construct a scene graph using Three from X3D tags (nodes) in the HTML file. In general all tags and attributes (nodes and fields) need to be accessible from DOM (both read and write). Internal animations (TimeSensor --> Interpolator --> TargetNode) need to work.
So far my preliminary investigation indicates that the problem is doable. The difficult part appears to be parsing the nodes In the HTML file and keeping the DOM reference from the node to the Three object. I have no idea of the performance would be, though it does need to be near 90 fps (browser willing).
Does anyone have any insights, comments, or thoughts on such an application?
--
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/20170411/d336c679/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org


------------------------------

End of x3d-public Digest, Vol 97, Issue 24
******************************************




-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170411/179338f0/attachment.html>


More information about the x3d-public mailing list