[x3d-public] X3D minutes 28 APR 2022: 3DBODY.TECH, Smart Cities, four Mantis issues reviewed, endgame for X3D4

Fri May 6 04:17:11 PDT 2022

Thank you!

czw., 5 maj 2022 o 04:05 Brutzman, Donald (Don) (CIV)
<brutzman at nps.edu> napisał(a):
>
> We concur, with thanks, and have made that deletion.
>
> Dick and I have recommended that (a) your access get restored, and (b)
> Mantis issues can be open, since there are no member-only Mantis issues to
> block for X3D.  Now is an especially good time for that since ISO national
> bodies will soon be reviewing X3D4 Draft International Specification (DIS)
> version.  Consortium leadership team and members are in charge of that
> decision.
>
> Uh, membership has value:  https://www.web3d.org/join
>
> 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: Tuesday, May 3, 2022 2:50 PM
> To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> Cc: X3D Public Mailing List (x3d-public at web3d.org) <x3d-public at web3d.org>;
> consortium at web3d.org; bod at web3d.org
> Subject: Re: [x3d-public] X3D minutes 28 APR 2022: 3DBODY.TECH, Smart
> Cities, four Mantis issues reviewed, endgame for X3D4
>
> NPS WARNING: *external sender* verify before acting.
>
>
> As for emissiveColor and related edits:
>
> 1. Note that I don't have access to Mantis anymore. I receive emails from
> it, but cannot login or comment there. My membership has expired few days
> ago and at this point I only have free "Community Membership".
>
> 2. The edits to UnlitMaterial look good.
>
> 3. I have some issues with edits to "11.2.2.5 Points and lines rendering",
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/
> components/rendering.html#PointsLinesRendering
> .
>
>     Specifically I very object to sentence "Failure to include emissive
> colors may result in these geometry nodes not being rendered." there. It's
> very unclear, and also untrue :) I would urge to just remove this sentence.
>
>     There is a prose, right below, that actually makes the situation clear.
>
>     - You don't need to specify emissive color explicitly (just like in all
> X3D, we always have defaults that are used when you don't specify
> something). And the points and lines will never just "not be rendered". The
> question is only what (if any) lighting calculation will be performed on
> lights/points.
>
>     - The prose there says that UnlitMaterial with points and lines works
> completely OK (whether you specify emissive colors or let the defaults be
> used).
>
>     - It also says that, when normals are provided, actually all material
> types work as normal (which is super-useful for rendering point clouds that
> approximate meshes and thus have a concept of inside/outside).
>
>     - I think it really covers the cases, and makes situation useful and
> clearly defined for users and implementors. Please remove the ambiguous and
> conflicting statement "Failure to include emissive colors may result in
> these geometry nodes not being rendered." :)
>
> Regards,
> Michalis
>
> sob., 30 kwi 2022 o 02:46 Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> napisał(a):
> >
> > Attendees:  Anita Havele, Nicholas Polys, Don Brutzman. Regrets: Dick Puk.
> We worked together for 2 hours today, minutes follow.
> >
> >
> >
> > Web3D 2022 Call for Papers
> >
> >
> >
> > https://www.web3d.org/news-story/web3d-2022-call-papers
> >
> >
> >
> > We discussed upcoming conference this fall.
> >
> >
> >
> > 13th 3DBODY.TECH Conference & Expo
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > 3dbody.tech%2F&data=05%7C01%7Cbrutzman%40nps.edu%7C7d297a0b922f413
> > 3eb3e08da2d4eec8b%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C6378721
> > 14270006863%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> > IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eWBsE%2BlO6
> > VZvihWDQ4FqHt58W6HgjA0E4hzaKld%2BmRM%3D&reserved=0
> > The Premier Multidisciplinary International Conference and Exhibition
> > on 3D Human Body Scanning and Processing Technologies 3DBODY.TECH
> Conference & Expo provides a platform of eminent professionals,
> entrepreneurs, academicians and researchers across the globe to present,
> learn and discuss the latest in 3D human body scanning and processing
> technologies. The multidisciplinary character of 3DBODY.TECH makes it unique
> and not comparable to any other meeting related to 3D body technologies.
> >
> >
> >
> > Of interest is that this immediately precedes Web3D Conference.
> >
> >
> >
> >
> >
> > ISO, INCITS H3 and W3C liaison: weekly issues check.
> >
> >
> >
> > Interesting draft work is proceeding on Guidelines for Representation and
> Visualization of Smart Cities.
> >
> >
> >
> > We are engaged in this effort and encouraging use of structured data and
> X3D visualization across several dozen ISO standards, motivated so that
> Smart Cities might have a coherent basis for information presentation and
> interaction.  Much lead-in work was performed at workshops and in papers at
> the past two Web3D Conferences.
> >
> >
> >
> > Abstract. "Developers and users of any smart city will need tools to
> evaluate and examine options and trade-offs, and predict outcomes. Parts or
> all of a smart city would need to be modelled, and smart city functions need
> to be simulated to evaluate possible results. The modelling and simulation
> of smart city functions relies on representation and visualization of the
> data. Representation and visualization of smart cities will enable
> prototyping, demonstration, and analysis of smart city concepts for further
> development. Both physical/geometric and semantic data will need to be
> represented and visualized."
> >
> >
> >
> > "Representation and visualization of smart cities is a prime application
> for an integrated approach to leverage standardization since no single
> standard will address all requirements. This document provides guidelines as
> to what needs to be represented for smart cities and how this can be
> achieved. This technical specification will define categories of data
> associated with smart cities, and the requirements for their representation
> and visualization. It will describe how ISO/IEC JTC 1/SC 24 standards
> including SEDRIS and X3D can be applied to represent and visualize urban
> infrastructure, services, and features. Use cases are presented that explore
> how these standards could be applied in smart city analysis and
> visualization applications."
> >
> >
> >
> >
> >
> > Web3D Consortium members can request a copy of this document and comment,
> if they like.  We will be voting prior to May 11.
> >
> >
> >
> > Web3D membership has value!  Please join, if you haven't already.
> >
> >
> >
> > https://www.web3d.org/join
> >
> >
> >
> >
> >
> > Dick and I had a big 2-week review, resolving or improving over 60 Mantis
> issues.   Change list for 19-28 April is attached.
> >
> >
> >
> > Web3D Mantis Issue List
> > https://www.web3d.org/member-only/mantis/view_all_bug_page.php
> >
> >
> >
> > Several issues have been pushed to the list requesting comment.  About 50
> additional issues remain. the finish line is almost visible!
> >
> >
> >
> > During the call, we will work towards achieving consensus on a handful of
> lingering discussion issues.  All inputs are welcome.
> >
> >
> >
> > X3D4 Architecture, latest
> > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/P
> > art01/Architecture.html
> >
> >
> >
> >
> >
> > We reviewed Michalis Kamburelis message
> >
> >
> >
> > [x3d-public] ambientIntensity [0, 1] or unbounded [0, infinity) ?
> > http://web3d.org/pipermail/x3d-public_web3d.org/2022-April/017278.html
> >
> >
> >
> > regarding
> >
> > Mantis 130: 17.2.2: Lighting Max Values
> > https://www.web3d.org/member-only/mantis/view.php?id=130
> >
> >
> >
> > We agreed on rationale for his first proposed solution:
> >
> > "1. Ignore, i.e. leave ambientIntensity in [0,1]. Just because
> >
> >     there's no practical reason to change it."
> >
> >
> >
> > Thanks for another great response Michalis.
> >
> >
> >
> >
> >
> > We worked to ensure that authors rendering points, lines or UnlitMaterial
> geometry include emissive values.
> >
> >
> >
> > 1347: UnlitMaterial emissiveColor has incorrect default value? no,
> > must remain 1 1 1, modify X3DOneSidedMaterialNode
> > https://www.web3d.org/member-only/mantis/view.php?id=1347
> >
> >
> >
> > Confirmed reasonableness of removing emissiveColor from
> X3DOneSidedMaterialNode so that no overrides are necessary for differing
> default values.  This is a common X3D design practice.
> >
> >
> >
> > Some wording improvements for clarity:
> >
> > 12.3.4 X3DOneSidedMaterialNode
> > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/P
> > art01/components/shape.html#X3DOneSidedMaterialNode
> > The emissiveColor field is defined in implementing nodes (albeit with
> differing default values). The emissiveColor and emissiveTexture fields
> enable an author to model "glowing" objects. This can be useful for
> displaying unlit (pre-lit) models (where the light energy of the room is
> computed explicitly), or for displaying scientific data. Application of
> emissive color values has an essential role when rendering points
> (PointSet), lines (LineSet and IndexedLineSet), and geometry rendered with
> unlit materials. To display an "unlit" object (whose visible color should
> not be modified by any light in the scene), an author can use an
> UnlitMaterial node.
> > The emissiveTexture RGB channel is multiplied with the emissiveColor to
> yield the emissiveParameter in the lighting equations. Further information
> is provided in 11.2.2.5 Points and lines rendering.
> >
> > Also included improvements to
> >
> > X3D4 Architecture, 11.2.2.5 Points and lines rendering
> > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/P
> > art01/components/rendering.html#PointsLinesRendering
> > Emissive colors are primary means of rendering these nodes. The
> emissiveColor and fields typically control these "glowing" effects. Failure
> to include emissive colors may result in these geometry nodes not being
> rendered.
> >
> >
> >
> >
> >
> > We discussed inclusion of markerType providing symbology for point
> displays, deciding against.
> >
> >
> >
> > Mantis 1393: 12.4.7 PointProperties missing markerType field
> > https://www.web3d.org/member-only/mantis/view.php?id=1393
> >
> >
> >
> > Nicholas thinks that old markerType values are pretty ancient and not
> useful, further that browser builders are unlikely to implement them.
> Modelers want their own icon/glyph/splat for visualization and interaction.
> >
> > Of further note is that markerType values do not have any existing
> implementations, not meeting our "2 implementations" requirement. There is a
> risk of it being counterproductive and distracting efforts in this
> direction.
> >
> > Downside to removal is small: if markerType not added, then no such
> mechanism exists until X3D4.1 (when it is likely to get resolved fully).
> Meanwhile experimentation is welcome, the "X" in X3D is Extensible.
> >
> > Dick please confirm: we are removing.
> >
> > Nicholas please get 1-2 Mantis issues added describing how to proceed,
> there may be one partial issue on glyphs already.
> >
> >
> >
> >
> >
> > We worked further on improvements to Switch and LOD when a descendant node
> is bound.  Currently such behavior is undefined.
> >
> >
> >
> > Mantis 1192: 07.2.2 Bindable children nodes - Undefined results if
> > bindable node is under Switch or LOD is problematic
> > https://www.web3d.org/member-only/mantis/view.php?id=1192
> >
> >
> >
> > Analysis during X3D Working Group call:
> >
> > a. Switch would keep each binding stack aligned with whichever child was
> active, thereby binding and unbinding nodes whenever the Switch level is
> modified.
> >
> > b. LOD would have all of its child bindable nodes on the binding stack
> throughout, so that user experience was consistent. For example, it would
> make no sense for Viewpoints to get arbitrarily unbound and bound, based on
> range to viewer, as a user independently navigated through a scene.
> >
> > c. LOD attempting to maintain author intent has access to all Viewpoint
> nodes on binding stack, and range-to-viewer LOD transitions are either
> flexible suggestions (browser-optimization control) or rigidly enforced
> (forceTransitions field is TRUE). Thus if a node is subsequently bound by
> user in a different inactive LOD child branch, then that binding event is
> honored and that LOD child branch becomes the active child branch. This
> binding event (and changed LOD child branch selection) takes precedence over
> browser range/performance considerations, and also takes precedence over
> whatever value is provided in forceTransitions field. (Example: selecting a
> room Viewpoint while in a large building model).
> >
> > d. NavigationInfo, Background and Fog binding stacks and responses to
> binding events should behave identically to Viewpoint. Variations would be
> exceedingly complex and not understandable. Consistency means that author
> intent and user action always take precedence, for Switch and LOD response.
> >
> > Spec editors work on integrating these principles as specification prose
> (we are close already) and report back recommended changes to X3D working
> group.
> >
> >
> >
> > IMO this will significantly help user-sensible scalability of huge
> (perhaps Metaverse-scale) models using many Inline and prototype nodes,
> enabling predictable and performant navigation and traversal throughout.
> >
> >
> >
> >
> >
> > Endgame plan for X3D4 Architecture specification.:
> >
> >
> >
> > The next few weeks are good for final member + public review.
> > We will continue resolving editorial Mantis issues, deliberately at best
> speed.
> > Unfinished/undemonstrated functional issues are marked as X3D4.1 for
> future work.
> > We expect to submit Draft International Specification (DIS) during last
> half of May, around 2-3 weeks from now.
> >
> >
> >
> > Vince, please confirm this plan aligns with our Consortium bylaws and
> practices documents. Thanks in advance for making sure we don't overlook any
> steps.
> >
> >
> >
> > Anita please supervise any formal ascertainment by Board and Membership,
> as needed.
> >
> >
> >
> > Thanks for all contributions and all progress, getting Extensible 3D (X3D)
> Graphics version 4 finally ready to ship.
> >
> >
> >
> > 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