[x3d-public] Prototype Expander, Question on design of instance expansions, JSON Schema for finding containerField types.

[John Carlson]

Currently adding extra nodes to parentArray without Switch node.  Switch node to come (needed?).  Flattener.js has been modified.  MaterialModulator.json (attached) appears to be rendering properly in X3DOM, X3DOMJSON (except for offsetting script text) and Cobweb (A dark red sphere?).  Also bonus, we got Figure…DonutExternalPrototype.json rendering properly in Cobweb!  That one has been extremely difficult to expand properly!

Left to do:  accidental @value at top level in Scripts, any other schema variances (getting fewer and fewer now).

Can you tell me which JSON object key “-…” (containerField) values should be arrays and which should be objects so I have a complete list?
I should be able to look this up in the JSON schema, possibly.  If I could access the schema in a program to determine this, it would be ideal, but still a bit unclear on how determine what’s a containerField in the JSON schema. Schema.definitions[containerField]?  Then check for leading “–“ and definitions[containerField].type for whether it’s an array or an object?  Should we have a separate definitions for containerFields???

Thanks,

John

Sent from Mail for Windows 10

From: John Carlson
Sent: Saturday, July 2, 2016 11:40 PM
To: Don Brutzman
Cc: x3dom-developer mlist; X3D Graphics public mailing list; Roy Walmsley
Subject: Re: Prototype Expander, Question on design of instance expansions

On Jul 2, 2016 5:10 PM, "Don Brutzman" <brutzman at nps.edu> wrote:
>
> b. Handle follow-on nodes by also inserting them, in a scene-valid manner.
> b.1. When the first node in the ProtoBody is an X3DChildNode, any follow-on nodes can be wrapped in a Switch (with whichChoice="-1") to ensure they are non-rendering.
> b.2. When first node in the ProtoBody is not an X3DChildNode, any follow-on nodes are still wrapped in a Switch which follows at the closest subsequent point in the scene graph that can accept children nodes.
Note that the closest subsequent point is likely to  be a parent array, since objects don't hold objects (they hold objects as values of attributes).  Is this what we want?  As to finding the parent array, I was thinking each object could contain a "../arrayElement" attribute which would have a value of the JSONPath from the root to the array element index that the ProtoInstance (for example) is contained within.  Doing this with nested protoinstances could get really tricky. I almost want to do the Proto expansion first, and then try to add the switch nodes in the Flattener.js.  hmm.  That may work a lot better.  Thank you John for thinking this through before implementation. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160703/aed0c090/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MaterialModulator.json
Type: application/json
Size: 6052 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160703/aed0c090/attachment-0001.json>