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

Mon Mar 7 09:32:07 PST 2022

At this time, without enhancement, possibly in a Switch node and not the
selected case.

John

On Mon, Mar 7, 2022 at 10:42 AM Joseph D Williams <joedwil at earthlink.net>
wrote:

> > 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 <gpugroup at gmail.com>
> *Sent: *Saturday, March 5, 2022 4:49 PM
> *To: *Michalis Kamburelis <michalis.kambi at gmail.com>
> *Cc: *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)
>
>
>
> 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
>
>
> _______________________________________________
> x3d-public mailing list
> 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/20220307/a10368e0/attachment-0001.html>