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

Wed May 4 19:05:22 PDT 2022

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
-------------- 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/20220505/d0008a4b/attachment-0001.p7s>