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

[GPU Group]

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