[X3D-Public] [x3dom-developers] initial X3D JSON conversion support using X3dToJson.xslt

[Christoph Valentin]

Hi Cecile,

I do not want to disturb your discussion.

Only, if you write [...]so this is more a VRML/X3D-inspired format, not "real X3D".[...], do you mean the "3D universe" will rather split into two "multiverses"?

One multiverse "X3D", which does not need W3C browsers and builds "full-blown 3D" (maybe including 2D as part of the 3D scene), but 3D is the "master".

Another multiverse "X3D light", which relies on W3C browsers as the "2D wrappers", as the "masters" of 3D content.

Thanks for any explanation in advance

Christoph 
 

Gesendet: Freitag, 10. Oktober 2014 um 19:53 Uhr
Von: "Cecile Muller" <newsletter at wildpeaks.fr>
An: "Jung, Yvonne" <yvonne.jung at igd.fraunhofer.de>
Cc: "x3d-pulbic mlist" <x3d-public at web3d.org>, "Don Brutzman" <brutzman at nps.edu>
Betreff: Re: [X3D-Public] [x3dom-developers] initial X3D JSON conversion support using X3dToJson.xslt

Hi everyone,
 
 
> JSON is a built-in JavaScript object. This works out of the box: the parse method simply creates a valid JS object from a JSON string.
> The resulting object tree however still has to be traversed to attach meaning and behavior.
 
Exactly: the way the engine chooses to render the scenegraph is up to it, the JSON data is only meant to initialize the scenegraph in the 3D engine (and optionally export its state at a given moment if needed).
 
 
Which is actually why it would feel redundant to have prototypes inside JSON if you use it in for Javascript because in real life I'd use real JS modules if I need a custom object type with properties and methods (CommonJS, AMD, ES6 modules, typescript modules, factories or whatever the author prefers) because:
 - it's the same scripting language as the rest of the application
 - it can be optimized with the rest of the application
 - it can be tested with the rest of the application
 - it can refer to and interact with non-3D modules (e.g. a thirdparty library for formatting Date timestamps)
 - no eval()
 
 
My goals for a scenegraph format are:
 - lightweight to parse
 - meaningful and low complexity because it's simpler to think with, easier to read, easier to diff between two states, and easier to sync between devices
 - easy to require(), to use the same package management as the rest of the application code and assets
 
However I'm fine not having feature parity with XML if it keeps it lightweight and straightforward, so this is more a VRML/X3D-inspired format, not "real X3D".
 
 
Example (the "_type" is omitted in some nodes because I also have a concept of "Default type" for some fields, e.g. how most of the time the value in "Shape.appearance.material" is a Material node):
 
[
{
"_type": "Shape",
"appearance": {
"material": {
"transparency": 0.5,
"diffuseColor": [0.8, 1, 0.8]
}
},
"geometry": {
"_type": 'Box',
"size": [2, 1, 2]
}
},
{
"_type": "MyCustomObjectType",
"translation": [0, 0, 1],
"scale": [2, 2, 2]
}
]
 
And an example (without messaging or engine-specific code) of one of many ways to create something similar to Protos:
 
var MyCustomObjectType = function(data){
'use strict';
var _data = data || {};
var _json = {
_type: 'Transform',
translation: _data.translation || [0, 0, 0],
scale: _data.scale || [1, 1, 1],
children: [
{
_type: 'Shape',
appearance: {
material: {
transparency: 0.5,
diffuseColor: [0.8, 1, 0.8]
}
},
geometry: {
_type: 'Sphere',
radius: 5
}
}
]
};
Object.defineProperty(
this,
'json',
{
configurable: false,
enumerable: true,
writable: false,
value: function(){
return _json;
}
}
);
};
 
MyCustomObjectType.prototype.modifySomething = function(){
'use strict';
//
//
};
 
module.exports = MyCustomObjectType;
 
 
See you,
Cecile_______________________________________________ X3D-Public mailing list X3D-Public at web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org