wildpeaks / 2015-json-scenegraph Goto Github PK

A question from the X3D mailing-list referencing #1 :

Something that jumps out is when you say "How would you make a Group that contains a Shape, a Transform and another Shape ? It can't be the following because an Object can't define property Shape twice".

That is indeed a serious constraint, if it is indeed correct - that wasn't clear about Javascript. (got a reference?)

A question that came up a few times:

Why "_type" instead of "type" ?

You might wonder:

Why bother having a $ in every node and the name of properties, when you could automatically deduce where child nodes belong to based on their type? For example, it's obvious what a Box and an Appearance inside a Shape should do.

A question from the X3D mailing-list referencing #1 :

Wondering then, what about your repeated use of "$", isn't that the same sort of repetition as repeating "Shape" and "Transform" ?

(Edit: $ used to be called _type at the time)

A question from the X3D mailing-list referencing #1 :

[...] wondering then whether this slight variation using field name (containerField) is an alternative option:

    "_children": "Shape"
    ...
},
{
    "_children": "Transform"
    ...
},
{
    "_children": "Shape"

This was a question from the X3D mailing-list:

how is
"$": "Shape",

different than
"Shape": [

The "$" doesn't add any information per se.

(Edit: $ used to be named _type at the time)

One may wonder:

How to convert CDATA blocks of text to JSON?

A question have been recurring:

How to handle comments?

Single numeric value are expressed with a simple Number, but how should MFVec3f (and other MFVec types) be represented: a single long Array, or an Array of tiny Arrays ?

One may wonder:

How to convert ROUTE statements such as:
ROUTE interpolator.value_changed TO transform.translation