[x3d-public] both X3DOM and X_ITE.

John Carlson yottzumm at gmail.com
Tue May 29 02:40:44 PDT 2018


Once, I put the try catch around replaceWorld, X3DJSONLD X_ITE seems to work flawlessly with NancyDivingProtoInstances.json.  However, X3DOM has all kinds of problems.  I do recommend that Andreas attempt to rewrite it for X3DOM, if not already done. We should get some positive bonuses, like SFRotation, if that’s possible in X3DOM.

So both NancyPrototypes.json and NancyDivingProtoInstances.json are candidates for X3DOM porting. I’ll let someone decide which has the lowest hanging fruit.

And don’t forget my script preprocessor:

https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/Script.js

[ yes, it’s a hack, improvements are welcome ]

Yes, I did work fairly hard to get NancyPrototypes.json working in the ProtoExpander.  Thank goodness Cobweb was available at the time to execute behaviors.

Do people want me to check in my Nancy Proto JSONs?

John

Sent from Mail for Windows 10

From: John Carlson
Sent: Tuesday, May 29, 2018 5:21 AM
To: Joseph D Williams; Andreas Plesch
Cc: x3dom mlist; X3D Graphics public mailing list
Subject: RE: both X3DOM and X_ITE.

If on the other hand, our goal is to get all types of HAnim working everywhere,
We can focus on the Nancy Protos.

I do know that currently, NancyDivingProtoInstances.json does not load in X3DJSONLD.   And probably won’t in X3DOM due to no conversion from XML to JSON for the ProtoExpander (oops).   You’ll probably have to provide JSON urls for the ProtoExpander, or put
    <script type="text/javascript" src="https://coderextreme.net/X3DJSONLD/src/main/node/fieldTypes.js"></script>
    <script type="text/javascript" src="https://coderextreme.net/X3DJSONLD/src/main/node/mapToMethod.js"></script>
    <script type="text/javascript" src="https://coderextreme.net/X3DJSONLD/src/main/node/DOM2JSONSerializer.js"></script>
before x3dom…js in your html file.  I had the best luck using local JSON urls.  I would attach the files, but I think they are rather big.

And it still won’t load. Hmm. Getting:

loaderJQuery.js:389 TypeError: Cannot read property 'push' of undefined
    at x3dom.Mesh.calcNormals (x3dom-full.debug.js:15345)
    at x3dom.registerNodeType.defineClass.nodeChanged.nodeChanged (x3dom-full.debug.js:57213)
    at x3dom.NodeNameSpace.setupTree (x3dom-full.debug.js:30582)
    at x3dom-full.debug.js:30576
    at Function.Array.forEach (x3dom-full.debug.js:35)
    at x3dom.NodeNameSpace.setupTree (x3dom-full.debug.js:30575)
    at x3dom-full.debug.js:30576
    at Function.Array.forEach (x3dom-full.debug.js:35)
    at x3dom.NodeNameSpace.setupTree (x3dom-full.debug.js:30575)
    at x3dom-full.debug.js:30576

In X3DJSONLD. This is when x3dom.reload() is called in replaceWorld (without loadJS()—I haven’t tried with loadJS()). Haven’t really figured out a reason yet. I put a breakpoint right after x3dom.reload() and it doesn’t do anything, so I figure it’s someplace in x3dom.reload(). I saw that sometimes a uri being loaded can be an X3D element, so that’s cool. I will put a try catch around replaceWorld so that the error is localized. I often put try/catch around x3dom.reload(), just because it’s so problematic, perhaps we should in this case. Your call, since you seem have the best ideas for replaceWorld, Andreas.

Or from X3DOM:

Uncaught TypeError: Cannot read property 'push' of undefined
    at x3dom.Mesh.calcNormals (x3dom-full.debug.js:15345)
    at x3dom.registerNodeType.defineClass.nodeChanged.nodeChanged (x3dom-full.debug.js:57213)
    at x3dom.NodeNameSpace.setupTree (x3dom-full.debug.js:30582)
    at x3dom-full.debug.js:30576
    at Function.Array.forEach (x3dom-full.debug.js:35)
    at x3dom.NodeNameSpace.setupTree (x3dom-full.debug.js:30575)
    at x3dom-full.debug.js:30576
   at Function.Array.forEach (x3dom-full.debug.js:35)
    at x3dom.NodeNameSpace.setupTree (x3dom-full.debug.js:30575)
    at x3dom-full.debug.js:30576


So it’s probably unrelated to replaceWorld() would be my best guess. More likely, it’s something  in the file itself (missing normals?).

It is interesting to note that NancyPrototypes.json had schema errors, but apparently, NancyDivingProtoInstances.json does not.


Note: X_ITE was successful at loading, displaying, and running both files.    X3DOM still needs work.

Do we want to work with continuous skin (seamless I guess) on not?

Note I was successful at displaying the NancyPrototypes.json model in X3DOM, just no interaction buttons appear as they do in X_ITE, so it’s difficult to test behaviors.   Can you look into why the interaction buttons don’t appear, Andreas?  Maybe we can use something else in X3DOM? Something similar to BoxManAnimationPanel.json  perhaps?  Thanks!

Sent from Mail for Windows 10

From: John Carlson
Sent: Tuesday, May 29, 2018 12:31 AM
To: Joseph D Williams; Andreas Plesch
Cc: x3dom mlist; X3D Graphics public mailing list
Subject: RE: both X3DOM and X_ITE.

Let’s keep the focus on “HAnim skeleton controlled deformable skin.” If the Nancy PROTO examples do that, good.  As far as I know, the skin mesh on NancyPrototypes.x3d is NOT continuous—It’s made up of separate pieces that follow separate pieces of the skeleton. I do not know about the other Nancy Proto.  I don’t know if continuous skin is a requirement or not.

John


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180529/9308377b/attachment-0001.html>


More information about the x3d-public mailing list