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

Behr, Johannes johannes.behr at igd.fraunhofer.de
Mon Oct 13 02:34:18 PDT 2014


Hi,

+1 for Cecile's, Sons and Yvonnes proposal. 

This is compact and reflects the internal X3D model and easy to parse.

> +1 for Cecile's proposal with explicit containers.
> 
> Two remarks:
> - I think there shouldn't be a default type. Otherwise an application needs to know these default values, which again makes it harder to implement tools.

Missing default types help to decrease the file size and is more easier to read for most user. 
Maybe we cout mark the with/without default-types in the header.  

> - MFFields should be encoded as simple arrays (not array of arrays). Typical multi-value fields such as normals, keyValues would be trnalsted to TypedArrays of GLBuffers anyway and for these operations arrays of array is only degrade the performance and have very little added value

+1

Best regards
Johannes

> 
> Just my 2 cents,
>   Kristian
> 
> 
>> 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
> 
> 
> -- 
> _______________________________________________________________________________
> 
> Kristian Sons
> Deutsches Forschungszentrum für Künstliche Intelligenz GmbH, DFKI
> Agenten und Simulierte Realität
> Campus, Geb. D 3 2, Raum 0.77
> 66123 Saarbrücken, Germany
> 
> Phone: +49 681 85775-3833
> Phone: +49 681 302-3833
> Fax:   +49 681 85775–2235
> 
> kristian.sons at dfki.de
> http://www.xml3d.org
> 
> 
> Geschäftsführung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
> Dr. Walter Olthoff
> 
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> _______________________________________________________________________________
> 
> _______________________________________________
> X3D-Public mailing list
> X3D-Public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

---
Dr. Johannes Behr
Head of Department: Visual Computing System Technologies
Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-510  |  Fax +49 6151 155-196
johannes.behr at igd.fraunhofer.de  |  www.igd.fraunhofer.de




More information about the X3D-Public mailing list