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

Mon Mar 7 12:29:41 PST 2022

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

pon., 7 mar 2022 o 17:41 Joseph D Williams <joedwil at earthlink.net> napisał(a):
>
> > The nodes within NodesLibrary don't make any
>
> > effect, they are not part of the scene graph; they are only to be
>
> > reUSEd (referenced) by other parts of the graph.".
>
>
>
>
>
> Where in the scenegraph do I keep this list that does not appear in the scenegraph until it is USEd?
>
> Thanks.
>
> Joe
>
>
>
>
>
> From: GPU Group
> Sent: Saturday, March 5, 2022 4:49 PM
> To: Michalis Kamburelis
> Cc: X3D Public Mailing List (x3d-public at web3d.org)
> Subject: Re: [x3d-public] X3DParticleEmitter node inherit from X3DChildNode(rather than X3DNode)
>
>
>
> Or 'split' the attributes of children class, to expose something like
>
> listable, and/or switchable (can be in Switch case list)?
>
> Doug Sanden
>
> ChildNode :: Switchable, Listable
>
> EmitterNode :: Switchable, Listable
>
> Then
>
> Library { list [
>
> DEF 'E1' EmitterNode {},
>
> DEF 'E2' EmitterNode {},
>
> DEF 'E3' EmitterNode {}
>
> ]}
>
> EmitterSystem {
>
> emitter Switch { case 0, list [
>
> USE 'E1',
>
> USE 'E2;,
>
> USE 'E3'
>
> ]
>
> }
>
> }
>
>
>
> On Sat, Mar 5, 2022 at 5:32 PM Michalis Kamburelis
>
> <michalis.kambi at gmail.com> wrote:
>
> >
>
> > Thanks for explaining the rationale, I didn't catch that previously.
>
> > OK, now I understand better -- so we agree that such
>
> > X3DParticleEmitterNode, when being used as root node, without being
>
> > "wrapped" in ParticleSystem, would not do anything, right? I mean it
>
> > would not actually emit any particles, because the
>
> > X3DParticleEmitterNode by itself doesn't have enough information how
>
> > to render the particles.
>
> >
>
> > It would only be useful for further reUSE.
>
> >
>
> > In such case, I say we should treat this just like we do with material
>
> > nodes. Or texture nodes. They also cannot be placed at the root node
>
> > of X3D graph, they *have* to be wrapped inside some Shape and
>
> > Appearance.
>
> >
>
> > If you want to use DEF/USE with materials and textures, you just have
>
> > to consent to the fact that the "first occurrence" is kind of special.
>
> > So you cannot do
>
> >
>
> > """
>
> > # INCORRECT EXAMPLE, JUST FOR THE SAKE OF DISCUSSION
>
> >
>
> > DEF MyMaterial Material { diffuseColor 1 1 0 }
>
> >
>
> > Shape { appearance Appearance { material USE MyMaterial } geometry ... }
>
> > Shape { appearance Appearance { material USE MyMaterial } geometry ... }
>
> > Shape { appearance Appearance { material USE MyMaterial } geometry ... }
>
> > """
>
> >
>
> > Instead you have to treat the first occurrence as something special in X3D:
>
> >
>
> > """
>
> > # CORRECT EXAMPLE, this is what you actually can do right now
>
> >
>
> > Shape { appearance Appearance { material DEF MyMaterial Material {
>
> > diffuseColor 1 1 0 } } geometry ... }
>
> > Shape { appearance Appearance { material USE MyMaterial } geometry ... }
>
> > Shape { appearance Appearance { material USE MyMaterial } geometry ... }
>
> > """
>
> >
>
> > This is a conscious design decision in X3D. Some other formats, like
>
> > glTF and Collada, introduce sections in format for a "library of
>
> > materials", "library of textures" to define all the prerequisites
>
> > before you can reference them. X3D, on the other hand, just
>
> >
>
> > - allows to employ DEF/USE for *everything* (advantage of the X3D
>
> > design compared to others)
>
> >
>
> > - but OTOH the "first occurrence" of a reUSEd node in X3D is special,
>
> > it has to DEFine the node (disadvantage of the X3D design compared to
>
> > others).
>
> >
>
> > I don't think we should make special exception for
>
> > X3DParticleEmitterNode. Because, following the rationale, we would
>
> > then need to enable all nodes as root nodes -- e.g. materials and
>
> > textures should also get the same treatment. We often want to reUSE
>
> > them. And this would make a significant confusion in X3D, if we just
>
> > "enable everything as root node".
>
> >
>
> > If anything, we could add to X3D a node like "NodesLibrary { }" that
>
> > can have a list of children, and X3DNode (not only X3DChildNode), with
>
> > explicit definition "The nodes within NodesLibrary don't make any
>
> > effect, they are not part of the scene graph; they are only to be
>
> > reUSEd (referenced) by other parts of the graph.". So, If we do
>
> > anything -> we should do it for absolutely all nodes. Particle
>
> > emitters, materials, textures, and many others are "in the same
>
> > situation" here, as I see.
>
> >
>
> > So for me:
>
> >
>
> > 1. Either we go with the simplest resolution, do nothing.
>
> >
>
> > 2. Or we go for a full solution, that addresses this for all the
>
> > possible nodes, and introduce something like "NodesLibrary". Probably
>
> > not for X3D 4.0, maybe for 4.1 -- first let some browsers try
>
> > implementing it.
>
> >
>
> > I do not see here a valid case to introduce just a specialized
>
> > exception for particle emitter nodes.
>
> >
>
> > Regards,
>
> > Michalis
>
> >
>
> > sob., 5 mar 2022 o 22:31 Brutzman, Donald (Don) (CIV)
>
> > <brutzman at nps.edu> napisał(a):
>
> > >
>
> > > Thanks for these followups Michalis.
>
> > >
>
> > > Also: we didn't have time to go over that on the meeting, but I wanted to point out my notes on particle emitter and X3DChildNode in "X3D agenda 3 MAR 2022: announcements, Mantis issues, NurbsSweptSurface NurbsSwungSurface, planning" . In short: X3DParticleEmitterNode should not be X3DChildNode. The current spec is already correct.
>
> > >
>
> > >
>
> > >
>
> > > 3. We talked at one point about making particle system emitter an X3DChildNode.   I looked at spec,
>
> > >
>
> > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/particleSystems.html
>
> > >
>
> > > , and this would be wrong. The current state of spec is good:  X3DParticleEmitterNode is supposed to be placed within ParticleSystem.emitter field. And ParticleSystem is a X3DShapeNode (which is already X3DChildNode).  So, let's not change anything here. It wouldn't be valid to allow X3DParticleEmitterNode directly inside some grouping nodes.
>
> > >
>
> > > The current specification works for particle emitter nodes, fully agreed about that.  Let’s press a just little bit farther please.
>
> > >
>
> > >
>
> > >
>
> > > The recent motivation for making X3DParticleEmitter node inherit from X3DChildNode (rather than X3DNode) is to allow these nodes to appear as root nodes in a scene, rather than solely within a ParticleSystem node’s emitter field.
>
> > >
>
> > >
>
> > >
>
> > > Mantis 836: 04.3.2 Root nodes - Additional nodes need to be allowed as root nodes
>
> > > https://www.web3d.org/member-only/mantis/view.php?id=836
>
> > >
>
> > >
>
> > >
>
> > > X3D4 Architecture, 40.3.1 X3DParticleEmitterNode
>
> > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/particleSystems.html#X3DParticleEmitterNode
>
> > >
>
> > >
>
> > >
>
> > > X3D4 Architecture, 4.4.2.3 Interface hierarchy
>
> > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/concepts.html#InterfaceHierarchy
>
> > >
>
> > >
>
> > >
>
> > > This might be useful for facilitating DEF/USE re-use of such emitters in a scene with multiple particle emitters.
>
> > >
>
> > >
>
> > >
>
> > > That might also be considered an obscure and perhaps unhelpful use case (since emitters are then allowed to appear in many places within a model’s scene graph.  I’m OK with (= can live with) either approach.
>
> > >
>
> > >
>
> > >
>
> > > So, staying conservative, especially at this stage of development:  does anyone have a better rationale for making the emitter nodes allowed as child nodes?
>
> > >
>
> > >
>
> > >
>
> > > Absent any other reasons for changing we’ll simply keep it unchanged as you’ve indicated.  Thanks for consideration of this small X3D4 model design point.
>
> > >
>
> > >
>
> > >
>
> > > 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: Friday, March 4, 2022 5:09 PM
>
> > > To: GPU Group <gpugroup at gmail.com>
>
> > > Cc: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; X3D Public Mailing List (x3d-public at web3d.org) <x3d-public at web3d.org>
>
> > > Subject: Re: [x3d-public] X3D minutes 3 MAR 2022: announcements, SpotLight default values, NurbsSweptSurface NurbsSwungSurface found in FreeWrl, planning X3DOM WebXR
>
> > >
>
> > > Thank you all for the good meeting!
>
> > >
>
> > > […].
>
> > >
>
> > >
>
> > >
>
> > > Also: we didn't have time to go over that on the meeting, but I wanted to point out my notes on particle emitter and X3DChildNode in "X3D agenda 3 MAR 2022: announcements, Mantis issues, NurbsSweptSurface NurbsSwungSurface, planning" . In short: X3DParticleEmitterNode should not be X3DChildNode. The current spec is already correct.
>
> > >
>
> > >
>
> > >
>
> > > Regards,
>
> > >
>
> > > Michalis
>
> > >
>
> > >
>
>
>
> _______________________________________________
>
> x3d-public mailing list
>
> x3d-public at web3d.org
>
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>