[x3d-public] X3D minutes 25 FEB 2022: resolving SpotLightdefaults, Particle Systems animation, resolving many Mantis issues

[John Carlson]

Joe, I am unsure of licensing at this point, so I’ve been reluctant to post
X3D JSON derived from Holger’s work.   I did run X3DJSONLD’s several.sh and
don.sh on many of Holger’s .x3d files, but for simple invocations, it’s
easier to run Saxonica’s xslt3.

Go for it.   If you need help with using X3D JSON on non-web players, let
me know.   I can possibly provide you with a simple script using xslt3.

On Mon, Feb 28, 2022 at 11:05 AM Joseph D Williams <joedwil at earthlink.net>
wrote:

>
>
>    - The *enabled* field enables or disables all contained emitter nodes,
>    without changing values of their respective *on* fields.
>
>
>
> Just specfkngtacular, and show some nice user code structures here. These
> 40.3.1 *X3DParticleEmitterNode*  things are prime for showing how to
> create, transport, and publish these thingees in various encodings then
> always being able to produce canonical xml for validation. x3d json
> encoding guide for these being shown?
>
>
>
>    - a number of node types were not under X3DChildNode as expected
>
>
>
> Are there other nodes like Joint where, as in skeleton, the first Joint
> container is skeleton but other joints from the same root are children?
>
> Can a Joint be a root node? For Hanim, only the first Joint, the root, has
> to be of skeleton which must be of humanoid
>
> Of course it could make perfect use of a Joint node as the root for a
> scene or inline, without a skeleton. Viewpoint not part of Hanim viewpoint
> group is legal.
>
> Even now, most simple examples can mostly work ok just using HAnimJoint,
> and HAnimDisplacer, and others, outside of Humanoid.
>
> Please, for next 4+, just go ahead and include Joint, Segment, Site
> hierarchy and Displacer as ok outside of Humanoid, just dropping Hanim
> prefix, for general use, getting validated structure and keystrokes, not a
> Spec ‘standard’ Humanoid.
>
> How to include a (more aligned with ridgidBody structures?) Joint
> structure and (especially because this is such a useful and common mesh
> animation tool) Displacer upgrade for users not needing a ‘standard’
> Humanoid?
>
>
>
>
>
> Peace and Fun with X3D to All,
>
> https://www.youtube.com/watch?v=P2MoQnBYCqU
>
> Joe
>
>
>
> *From: *Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> *Sent: *Saturday, February 26, 2022 9:17 PM
> *To: *X3D Public Mailing List (x3d-public at web3d.org)
> <x3d-public at web3d.org>
> *Subject: *Re: [x3d-public] X3D minutes 25 FEB 2022: resolving
> SpotLightdefaults, Particle Systems animation, resolving many Mantis issues
>
>
>
> Attendees:  Michalis Kamburelis, Vince Marchetti, Nicholas Polys, Dick
> Puk, Doug Sanden, Don Brutzman.  Regrets and best regards: Anita Havele.
>
>
>
> A good portion of this week’s session continued examination of issues
> discussed in last week’s minutes.  As ever, publicly posted:
>
>
>
>    - [x3d-public] X3D meeting minutes 18 FEB 2022: SpotLight angles,
>    Volume Rendering component
>    -
>    https://web3d.org/pipermail/x3d-public_web3d.org/2022-February/016795.html
>
>
>
> It was great to have Doug with us Friday, sharing his insights from
> extensive implementation of X3D in the FreeWrl project.  Thanks buddy!
>
>
>
>    - http://freewrl.sourceforge.net
>
>
>
> Topics are numbered in order of initial agenda, but listed in order that
> we discussed them.
>
>
>
> = = = = = =
>
>
>
>    1. We first discussed Spotlight defaults.  The prior discussion and
>    minutes were very helpful.  We compared high-resolution  images created by
>    Michalis using view3D (from Castle Game Engine) posted on Twitter.
>
>
>
>    - https://twitter.com/Web3DConsortium/status/1495106530034679810
>    - https://castle-engine.io/view3dscene.php
>
>
>
>    - Mantis 441: 17.4.3 SpotLight -- Default Values
>    - https://www.web3d.org/member-only/mantis/view.php?id=441
>
>
>
> We again all agreed that current outer cutoffAngle was satisfactory, and
> that inner angle beamWidth default deserves changing.  The inner angle
> beamWidth is full intensity, the outer cutoffAngle is region for linear
> dropoff of lighting intensity from full to 0.
>
>
>
>    -
>    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/lighting.html#SpotLight
>    - https://en.wikipedia.org/wiki/Umbra,_penumbra_and_antumbra
>
>
>
> Michalis gave a helpful summary revisit of the issues, noting that
> defaults option (cutOffAngle pi/4, beamWidth pi/8) was best of three.  Doug
> and Don endorsed his assessment of goodness of first defaults.  Of course
> authors can override any value – we are currently seeking best (and perhaps
> most beautiful) default values.
>
>
>
> Dick and Nicholas proposed that an even-better adjustment might be
> possible, showing even-more-obvious central beamwidth, with
> less-overwhelming dropoff in the penumbra… more like what theatrical
> effects might look like.
>
>
>
> Nicholas shared dramatic images illustrating this point.  Looks like outer
> cutoffAngle is less than 10% greater than central beamWidth.  Might want an
> even-narrower SpotLight radius overall.
>
>
>
>    - https://clipartix.com/spotlight-clipart-image-23014
>    -
>    https://media.istockphoto.com/vectors/abstract-blue-spotlight-shiny-vector-id508944706?k=6&m=508944706&s=170667a&w=0&h=Vd6xyzzTBu7EFB68CssxKnsKZl-z0rR6f4MB-EuRsuI=
>
>
>
> So we decided to look even further at this potential improvement.
> Michalis will take another look at possible defaults (cutOffAngle = pi/4,
> beamWidth = almost cutOffAngle but not quite) and share them back as
> example images.  Thanks!
>
>
>
> = = = = =
>
>
>
>    1. We next examined whether X3DParticleSystem might add enabled field
>    to facilitate author control
>
>
>    - Mantis 1380: ability to disable/enable X3DParticleEmitterNode
>    - https://www.web3d.org/member-only/mantis/view.php?id=1380
>
>
>
>    - X3D Architecture, Particle Systems component, 40.3.1
>    *X3DParticleEmitterNode*
>    -
>    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/particleSystems.html#X3DParticleEmitterNode
>    - several positive reasons to add: animation, control, performance,
>    avoid convoluted workarounds
>    - question about whether they should be still shown if enabled set to
>    false… good discussion… drives us towards maybe defining an ‘on’ field
>    instead, much clearer
>    - negative points: none noted
>
>
>
> We will work on draft prose and potential resolution next week. Example:
>
>
>
>    - X3D Architecture, 17.2.1 Light source semantics
>    -
>    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/lighting.html#LightSourceSemantics
>    - “The *on* field specifies whether the light is enabled or disabled.
>    If the value is FALSE, the light is disabled and will not affect any
>    nodes in the scene. If the value is TRUE, the light will affect other
>    nodes according to the 17.2.1.2 Scoping of lights.”
>
>
>
> Suggested addition to 40.3.1 *X3DParticleEmitterNode *follows.
>
>    - “The *on* field specifies whether the particle emitter node is
>    enabled or disabled. If the value is FALSE, the node is disabled and no new
>    particles are generated. If the value is TRUE, particles are generated. If
>    the node is generating particles and value is subsequently set to FALSE,
>    existing particles finish their expected presentation.”
>
>
>
> Since ParticleSystem node includes an emitters array for all active
> emitter nodes, it makes sense to include a boolean field there as well.
> However, we don’t want to force disabled nodes on/off since the author
> might be selective regarding which emitters are on/off.  For
> disambiguation, suggest calling that field *enabled*.
>
>    - The *enabled* field enables or disables all contained emitter nodes,
>    without changing values of their respective *on* fields.
>
>
>
> In the meeting chat, Doug suggested particles would stall in place until
> re-enabled.  Thinking that through after the meeting, it might look strange
> to have particles “hanging” in mid-space, further an author would not have
> a way to clear the field.  And so, think it best that on/off control just
> be connected to particle generation.  If someone really wants
> pause/resume/clear functionality added, that would be appropriate for
> future X3D4.1.
>
>
>
> Serious “eye candy” from Holger and X_ITE: a compelling set of
> implementations demonstrating power of Particle emitter nodes.
>
>
>
>    - https://create3000.github.io/x_ite
>    -
>    https://create3000.github.io/media/examples/ParticleSystems/ConeEmitter/example.html
>    -
>    https://create3000.github.io/media/examples/ParticleSystems/ExplosionEmitter/example.html
>    -
>    https://create3000.github.io/media/examples/ParticleSystems/ForcePhysicsModel/example.html
>    -
>    https://create3000.github.io/media/examples/ParticleSystems/ParticleSystem/example.html
>    -
>    https://create3000.github.io/media/examples/ParticleSystems/PointEmitter/example.html
>    -
>    https://create3000.github.io/media/examples/ParticleSystems/PolylineEmitter/example.html
>    -
>    https://create3000.github.io/media/examples/ParticleSystems/SurfaceEmitter/example.html
>    -
>    https://create3000.github.io/media/examples/ParticleSystems/VolumeEmitter/example.html
>    -
>    https://create3000.github.io/media/examples/ParticleSystems/WindPhysicsModel/example.html
>
>
>
> 9. We next rechecked Interface Hierarchy for X3DChildNode and root node
> type.  At first it looked like a number of node types were not under
> X3DChildNode as expected.  Looking at them again in subsequent review, I
> think we are OK.  Further scrutiny is always welcome, this diagram
> (originally authored by Joe Williams) is central to everything defined in
> X3D scene graph.
>
>
>
>    -
>    https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/concepts.html#InterfaceHierarchy
>
>
>
> Next discussion responses are applied following each of the meeting agenda
> items.
>
>
>
> *From:* Brutzman, Donald (Don) (CIV)
> *Sent:* Wednesday, February 23, 2022 5:22 PM
> *To:* X3D Public Mailing List (x3d-public at web3d.org) <x3d-public at web3d.org
> >
> *Cc:* Nicholas Polys <npolys at vt.edu>; Michalis Kamburelis (
> michalis.kambi at gmail.com) <michalis.kambi at gmail.com>; brutzman at nps.edu
> *Subject:* RE: X3D agenda 25 FEB 2022: resolve SpotLight defaults, other
> Mantis issues
>
>
>
> 6. Also proposed for working-group review, comments welcome:
>
>
>
>    - Mantis 1382: 37.4.10 RigidBody as X3DChildNode (instead of X3DNode)
>    - https://www.web3d.org/member-only/mantis/view.php?id=1382
>
>
>
>    - X3D Architecture, clause 37 Rigid body physics, 37.4.10 RigidBody
>    -
>    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/rigidBodyPhysics.html#RigidBody
>
>
>
> Seems more consistent and practical to have RigidBody as X3DChildNode.
> No problems yet seen, testing with X3DUOM and XMLSpy looks OK.
>
> If there are any difficulties with content model, then do not do it.
> If added, only expected changes are to the node signature and the
> Interface hierarchy.
>
>
>
> *Consensus*: RigidBody changed to implement X3DChildNode.  As expected,
> no problems occurred in X3DUOM.  Changes checked in.
>
>
>
>
>
> *From:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> *Sent:* Wednesday, February 23, 2022 9:24 AM
> *To:* X3D Public Mailing List (x3d-public at web3d.org) <x3d-public at web3d.org
> >
> *Cc:* Nicholas Polys <npolys at vt.edu>; Michalis Kamburelis (
> michalis.kambi at gmail.com) <michalis.kambi at gmail.com>; Brutzman, Donald
> (Don) (CIV) <brutzman at nps.edu>
> *Subject:* X3D agenda 25 FEB 2022: resolve SpotLight defaults, other
> Mantis issues
>
>
>
> 1.      Regular Friday meeting 08-0900 Friday, call information follows.
>
>
>
> Videoconference Connectivity:
>
>    -
>    https://us02web.zoom.us/j/81634670698?pwd=a1VPeU5tN01rc21Oa3hScUlHK0Rxdz09
>    - https://zoom.us/j/148206572  Password 483805
>    - https://www.web3d.org/member/teleconference-information
>
>
>
>    1. Followup on SpotLight default values, concluding considerations
>    from last week
>
>
>    -
>    https://web3d.org/pipermail/x3d-public_web3d.org/2022-February/016795.html
>    - https://twitter.com/Web3DConsortium/status/1495106530034679810
>    - see Twitter images, thanks again to Michalis for compelling examples
>
>
>
> answered in detail above.
>
>
>
>    1. I “discovered” about a hundred more issues on Mantis that were not
>    being tracked, ouch… They are now all “assigned” and being seen by our
>    filters.  The majority are editorial in nature, time-consuming but not
>    requiring working-group inputs.  Will advise when help is needed.
>
>
>    - https://www.web3d.org/member-only/mantis/view_all_bug_page.php
>
>
>
> ouch ouch ouch but no major blockers found... super glad these comments
> (many by Roy Walmsley) weren’t lost, they indeed improve the X3D4 spec.
> onward we go, accelerating uphill…
>
>
>
>    1. Michalis Appearance adjustments: please walk us through this, there
>    are some questions, should be simple.
>
>
>    - Mantis 1381: editorial correction to Appearance texture prose
>    - https://www.web3d.org/member-only/mantis/view.php?id=1381
>
>
>
> Michalis updated the Mantis issue with more information – thank you.  Not
> at all controversial.  Dick and I will perform final review and resolution
> as editors.
>
>
>
>    1. Nicholas + everyone, continue needing your insight for carefully
>    resolving these.
>
>
>
>    - 1380: ability to disable/enable X3DParticleEmitterNode
>    - https://www.web3d.org/member-only/mantis/view.php?id=1380
>
>
>
> answered in detail above, better and better.
>
>
>
>    - 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=1381
>
>
>
> now ready to resolve, RigidBody no longer needs to be listed since it is
> X3DChildNode.
>
>
>
>    - Mantis 499: 41.4.8 ProjectionVolumeStyle - add Fields
>    intensityThresholdFloor, intensityThresholdCeiling ?
>    - https://www.web3d.org/member-only/mantis/view.php?id=499
>
>
>
> Thanks for review Nicholas.  Not needed now in X3D4. Mantis issue deferred
> as possibility in X3D4.1.
>
>
>
>    - Mantis 545: 41.4.2 BoundaryEnhancementVolumeStyle descriptions for
>    opacityFactor and retainedOpacity fields
>    - https://www.web3d.org/member-only/mantis/view.php?id=545
>    -
>    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/volume.html#BoundaryEnhancementVolumeStyle
>
>
>
> Thanks for prose definitions Nicholas.  Descriptions added to
> specification.  Also added following reference:
>
>
>
>    - Mantis 1383: Adding reference to Volume Component
>    - https://www.web3d.org/member-only/mantis/view.php?id=1383
>    -
>    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/bibliography.html#VIS2002
>
>
>
> Finally
>
>
>
>    - Mantis 917: Table 41.7 Volume rendering component support levels -
>    ShadedVolumeStyle shadows support unclear
>    - https://www.web3d.org/member-only/mantis/view.php?id=917
>
>
>
> Reviewed and considered satisfactory, issue is ready for final editors
> review to resolve.
>
>
>
> = = = = = =
>
>
>
>    1. Dare we look ahead?
>
>
>
> Umm, no we don’t!   Too many X3D4 Mantis issues still need to be applied
> for a pristine ISO specification!!
>
>
>
> (after-action discussion by Nicholas and Don follows…)
>
>
>
> Interesting discussion point today: Geospatial implementations are farther
> along than Dick and I had thought… this will deserve further group
> discussion.  Example:
>
>
>
>    - 2019 M56.4 and M7.1 Ridgecrest sequence
>    -
>    https://raw.githack.com/andreasplesch/VR-GeoCal/master/x3dom/RidgeCrest_M7.1.html
>
>
>
> But, if we were to look farther ahead to X3D4.1 beyond some small
> potential improvements, there is perhaps only a short list of major-change
> additions that we are deferring:
>
>
>
>    1. Khronos KTX texture comparison
>
> https://www.khronos.org/ktx
>
>    1. Open Geospatial Consortium (OGC) 3D Tiles
>
> http://docs.opengeospatial.org/cs/18-053r2/18-053r2.htmlW3C
>
>    1. WebXR Device API
>
> https://www.w3.org/TR/webxr
>
>
>
> Further, given X3D4 support for all X3D3 capabilities, glTF rendering, Web
> Audio API and HTML5 itself, it appears there are no barriers to
> implementation simply adding such support to their codebases with full
> expressiveness in X3D scene graph already available.  Wow…
>
>
>
> = = = = = =
>
>
>
> What an amazing team of players!  Today was another impressive high-water
> mark of collaboration by many super experts, truly exhilarating.
>
>
>
> Thanks for all efforts, onward we go.  Have fun with X3D!  8)
>
>
>
> 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
>
>
>
>
> _______________________________________________
> 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/20220228/1d27b557/attachment-0001.html>