[x3d-public] Announcing XSeen
Leonard Daly
Leonard.Daly at realism.com
Tue May 30 10:08:27 PDT 2017
John,
I'm not sure I follow all of this (at least not sure yet...)
I can get the external (JSON) file in text format and easily parse it
into an object. Do you have software that goes from the object to DOM
nodes? Once there are DOM nodes (but not in the page's document tree), I
can extract what I need and insert it as children of Inline, then parse
the 3D node contents.
BTW, the conversion from JSON object to DOM needs to be general purpose
and not specifically for X3D nodes, though it can follow the attribute
and children pattern that has been set up.
Leonard Daly
> Yes, the code is in x3dom/src/nodes/Networking/Inline.js:loadInline()
>
> You would have to set the Ajax to be generic (or add json, not sure
> how to do that—one thing you can do is test the extension of the url),
> instead of XML so you can download JSON as well, then around these lines,
>
> if (navigator.appName != "Microsoft Internet
> Explorer")
>
> xml = xhr.responseXML;
>
> else
>
> xml = new
> DOMParser().parseFromString(xhr.responseText, "text/xml");
>
> call my JSON to DOM converter after parsing the xhr.response with
> JSON.parse(), then pass javascript object returned from JSON.parse and
> a brand new xml variable X3D element you create into my routines (or
> call JSONParser.parseJavaScript() which returns an X3D element and set
> the xml variable to it).
>
> I believe they will do the step of integrating the JSON Inline into
> the scene below, so you don’t have to do it!
>
> Then you add X3DJSONLD as a package to X3DOM. That, I don’t know how
> to do yet. Why didn’t I do it myself? Because I want to get people
> interested with me and test my code! I believe programmer should test
> their code, and I have done that, but further testing is always welcome!
>
> I believe the best approach would be to integrate the JSONParser with
> X3DOM, since the code is cleaner, and JSONParser is already somewhat
> packaged. If not, give me module for X3DOM/JSONLD, and I will add my
> code to it, and we can put it under X3DOM’s license!
>
> If we make these changes to X3DOM (or XSeen), I will be happy to test
> XSeen!
>
> And then watch how easy my JSON prototype expander slips in. LOL,
> needs more work.
>
> What is Multipart.js in X3DOM? Do we need to modify that?
>
> John
>
> *From: *John Carlson <mailto:yottzumm at gmail.com>
> *Sent: *Tuesday, May 30, 2017 3:48 AM
> *To: *Leonard Daly <mailto:Leonard.Daly at realism.com>; X3D Public
> <mailto:x3d-public at web3d.org>; Don Brutzman <mailto:brutzman at nps.edu>
> *Subject: *RE: [x3d-public] Announcing XSeen
>
> 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);
>
> element.appendChild(child);
>
> element.appendChild(document.createTextNode("\n"));
>
> } 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);
>
> element.appendChild(child);
>
> element.appendChild(document.createTextNode("\n"));
>
> }
>
> });
>
> 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.
>
> John
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
> *From: *Leonard Daly <mailto:Leonard.Daly at realism.com>
> *Sent: *Tuesday, May 30, 2017 2:16 AM
> *To: *John Carlson <mailto:yottzumm at gmail.com>; X3D Public
> <mailto:x3d-public at web3d.org>; Don Brutzman <mailto:brutzman at nps.edu>
> *Subject: *Re: [x3d-public] Announcing XSeen
>
> John,
>
> 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!
>
> functionloadX3DJS(jsobj, path, xml, NS, loadSchema, doValidate,
> callback) {
>
>
>
>
> console.error("Invoking client side loader");
>
>
>
>
> loadSchema(jsobj, path, doValidate, function() {
>
>
>
>
> x3djsonNS =NS;
>
>
>
>
> varchild =CreateElement('X3D', NS);
>
>
>
>
> ConvertToX3DOM(jsobj, "", child, path);
>
>
>
>
> if(typeofxml !=='undefined'&&typeofxml.push==='function') {
>
>
>
>
> xml.push(serializeDOM(jsobj, child));
>
>
>
>
> }
>
>
>
>
> console.error("Returning with", child);
>
>
>
>
> callback(child);
>
>
>
>
> }, function(e) {
>
>
>
>
> console.error(e);
>
>
>
>
> callback(null);
>
>
>
>
> });
>
>
>
>
> }
>
> John
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986>
> for Windows 10
>
> *From: *Leonard Daly <mailto:Leonard.Daly at realism.com>
> *Sent: *Monday, May 29, 2017 7:11 PM
> *To: *X3D Public <mailto:x3d-public at web3d.org>
> *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
> LA ACM SIGGRAPH Chair
> President, Daly Realism - /Creating the Future/
>
> --
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Chair
> President, Daly Realism - /Creating the Future/
>
--
*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/20170530/babea423/attachment-0001.html>
More information about the x3d-public
mailing list