[x3d-public] Topics for Discussion at JSON meeting:SFNode/MFNode field/fieldValue content, ProtoBody, regexes

[Don Brutzman]

Thanks for checking up on this Joe.  Very important for us to get JSON correct and matching the functionality of ClassicVRML/XML/binary encodings.

On 2/6/2016 2:41 PM, Joe D Williams wrote:
>> only be one top level node in the ProtoBody?
>
> What is a top-level node? I didn't understand the term.
> Isn't there some more X3D established name for this? root or child?

OK let me retry:

Each ProtoBody can contain a list of nodes.  At least one node must be in that list.

The first node determines the overall node type of the prototype.

Subsequent peer nodes can be of any type.

This list of nodes - at the top level of what is held in the ProtoBody - does not have to be a valid scene subgraph.

(This is similar to other MFNode arrays that are held in a Script or prototype field/fieldValue initialization, I believe.)

Nevertheless each of those nodes in the ProtoBody top-level list (Shape, Group, Box, Material, Script, whatever) must themselves contain valid content.  They are not rendered.  They can be triggered via IS/connect fields or by the first node in the list.

> The type of the first node defines where the proto can appear in a scene graph. The rest is just whatever it takes to complete the structure and provide the functionality.

Agreed, you bet.

> So, isn't is it that any field that has a DEF can be the first node in the proto and likewise any field that can have a DEF can be 'replaced' by an instance of a proto?

The spec excerpts shown before don't add any new requirements on DEF/USE.

However you have to be careful about prototype scope:  DEF/USE nodes inside a protobody are not accessible outside of that prototype body.  More on that:

http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#Runtimenamescope
=========================================
4.4.7 Run-time name scope

Each X3D browser defines a run-time name scope that contains all of the root nodes currently contained by the scene graph and all of the descendant nodes of the root nodes, with the exception of nodes hidden inside another name scope. Prototypes establish a name scope and therefore nodes inside prototype instances are hidden from the parent name scope.

Each Inline node or prototype instance also defines a run-time name scope, consisting of all of the root nodes of the file referred to by the inline node or all of the root nodes of the prototype definition, restricted as above. Other nodes or extension mechanism may be introduced which specify their own name scope.
[...]
=========================================

>  From HAnim#VRML V2.0 utf8 eMpTyWorlds V3.29.70
>
> PROTO Humanoid [
> exposedField    SFVec3f    center       0 0 0
> exposedField    MFNode     humanoidBody          [ ]
> exposedField    MFString   info         [ ]
> exposedField    MFNode     joints       [ ]
> exposedField    SFString   name         ""
> exposedField    SFRotation rotation     0 0 1 0
> exposedField    SFVec3f    scale        1 1 1
> exposedField    SFRotation scaleOrientation      0 0 1 0
> exposedField    MFNode     segments     [ ]
> exposedField    MFNode     sites        [ ]
> exposedField    SFVec3f    translation           0 0 0
> exposedField    SFString   version      "200x"
> exposedField    MFNode     viewpoints            [ ]
> field           SFVec3f    bboxCenter            0 0 0
> field           SFVec3f    bboxSize     -1 -1 -1
> ]
> {

<== Here is the point of interest: the ProtoBody.

It is implicit in VRML/ClassicVRML syntax, wrapped by the preceding/following {squiggly brackets). It is called ProtoBody in XML and JSON syntax so that we can, uh, talk about it.  8)

For this example, the following Transform would be the single node in the "list of top-level nodes" contained by the ProtoBody.

> Transform {
>   center           IS center
>   rotation         IS rotation
>   scale            IS scale
>   scaleOrientation IS scaleOrientation
>   translation      IS translation
>   children [
>    Group {
>     children IS humanoidBody
>    }
>    Group {
>     children IS viewpoints
>    }
>   ]
> }
> }
> Thanks,
> Joe

Hope this sounds good.
all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman