[x3d-public] x3d extensions through Metadata; ExternProtoDeclare also possible

Mon Jul 3 18:35:25 PDT 2023

Acknowledged all, thanks.

The way to use a prototype to only extend the fields in a node is to declare a new prototype node containing the original node as first node, include the original fields with IS connections (as appropriate) then add new fields of interest.

Example follows, preserving original fields and adding an ‘enabled’ field.

*	X3D Example Archives: X3D4WA, X3D for Web Authors, Chapter 14 Prototypes, Material Modulator
*	Mimic a Material node and modulate the diffuseColor field as an animation effect, provided as a prototype for reusability.
*	https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulatorIndex.html
*	https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulator.x3d

*	X3D Example Archives: X3D4WA, X3D for Web Authors, Chapter 14 Prototypes, Material Modulator Examples
*	Demonstrate multiple instances of an external prototype.
*	https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulatorExamplesIndex.html
*	https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulatorExamples.x3d

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 https://faculty.nps.edu/brutzman

From: GPU Group <gpugroup at gmail.com> 
Sent: Monday, July 3, 2023 4:05 PM
To: Andreas Plesch <andreasplesch at gmail.com>
Cc: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; X3D Graphics public mailing list <x3d-public at web3d.org>
Subject: Re: [x3d-public] x3d extensions through Metadata; ExternProtoDeclare also possible

Tangentially related: 

a) tuple nodes in web3d: like script or protoDeclare fields - configurable field types, but that's all it is - a collection of fields.

- and can be ROUTEd as SFNodes

b) Blender import - where to hide non-blender nodes and information, in such a way they can be exported and reconstituted in the exported scene

-Doug

On Mon, Jul 3, 2023 at 3:46 PM Andreas Plesch <andreasplesch at gmail.com <mailto:andreasplesch at gmail.com> > wrote:

Hi Don,

<MetadataSet name="NewFields4.1" containerField='metadata'><!—list of
fields follow --></MetadataSet> would work. On the other hand, I may
prefer use of the reference field to avoid a level of hierarchy:

<MetadataFloat reference="NewFields4.1" name="sortKey" value="1"
containerField='metadata' />

After all, reference is supposed to be used for a well-defined class
of Metadata, perhaps with a Schema.

We should keep in mind that there will be extensions which are not
candidates for v4.1.

Describing the SFNode representation, I also had thought about reusing
ProtoInstance, with or without ProtoExternDeclare. But how would one
then represent extension fields to existing nodes like Shape ?

I guess it is possible to mix and match Metadata and Proto but it
seems not ideal.

Best, Andreas

On Mon, Jul 3, 2023 at 3:48 PM Brutzman, Donald (Don) (CIV)
<brutzman at nps.edu <mailto:brutzman at nps.edu> > wrote:
>
> Good efforts, thanks for thinking this possibility through farther.  Agreed that new fields might be added this way
>
> <MetadataSet name="NewFields4.1" containerField='metadata'><!—list of fields follow --></MetadataSet> though nodes do seem trickier.
>
>
>
> Another thought, belatedly:  we might also use more-familiar ExternProtoDeclare constructs to define signatures for any new nodes of interest.
>
>
>
> While we usually work hard to provide essential implementations in X3D for such declarations (possibly including even Script and Shader nodes), it is also possible that an X3D browser might recognize particular externproto nodes of interest and apply its own native implementation.  The ExternProtoDeclare might even point to a stub that let any player read and handle them without rendering or error.
>
>
>
> Then including a ProtoInstance for each usage of each new node also has familiar, simple syntax.
>
>
>
> all the best, Don
>
> --
>
> Don Brutzman  Naval Postgraduate School, Code USW/Br        brutzman at nps.edu <mailto:brutzman at nps.edu> 
>
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA    +1.831.656.2149
>
> X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman
>
>
>
> -----Original Message-----
> From: x3d-public <x3d-public-bounces at web3d.org <mailto:x3d-public-bounces at web3d.org> > On Behalf Of Andreas Plesch
> Sent: Monday, July 3, 2023 11:51 AM
> To: X3D Graphics public mailing list <x3d-public at web3d.org <mailto:x3d-public at web3d.org> >
> Subject: Re: [x3d-public] x3d extensions through Metadata
>
>
>
> While Metadata could provide a backward compatible way to represent non-standard fields and nodes, it seems difficult to use such Metadata nodes for events and routes.
>
>
>
> It would mean for a browser to establish implicit, internal bi-directional routes between an extension Metadata node and the actual field of a scene graph node. This becomes similar to Prototypes and quite difficult to track properly for a browser.
>
>
>
> A potential solution may be to disregard extension Metadata nodes for routing to the represented nodes. Extension Metadata nodes would only be used initially to populate extension fields and add extension nodes to the scene graph.
>
>
>
> In effect this means that for MetadataSets representing SFNodes it will be necessary to include another MetadataString child which defines the DEF name of the represented extension node. So the name for this MetadataString could be 'DEFname' and the value the name which can be used for routing. Unfortunately, it would not be possible to use the name field of the MetadataSet since the name field contains the node name ("Depthmode"). It is also not possible to use the DEF statement because it will refer to the Metadata node, not the represented SFNode.
>
>
>
> This way there is complete information to construct the scene graph node during first loading and add it.
>
>
>
> This also would mean routes with a fromNode or toNode to an extension node with a DEFname of say "readonlyDepthmask" represented by a MetadataSet would be legal even although there is no DEF statement with such a name, only the corresponding MetadataString. If validators check for routes, they would have to account for this.
>
> Similarly routes with fromField or toField to an extension field, say "sortKey", would be also legal although the field is only represented by MetadataXXX node with the name of the field.
>
>
>
> Perhaps this all means that the integrity of routes cannot be completely validated if Metadata are used to represent extension fields and nodes.
>
>
>
> It is probably time to put together examples for easier discussion.
>
>
>
> -Andreas
>
>
>
> On Sun, Jul 2, 2023 at 1:45 PM Andreas Plesch <andreasplesch at gmail.com <mailto:andreasplesch at gmail.com> > wrote:
>
> >
>
> > X3D Browsers may have non-standard extensions such as fields and
>
> > nodes. It has been suggested that a backwards compatible way to access
>
> > such extensions could be accomplished through Metadata nodes. This way
>
> > a X3D file using such extensions still can conform strictly to the
>
> > syntactic standard.
>
> >
>
> > It should be possible for browsers to have general and automatic
>
> > recognition of such extension fields and nodes provided in Metadata.
>
> > Here is a first draft mechanism:
>
> >
>
> > A metadata node would advertise that it is eligible to be considered
>
> > as an extension, probably through a reference value of say
>
> > "x3dExtension", or by being contained in a special Metadataset with
>
> > such a name or reference.
>
> >
>
> > Then a browser would check the Metadata name and if the name is
>
> > equivalent to an implemented field of the parent node, the browser
>
> > would use the value of the Metadata and use it in some way as the
>
> > value of the field (This could also apply to standard fields).
>
> >
>
> > Since Metadata values can only be of type MFString, MFFloat, MFDouble,
>
> > MFBool or MFInt32 there needs to be some translation to field values.
>
> >
>
> > Most translations are obvious but SF/MFNode fields are not. One option
>
> > is to provide the xml string of an SFNode as the value in a
>
> > MetadataString node. But this may be too encoding specific. On the
>
> > other hand there is the standard SAI  function createX3DFfromString
>
> > for that.
>
> >
>
> > So another option is to use MetadataSet for SFNode. name would still
>
> > be the field name for the SFNode. Then the children of MetadataSet
>
> > would contain the fields of the SFNode node. In addition there would
>
> > be a MetadataString node with name "nodeName" which has the node name
>
> > as the value.  This is more verbose but crosses encodings.
>
> >
>
> > MFNode fields would also use MetadataSet. The only children would be
>
> > MetadataSet of the SFNode kind.
>
> >
>
> > I will have to check how well that kind of mechanism would fit with
>
> > processing of metadata in x3dom. It may not fit that well.
>
> >
>
> > Any feedback, or ideas welcome,
>
> >
>
> > Andreas
>
> > --
>
> > Andreas Plesch
>
> > Waltham, MA 02453
>
>
>
>
>
>
>
> --
>
> Andreas Plesch
>
> Waltham, MA 02453
>
>
>
> _______________________________________________
>
> x3d-public mailing list
>
> x3d-public at web3d.org <mailto:x3d-public at web3d.org> 
>
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-- 
Andreas Plesch
Waltham, MA 02453

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org <mailto:x3d-public at web3d.org> 
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230704/7a3f3bf8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5464 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230704/7a3f3bf8/attachment-0001.p7s>