[x3d-public] X3D minutes 2 OCT 2020: draft X3D4 Shape component, 3 approaches to X3D4 shadows, RenderingEnvironment node, audio concepts
Michalis Kamburelis
michalis.kambi at gmail.com
Fri Oct 2 16:04:08 PDT 2020
I already answered some of it in the previous thread :) See there.
To the new comments in this mail:
1. When you say "shadows" in the context of real-time 3D computer
graphics, people usually think of real-time shadow algorithms. Which
means "shadow maps" or "shadow volumes" usually.
My proposition from previous mail was a start of something that
would make sense for these 2 typical algorithms. That is, add to light
sources:
SFBool shadows FALSE # enable/disable shadows from this light
SFFloat shadowsPriority 0 # in case browser supports only a
limited number of shadow-casting lights, it should prioritize the
light sources with largest priority
I see you explored some other approaches to shadows today, but
remember these are special / of limited use :)
2. As for "occlusionTexture", it is a way to bake ambient occlusion.
See https://en.wikipedia.org/wiki/Ambient_occlusion .
I guess you can consider it an extremely limited way to get
shadows. But it is not dynamic. It just allows to bake, into a
texture, some darker spots. It assumes that the mesh stays static, and
that it is lit by a uniform omnidirectional light. This is generally
not true, but the effect is still sensible to emphasize the mesh
darker spots, so it is used.
3. As for "normalTexture", it has no relation to common shadow
algorithms (shadow maps and shadow volumes). It modifies normal
vectors, which represent the curvature of the surface. It is ignored
e.g. by shadow determination of shadow maps and shadow volumes.
Although there are connected algorithms, like CGE "steep parallax
mapping with self-shadowing" that allow to get some real-time shadows
thanks to the normalmap information.
4. SSAO is a very different technique to get shadows. It is wildly
incorrect, it assumes things about geometry and lighting that are
completely "wild guesses" and generally invalid. However, when applied
with care (to only slightly darken some areas) SSAO makes a pleasant
visual effect, and nobody cares that it's not exactly correct :) And
it is cheap, working in screen space as a post-processing effect.
5. In Castle Game Engine we have
- shadow maps https://castle-engine.io/x3d_extensions_shadow_maps.php
- shadow volumes https://castle-engine.io/x3d_extensions_shadow_volumes.php
- steep parallax with self-shadowing
https://castle-engine.io/x3d_implementation_texturing_extensions.php
- occlusionTexture, if you really count it as a technique to get
shadows, is also supported :), following X3Dv4 spec
- radiance transfer
- SSAO
Regards,
Michalis
pt., 2 paź 2020 o 19:59 Don Brutzman <brutzman at nps.edu> napisał(a):
>
> Review meeting today.
>
> Attendees: Anita Havele, Nicholas Polys, Dick Puk, Don Brutzman. Regrets Michalis Kamburelis.
>
> Confirming: no member-only meeting information is included in these minutes...
>
> ... with one agreed-upon exception: pdf of latest draft X3D4 Shape component attached, taken from current member-only version in github. All review comments welcome.
>
> [0.1] Web3D Teleconference Information
> https://www.web3d.org/member/teleconference-information
>
> > Please use the following link for all Web3D Consortium Meetings.
> >
> > Join URL: https://us02web.zoom.us/j/81634670698?pwd=a1VPeU5tN01rc21Oa3hScUlHK0Rxdz09
>
> Last week's minutes:
>
> [0.2] [x3d-public] X3D minutes 25 SEP 2020: conference, https DOCTYPE, X3D4 PBR Material textures and "mapping" field
> https://web3d.org/pipermail/x3d-public_web3d.org/2020-September/013661.html
>
> [0.3] [x3d-public] ... X3D4 PBR Material textures: all [X3DSingleTextureNode] vice some [X3DTexture2DNode] ?
> https://web3d.org/pipermail/x3d-public_web3d.org/2020-September/013663.html
>
> Late addition to these minutes: section 4 at bottom reports successful transition of default XML schema/DOCTYPE to use https rather than http.
>
> ---
>
> 1. Web3D Outreach and Web3D 2020 Conference
>
> a. X3D in a Box, Anita Havele
>
> [1.0] blog entry "X3D in a Box"
> https://webx3d.org/box-of-x3d
>
> b. Conference registration is FREE and open, schedule going online over next week
>
> [1.1] Web3D 2020 Conference registration
> https://web3d.siggraph.org
>
> With free registration, and with all conference content going online, we may keep registration open... indefinitely. Interesting opportunities to think about.
>
> c. Deadline imminent for Industrial Use Case submissions
>
> [1.2] Web3D Industrial Use Cases Workshop
> https://web3d.siggraph.org/conferences2020/program/
>
> [1.3] Deadline 3 October 2020 (updated): Industrial use cases submission to EasyChair
> https://twitter.com/Web3DConsortium/status/1311832969485512704
>
> d. Web3D Consortium will hold our regular annual Town Hall session during the conference. Big picture getting bigger, looking forward to that discussion!
>
> ---
>
> 2. X3D Shadows
>
> Nicholas brings up a timely topic.
>
> Question: do we now support shadows satisfactorily? Are any more fields needed for scoping (turning on/off) shadows in a scene?
>
> For the new Shape component and X3D4 support of glTF, we think that
> - all the node signatures and field definitions work,
> - prose definitions need some polishing by Dick and Don,
> - good progress achieved on validation and examples.
>
> [2.0] X3D4 Shape Component
> https://github.com/Web3DConsortium/X3D/blob/master/ISO-IEC19775/ISO-IEC19775-1/ISO-IEC19775-1v4.0/ISO-IEC19775-1v4-WD2/Part01/components/shape.html
>
> PDF attached. Of note in draft specification:
>
> =========================
> 12.4.5 Material
> Material : X3DOneSidedMaterialNode {
> [...]
> SFFloat [in,out] occlusionStrength 1 [0,1]
> SFNode [in,out] occlusionTexture NULL [X3DSingleTextureNode]
> SFString [in,out] occlusionTextureMapping ""
>
> "The optional /occlusionTexture/ can be used to indicate areas of indirect lighting,
> typically called /ambient occlusion/.
> Only the /Red/ channel of the texture is used for the computation,
> the other channels are ignored.
> Higher values indicate areas that should receive full indirect lighting
> and lower values indicate no indirect lighting.
> The /occlusionStrength/ determines how much does the occlusion texture
> affect the final result."
> =========================
>
> This seems related but complementary to any other shadowing technique. We need to be careful that everything potentially works together.
>
> Survey of candidate X3D4 shadow techniques follows. Additions and feedback are welcome.
>
> Nicholas reports regarding Fraunhofer IGD:
>
> > Many proposals over the years implemented in different engines ...
> >
> > The IGD approach in X3DOM and InstantReality has two pieces:
> >
> > 1] attributes on Lights
> > shadowIntensity SFFloat inputOutput 0 [0, 1] # intensity of the shadow; 0 is no shadow at all
> >
> > 2] Environment node has shadow and ambientOcclusion parameters, culling parameters etc: a new bindable node:
>
> [2.1] Environment (Standard name: EnvironmentBindable)
> https://doc.instantreality.org/documentation/nodetype/Environment
>
> Several dozen! fields having to do with rendering preferences. Today's nerd herd says "take a look see!" since a lot of cool related potential follows.
>
> Of note is that discussions we had gamma correction a few weeks ago (once again, not fully resolving) is closely related and also aligned with Environment bindable node.
>
> [2.2] [x3d-public] X3DOM Documentation: Gamma Correction (part of long thread)
> https://www.web3d.org/mailman/private/x3d-public_web3d.org/2020-September/013510.html
>
> [2.3] Gamma Correction in Future X3D, Michalis Kamburelis
> https://github.com/michaliskambi/x3d-tests/wiki/Gamma-Correction-in-Future-X3D
>
> Naming: it looks like all of the fields have to do with rendering, perhaps better name is RenderingEnvironment or somesuch.
>
> Quite similar to InstantReality is corresponding definition in X3DOM, plus examples:
>
> [2.4] Node, Environment
> https://doc.x3dom.org/author/EnvironmentalEffects/Environment.html
>
> [2.5] X3DOM Shadow Example
> https://doc.x3dom.org/tutorials/lighting/shadows/example.html
>
> [2.6] TUTORIAL going with example: Shadow Effects
> https://doc.x3dom.org/tutorials/lighting/shadows/index.html
>
> [2.7] Simple Screen-Space Ambient Occlusion (SSA)
> https://doc.x3dom.org/tutorials/lighting/ssOao/index.html
> https://doc.x3dom.org/tutorials/lighting/ssao/example.html
>
> In contrast to the (ambient) occlusionTexture approach currently in X3D4 working draft (attached and [2.0] link above), which is on a per-Material (i.e. per-Appearance per-Shape basis), the SSAO ambient occlusion approach is defined globally for all geometry via the (Rendering)Environment node.
>
> [2.8] Simple Screen-Space Ambient Occlusion (SSAO) Example
> https://www.x3dom.org/examples/simple-screen-space-ambient-occlusion/
>
> Can these two occlusionTexture (local) and SSAO (global) approaches coexist?
>
> Interesting that there are 2 implementations here (InstantReality and X3DOM) with flexibility for multiple algorithmic approaches to shadows.
>
> ---
>
> Next, Castle Game Engine and view3dscene.
>
> Michalis reports:
> "For simple yes/no field in light source, we have (and always had) what we need. Maybe that and some priority SFInt32 (if implementation has limit on light sources casting shadows -- most implementations have). For something more complicated we don't have what we need as 3d industry as a whole hasn't yet decided what is the best shadows algorithm:) E.g. my engine has 3 real-time shadows algorithms implemented."
>
> [2.9] Castle Game Engine, Shadow Maps
> https://castle-engine.io/x3d_extensions_shadow_maps.php
>
> [2.10] Castle Game Engine, Shadow Volumes
> https://castle-engine.io/x3d_extensions_shadow_volumes.php
>
> Different: includes fields for lights and Appearance, other fields. Rather than a holistic scene emphasis like (Rendering)Environment bindable node, it is defining shadow-related parameters on a per-light, per-appearance, per-volume basis.
>
> There might (or might not) be a use case for some objects having shadows, and some objects not having shadows (for example annotations, guideline billboards, etc.)
>
> Does X_ITE have any kind of support for shadows? Not sure of definitive answer... We found an interesting example:
>
> [2.11] X_ITE shadow demo: Mad Flats
> https://create3000.github.io/media/examples/Lighting/DirectionalLight/example.html
>
> Excerpted from that source, X_ITE shadow definition via light:
>
> > <DirectionalLight DEF='Light1'
> > global='true'
> > intensity='0.931818'
> > ambientIntensity='0.383133'
> > direction='-0.598842 -0.417805 -0.683248'
> > shadowColor='0.14 0.0563119 0'
> > shadowIntensity='0.542169'
> > shadowMapSize='2048'/>
>
> Similarity question: do X3DOM (Rendering)Environment shadowing techniques get implemented via lights?
>
> Overlap with X3D SAI Browser services:
>
> [2.12] X_ITE Browser Services, Browser Object, String getBrowserOption (String name)
> https://github.com/create3000/x_ite/wiki/Browser-Services#string-getbrowseroption-string-name
>
> Concept question: do shadows interact in some way with normalTexture bump maps? It would seem the both effect the texture modulation of a *Material but the "bump" is achieved by normal manipulation, not geometry manipulation, so computation of a geometry-occluded shadow would not occur. It that feasible, or desirable, in the general sense for an arbitrary scene? At a minimum we should try to state in the specification the extent to which realistic rendering is possible, noting any limitations involved.
>
> Whoosh... a lot to sum up from this exploration, here goes...
>
> Characterizations:
> a. Shadows are important.
> b. Some shadow effects are currently in X3D4 draft as part of occlusionTexture.
> c. Multiple shadow algorithms are in usage in 3D graphics.
> c. Multiple shadow techniques are available to us now and implemented within X3D4-capable implementations.
> d. (Rendering)Environment node defines preferences for global algorithms. It is bindable and thus variations are author-adjustable.
> e. occlusionTexture seems to be a well-accepted technique (glTF etc.) that defines local (per-Material/Appearance/Shape) effects.
>
> Going forward:
> f. Are these three techniques (global parameters, global/local scoped light, local Shape/Appearance/Material) compatible or mutually exclusive?
> g. If compatible, X3D4 spec can define coexistence by declareing that local effects can override (or else be modified by) global effects.
> h. Are silhouette effects something to consider? Seems so, some discussion regarding geometry tesselation quality and aliasing...
> i. Perhaps we need an anti-aliasing parameter of some sort, presumably an environment parameter?
> (X3DOM and X_ITE both have an antialiasing parameter, albeit in different places)
> j. Any overlap with Browser services, which have some global parameters defined? Yes a few, worth checking but not a blocker.
> k. If all three techniques are compatible, can we propose RenderingEnvironment node and lighting shadow parameters?
>
> Wow and whoa. We've reached a new high plateau with X3D4 advanced rendering and can now see the next visible tip of the mountain... the journey continues.
>
> ---
>
> 3. X3D4 Audio and Sound
>
> Excellent progress towards finalizing the Sound component occurring in weekly meetings, all progress reported on x3d-public mail list.
>
> [3.1] [x3d-public] X3D4 Sound meeting 30 SEP 2020: Web3D 2020 preparations, Gain and ChannelSelector nodes,
> avoiding channel indices via parent-child MFNode field relationships
> https://www.web3d.org/mailman/private/x3d-public_web3d.org/2020-October/013721.html
>
> [3.2] [x3d-public] X3D4 Sound meeting 30 SEP 2020: (part 2)
> https://www.web3d.org/mailman/private/x3d-public_web3d.org/2020-October/013722.html
>
> Definition for review:
>
> > We need an X3D definition for "audio graph" term. Suggested draft:
> >
> > * An /audio graph/ is a collection of nodes structured to process audio inputs and outputs
> > in a manner that is constrained to match the structure allowed by the Web Audio API.
>
> [3.3] Web Audio API
> https://www.w3.org/TR/webaudio
>
> ==============
> Abstract.
> This specification describes a high-level Web API for processing and synthesizing audio in web applications. The primary paradigm is of an audio routing graph, where a number of AudioNode objects are connected together to define the overall audio rendering. The actual processing will primarily take place in the underlying implementation (typically optimized Assembly / C / C++ code), but direct script processing and synthesis is also supported.
> ==============
>
> > We have defined all of the new nodes (beyond Sound, Spatial Sound and AudioClip) to match the terms and capabilities of Web Audio API.
>
> around 20 nodes total, most are visible online at
>
> [3.4] X3D4 Public Working Draft Specification, Sound component, working draft 2, SIGGRAPH July 2020
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/sound.html
>
> > This means a collection of the new nodes, that together can create and process sound, produce a result that needs to inputs for our Sound and SpatialSound nodes. In combination, the output is similar to a computational version of a simple AudioClip node. It is a source, computationally created, whereas the AudioClip is a prerecorded version.
>
> Efi's examples are compelling and improving. Now preparing Web3D 2020 tutorial to accompany accepted conference paper.
>
> > [5] Spatial Sound in X3DOM with Web Audio API
> > http://www.medialab.teicrete.gr/minipages/x3domAudio/index.html
> Audio and sound conceptual overview:
>
> > ========================================
> > Basic stages for flow of sound, from source to destination:
> >
> > a. Sources of sound (perhaps an audio file or MicrophoneSource, perhaps signal processing of channels in audio graph),
> >
> > b. X3D Sound or SpatialSound node (defining location direction and characteristics of expected sound production in virtual 3D space),
> >
> > c. Propagation (attenuation model, may be modified by AcousticProperties based on surrounding geometry),
> >
> > d. Reception point (avatar "ears" or recordable listening point at some location and direction, that "hears" result, with left-right pan and spatialization).
> > ========================================
>
> Questions and improvements welcome. Thinking through whether a diagram might illustrate this.
>
> ---
>
> 4. Changing XML Schema and DOCTYPE references to https
>
> As decided last week, all of the X3D Example scenes (around 4000 total) have been updated and checked in. This revises all variants of each scene. Upload revisions continue.
>
> Summary of correct practice, and corresponding examples:
>
> [4.1] X3D Scene Authoring Hints, Validation of X3D Scenes using DTD and XML Schema
> https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#Validation
>
> [4.2] X3D Resources, Examples: Scene Archives for X3D
> https://www.web3d.org/x3d/content/examples/X3dResources.html#Examples
>
> ---
>
> My goodness these concepts are getting powerful and intense, in very good ways. We're driving hard towards a Web3D 2020 Conference deadline in November.
>
> Have fun with X3D4! 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 http://faculty.nps.edu/brutzman
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
More information about the x3d-public
mailing list