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

Mon Mar 7 08:41:30 PST 2022

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220307/560fe5f1/attachment.html>