[x3d-public] Announcing XSeen

John Carlson yottzumm at gmail.com
Tue May 30 00:48:02 PDT 2017

I have code for that in X3DJSONLD.js, but it doesn’t work very well yet in X3DOM (works fine in Cobweb), so it’s commented out.  Here it is. I attach the Inline to the parent of the Inline, instead of the scene element, I believe. I believe I have a problem with figuring out the right URL to load, so look at loadURLs and especially processURLs with it—I believe these are best left to X3DOM and Cobweb though.  Patching the code to load the right URL based on a parent would go a long way to fixing my code-loading the right URL is pretty much always an issue, and it would be nice if it was built into the browser itself.  I can work on it if you want, if XML -> JSON is not a priority.

                } else if (key === 'Inline') {
                        var localArray = object[key]["@url"];
                        console.error("Loading", localArray, "at", path, "into", key);
                        loadURLs(path, localArray, function(jsobj, path) {
                                // console.error("Read", jsobj);
                                try {
                                        // console.error("Loading", jsobj, "into inline");
                                        var child = document.createDocumentFragment();
                                        ConvertToX3DOM(jsobj, "-children", child, path);
                                } catch(e) {
                                        // if JSON parse failed, it might be XML or WRL
                                        var child = CreateElement(key, x3djsonNS, containerField);
                                        // console.error("Reloading", object[key]["@url"].join('","').replace(/\.json/g, '.x3d').split(/","/));
                                        ConvertToX3DOM(object[key], key, child, path);

I don’t believe I need this in Cobweb (loadURLs and processURLs is not present), because Inlines are handled separately from the JSON parsing.  I believe that cobweb/X3DJSONLD can load a JSON URL for XML, or an XML URL for JSON.

Speaking of this, I am just realizing that Inlines in the above code will not go through normal schema processing (WHOOPS!).  So that’s something I need to change—or plain throw away the above code.

In summary, you can look at this code for an example, but it plain doesn’t work, and I prefer what Cobweb does anyway..so I leave it up to cobweb to call my parser when it finds a JSON scene in a URL in DOM.

The real thing would be to extend X3DOM to handle JSON Inlines and translate from JSON to DOM there natively when reading Inlines.  That would work best, IMHO, not in a separate piece of code.  My code can be used in X3DOM (you have my permission).

I haven’t gotten any interest in X3DJSONLD from the X3DOM folks that I know of.  Perhaps you could intercede? I can also look into how Inlines are loaded in X3DOM (but so can you).  I can certainly provide a DOM object from reading JSON.  If you know the best place to attach the Inline, great!

I use $.getJSON() from JQuery to load JSON external references.  References to that is in:  https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/loaderJQuery.js.  I have also used Google’s get() and getJSON() from https://developers.google.com/web/fundamentals/getting-started/primers/promises if you want a smaller chunk of code than JQuery, and something compatible with current promises.  Likely there is already similar code in X3DOM’s inlines, and you can just call JSON.parse(ajax return).  If it throws an exception, then you know it’s XML.  Easy.

So in other words, I think going from JSON to DOM really is the correct solution that will work in the long run.  It’s probably very difficult to replace X3DOM with a JSON equivalent and not recreate DOM.  I don’t have the time, and you probably don’t either.  Maybe if we sacrifice a few years of our lives.  But I don’t want to do that.  Do you?  I have not seen a great difference in loading times between Cobweb/X3DJSONLD and Cobweb native (in one case), but someone could show me the differences.

I will look a bit into X3DOM Inlines and tell you what I think.


Sent from Mail for Windows 10

From: Leonard Daly
Sent: Tuesday, May 30, 2017 2:16 AM
To: John Carlson; X3D Public; Don Brutzman
Subject: Re: [x3d-public] Announcing XSeen


Thank you for your interest. I have thought about how to create a scene in the browser if the input is JSON. I don't really have an answer right now. One solution I thought of is to create DOM nodes from the info in the JSON, then parse the DOM into the scene graph. There is obvious overhead, but it does reduce the problem to a previously solved case.

At this time I am comparing features to determine which are important and how best to express them. I have tried to keep the input possibilities as simple as possible so I haven't worked on handling a JSON encoding just yet. I do consider it important, but I'm not sure exactly where to start with it given where XSeen is right now.

When importing, I can take an X3D file and parse it as an XML file to create a DOM tree that is not attached to the document. I walk through the tree looking for a Scene element, then move all children of Scene to be children of the referring Inline. If you have code that can take an input (as external reference via Inline) and parse it into a DOM tree, I would be interested. Is that what your code does?

Leonard Daly

Interesting.  Do you need a JSON -> DOM library, or are you going with glTF or some other tool based JSON?
X3DJSONLD may work for your JSON -> DOM purposes.  It is intended to be fairly JSON encoding agnostic, and I’d like to try it with one of your scenes.  Do you have a scene in JSON?  That is, I don’t have a DOM -> JSON yet, but that’s on my near todo list, and I have a pre-alpha prototype, if X3D/X3DOM Scripts and Routes are no longer a priority.  It sounds like DOM -> JSON is higher priority…
If you do have JSON, and you are using https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/X3DJSONLD.js ,  you will need to modify the below method to provide your own loadSchema for JSON validation, or just remove it an rely on the basic DOM validation in the browser.
I do have a version which is more packaged, found in cobweb/X3DJSONLD, here:  https://github.com/coderextreme/cobweb/blob/master/cobweb.js/cobweb/Parser/JSONParser.js in that case, you just call var dom = JSONParser.parseJavaScript(jsObj), but it creates and X3D DOM element, which may not be desired.  The code is cleaner, and you may provide an alternative to parseJavaScript…
There are also DOM -> XML serializers in X3DJSONLD (not the above JavaScript, but in src/main/node) to validate your JSON is producing the right DOM.  The serialization is fairly standard, but you may find that you need to do some substitutions, which I provide.
I will start work on DOM -> JSON again.  We do need a second implementation, and I need it for client side purposes.  Off to work!
function loadX3DJS(jsobj, path, xml, NS, loadSchema, doValidate, callback) {

       console.error("Invoking client side loader");

       loadSchema(jsobj, path, doValidate, function() {

              x3djsonNS = NS;

              var child = CreateElement('X3D', NS);

              ConvertToX3DOM(jsobj, "", child, path);

              if (typeof xml !== 'undefined' && typeof xml.push === 'function') {

                     xml.push(serializeDOM(jsobj, child));


              console.error("Returning with", child);


       }, function(e) {




Sent from Mail for Windows 10
From: Leonard Daly
Sent: Monday, May 29, 2017 7:11 PM
To: X3D Public
Subject: [x3d-public] Announcing XSeen
As most of you know I have been advocating that X3D fully move into the HTML5 environment and support the display and interaction of flat-screen and VR declarative content in the browser. A-Frame offers many of those capabilities and was built for the browser environment. 
In keeping with my advocacy of this evolution of X3D, I started development of a library that supports comparison and definition of the best features of A-Frame, X3D, and other capabilities. This is a very early pre-alpha development release to help generate interest in a discussion of the appropriate technologies to include in the 3D/VR HTML language. The initial release is announced at http://realism.com/blog/xseen-merging-x3d-and-frame
At this stage only a few static features are available including all 3D pre-defined solids from  both languages plus X3D's Appearance, Material, Shape, Transform, and Inline. It is possible to mix nodes from X3D and A-Frame. The initial version of the library is on GitHub at https://github.com/DrX3D/XSeen. It runs on top of THREE.js
My next step is to write the beginnings of the internals documentation describing how to add nodes and other features. At this time there are no capabilities for animation except for what is done directly through THREE.
The goal of this work is to develop a language that is
1. Standardizable
2. Enterprise ready
3. Fully HTML5/DOM integrated
4. Runs in all browsers
5. Fully support VR, AR, xR, and flat-screen displays as determined by the content developer and user
6. Leverages other standards and communities applications and libraries
Leonard Daly
3D Systems & Cloud Consultant
President, Daly Realism - Creating the Future 

Leonard Daly
3D Systems & Cloud Consultant
President, Daly Realism - Creating the Future 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170530/13078f93/attachment-0001.html>

More information about the x3d-public mailing list