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

Sat Feb 26 21:16:36 PST 2022

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.

= = = = = =

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

= = = = =

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

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

3.	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…

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

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

= = = = = =

10.	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:

a.	Khronos KTX texture comparison

https://www.khronos.org/ktx

b.	Open Geospatial Consortium (OGC) 3D Tiles 

http://docs.opengeospatial.org/cs/18-053r2/18-053r2.htmlW3C 

c.	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         <mailto:brutzman at nps.edu> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220227/837f6084/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5353 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220227/837f6084/attachment-0001.p7s>