[x3d-public] X3DParticleEmitter node inherit fromX3DChildNode(rather than X3DNode)

Thu Mar 10 18:23:00 PST 2022

Within that Switch, we've used Shape as the container for unrendered texture
and material nodes getting DEF instantiation and later USE usage.

Other mechanisms include Prototypes, as shown in UniversalMedia examples for
Material and Background nodes (which include image urls).

* https://www.web3d.org/x3d/content/examples/Basic/UniversalMediaMaterials/
* https://www.web3d.org/x3d/content/examples/Basic/UniversalMediaPanoramas/

Third mechanism that someone might show:  Inline with IMPORT/EXPORT.

Of note is that design decision might be driven by animation intentions as
well as data re-use.

It will further be good to consider use cases with CAD, possibly Smart
Cities also.

"Are we having fun yet?!"   8)

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

-----Original Message-----
From: Michalis Kamburelis <michalis.kambi at gmail.com> 
Sent: Thursday, March 10, 2022 2:32 PM
To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
Cc: Andreas Plesch <andreasplesch at gmail.com>; Joseph D Williams
<joedwil at earthlink.net>; X3D Graphics public mailing list
<x3d-public at web3d.org>
Subject: Re: [x3d-public] X3DParticleEmitter node inherit
fromX3DChildNode(rather than X3DNode)

NPS WARNING: *external sender* verify before acting.

> The right way to cache non-rendered content for DEF/USE libraries is to
put them as children nodes within a Switch node with whichChoice='-1'.

Indeed, "Switch" (with whichChoice left -1) is our (VRML, X3D) traditional
way of making a "library of nodes".

But the very reason why this thread exists is because Switch is not
sufficient :)

Switch only allows X3DChildNode as children. Which is of course correct, it
cannot allow "any X3DNode" as children, because it would not make sense to
traverse it, and Switch has to be designed with assumption "one of these
nodes can be active".

This means you cannot use Switch to have a library of e.g.
X3DParticleEmitter nodes. Which was the catalyst for this entire thread --
Don wanted to make X3DParticleEmitter a X3DChildNode for this reason, or
make special exception to allow it as a root node, and I argued that we
should not make a special hack for X3DParticleEmitter. Because one may also
want to reUSE easily Materials, ImageTextures etc.

This is why I proposed NodesLibrary. I suspect this is why X_ITE decided to
implement this by hacking MedataSet.

If we truly want functionality "library of any nodes", then I think we
really need something like NodesLibrary I described, probably in X3D 4.1.
Switch is not enough (not for any node), and indeed we don't want to
encourage "hacking" MetadataSet to achieve this.

Regards,
Michalis

czw., 10 mar 2022 o 22:14 Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
napisał(a):
>
> Thanks for continued scrutiny and consideration.
>
>
>
> Likely we should create a set of examples from each of the languages
you've listed (and more) to show how to do it.
>
>
>
> Metadata libraries are further exposable via Inline IMPORT/EXPORT or even
as prototype declarations.  Such repurposing of MetadataSet structures can
be automated if desirable.  Corresponding forms in Turtle for semantic web
query will provide further use.
>
>
>
> Test cases welcome.
>
>
>
> 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: Andreas Plesch <andreasplesch at gmail.com>
> Sent: Thursday, March 10, 2022 1:08 PM
> To: Joseph D Williams <joedwil at earthlink.net>
> Cc: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; X3D Graphics 
> public mailing list <x3d-public at web3d.org>
> Subject: Re: [x3d-public] X3DParticleEmitter node inherit 
> fromX3DChildNode(rather than X3DNode)
>
>
>
> Good comments.
>
> MetadataSet to have X3DNode nodes
>
> If I understand it, the idea of ending meta to include actual user code
for the scenegraph is exactly the sort of extension wanting to be
"worthwhile to deviate a bit and be more permissive than the spec" that
dooms the long-term validation operation. Maybe good for something with
simple structure that looks convenient and logical and seemingly convenient
to implement at first thought and elementary usage, then ends up making
something definitely not to be best practice. Please delineate the
"worthwhile" parts that make a case.
>
>
>
> I only know that this construction shows up in most of x-ite examples, and
is how the Titania editor saves a scene, simple or complex. I can only
deduce that this decision was deliberate but cannot speak to the specific
motivation by the author. Speculating, the feature seems to be valuable for
authoring. It should be possible to convert to standard x3d automatically by
moving the DEF node from the MetadataSet to the first USE node, perhaps by
xslt.
>
>
>
> Not quite sure how validation would be affected.
>
>
>
> I agree that Metadata nodes should be limited to actual metadata but a
library node seems sensible.
>
>
>
> Here is a list of other, well established scene graph systems which do
have a concept of a non-renderable library which is separate and can then be
referenced as needed:
>
>
>
> - svg
>
> - glTF
>
> - a-frame
>
> - collada (I believe)
>
>
>
> it is a natural concept and perhaps allows for cleaner user code
organization. Having two alternative ways to define a DEF node (in a
library, and as a first scene graph node) does seem to invite friction, and
would need to be carefully considered.
>
>
>
> Andreas
>
>
>
>
>
> From: Andreas Plesch
> Sent: Tuesday, March 8, 2022 11:39 AM
> To: Brutzman, Donald (Don) (CIV)
> Cc: X3D Graphics public mailing list
> Subject: Re: [x3d-public] X3DParticleEmitter node inherit 
> fromX3DChildNode(rather than X3DNode)
>
>
>
> Yes, I am pretty sure Holger is aware. I only brought it up because
Titania/x-ite typically stays very close to the spec. But this is a
capability where Titania/x-ite found it worthwhile to deviate a bit and be
more permissive than the spec. This decision may point to the value of
having a way to DEF any X3DNode (not just child nodes) outside of the scene
graph, outweighing strict compliance.
>
>
>
> All the best, Andreas
>
>
>
> On Tue, Mar 8, 2022 at 2:22 PM Brutzman, Donald (Don) (CIV)
<brutzman at nps.edu> wrote:
>
> MetadataSet is only allowed to contain other Metadata* nodes or comments.
Other content will fail validation (and will not load or import in the
X3DJSAIL Java and X3DPSAIL Python libraries).
>
>
>
> The right way to cache non-rendered content for DEF/USE libraries is to
put them as children nodes within a Switch node with whichChoice='-1'.
>
>
>
> 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: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of Andreas 
> Plesch
> Sent: Tuesday, March 8, 2022 10:11 AM
> To: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: Re: [x3d-public] X3DParticleEmitter node inherit from 
> X3DChildNode(rather than X3DNode)
>
>
>
> Of note is that Titania and x-ite allow MetadataSet to have X3DNode nodes,
eg. any node, in the value field, not just X3DMetadataObject nodes.
>
>
>
> This allows MetadataSet to be used as a NodesLibrary for DEF/USE purposes.
In fact, this kind of redirection is the default setup for scenes created in
Titania.
>
>
>
> SVG also has a NodesLibrary equivalent, the <defs> element:
>
>
>
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve
> loper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FSVG%2FElement%2Fdefs&data
> =04%7C01%7Cbrutzman%40nps.edu%7C56a9ba0148dd4f62df6208da02e5e903%7C6d9
> 36231a51740ea9199f7578963378e%7C0%7C0%7C637825483733041551%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> CI6Mn0%3D%7C3000&sdata=%2B%2FgRkY6oSv48yubNQLWaarKfzrw0SnvWROSlbIb
> %2FtuU%3D&reserved=0
>
>
>
> -Andreas
>
>
>
> Date: Mon, 7 Mar 2022 21:29:41 +0100
> From: Michalis Kamburelis <michalis.kambi at gmail.com>
> To: Joseph D Williams <joedwil at earthlink.net>
> Cc: GPU Group <gpugroup at gmail.com>,  "X3D Public Mailing List
>         (x3d-public at web3d.org)" <x3d-public at web3d.org>
> Subject: Re: [x3d-public] X3DParticleEmitter node inherit from
>         X3DChildNode(rather than X3DNode)
> Message-ID:
>         
> <CAKzBGZNToR-7CmaUzRxBE3xx9J6j2mPgmvKAjQKpGQxjdY_0hA at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Perhaps I should have written
>
> """
> The nodes within NodesLibrary don't make any effect, they are not 
> traversed. They are only to be reUSEd (referenced) by other parts of 
> the graph."
> """
>
> This makes the wording consistent with how e.g. Switch is described.
> Sure you have all the nodes in memory, you just don't traverse to 
> inactive parts of Switch, LOD, NodesLibrary etc.
>
> Regards,
> Michalis
>
>
>
>
> --
>
> Andreas Plesch
> Waltham, MA 02453
>
>
>
>
>
>
> --
>
> Andreas Plesch
> Waltham, MA 02453
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5353 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220311/7b4066f8/attachment.p7s>