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

[GPU Group]

.. But the Group and Switch method of librarizing a scene still
requires ChildNodes. Nodes that aren't ChildNodes aren't allowed by
specs.
So splitting the ChildNode class
ChildNode :: ListItemNode, ChoiceItemNode, RootItemNode
will allow non-child nodes like Material :: ListItemNode to be in a
Library.List but not in Switch or at Root level.
And EmitterNode::ListItemNode, ChoiceItemNode to be in a Library.List
or Switch.Choice but not at Root level.

On Mon, Mar 7, 2022 at 11:18 AM GPU Group <gpugroup at gmail.com> wrote:
>
> Right - that's what I did for a big scene I generated first in collada
> -with its library-like pre-definitions- and then something equivalent
> in x3d.
> http://dug9.users.sourceforge.net/web3d/townsite_2014/townsite.x3d
> <Switch DEF='library_nodes' whichChoice='-1'>
> (library nodes build up here with Groups)
> I used a 2-level build up, defining chunks of geometry, and grouping
> the chunks into big chunks
> <Group DEF='GR_GrpPillWest_L50'>
> <Transform USE='GOB_PillWest_L50'/>
> <Transform USE='GOB_WindowPanes_L50'/>
> <Transform USE='GOB_Steps_001_L50'/>
> <Transform USE='GOB_rGrid1_001_L50'/>
> <Transform USE='GOB_Porch_L50'/>
> <Transform USE='GOB_Chimney_001_L50'/>
> <Transform USE='GOB_Base_L50'/>
> <Transform USE='GOB_Corners_L50'/>
> <Transform USE='GOB_Shingles_L50'/>
> <Transform USE='GOB_Walls_L50'/>
> <Transform USE='GOB_Roof_L50'/>
> <Transform USE='GOB_Chimney_L50'/>
> <Transform USE='GOB_Steps_L50'/>
> <Transform USE='GOB_DoorFrame_L50'/>
> <Transform USE='GOB_WindowFrame_L50'/>
> <Transform USE='GOB_GrpScreenDoor_001_L50'/>
> <Transform USE='GOB_GrpScreenDoor_L50'/>
> <Transform USE='GOB_GrpDoor4panBW_L50'/>
> </Group>
>
> </Switch>
> (main scene goes at bottom)
> then here I could do a transform wapper
> <Transform ..>
> <Group USE='GR_GrpPillWest_L50'/>
> </Transform>
> (I did this by hacking blender x3d exporter)
>
> And the equivalent collada for GoogleEarth had a similar library-like
> predefinition
> (googleEarth kml has the geographic 'placemarks' each of which
> wraps/refers-to a building collada/.dae separately)
> Example .dae with library structure:
> http://dug9.users.sourceforge.net/ACC/AirdrieEarlyYearsBuildings/bfiles/Tshed.dae
> -Doug
>
> On Mon, Mar 7, 2022 at 10:32 AM John Carlson <yottzumm at gmail.com> wrote:
> >
> > 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
> >> 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
> >>
> >>
> >>
> >> _______________________________________________
> >> x3d-public mailing list
> >> x3d-public at web3d.org
> >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org