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

Sat Mar 5 16:31:27 PST 2022

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
>
>