[x3d-public] X3D meeting minutes, 7 SEP 2018: Specification Relationships, LocalFog, X3D regexes complete

Don Brutzman brutzman at nps.edu
Sat Sep 8 22:19:22 PDT 2018 

Attendees: Dick Puk, Vince Marchetti, Michalis Kamburelis, Anita Havele, Don Brutzman.

Apologies, no advance agenda today.

=========================

1. We reviewed last week's minutes.

	[x3d-public] X3D meeting minutes, Friday 30 AUG 2018
	http://web3d.org/pipermail/x3d-public_web3d.org/2018-August/009369.html

Approved without comment.

=========================

2. X3D Specification Relationships diagram update.

Scrutiny on diagram included following small changes:
- JSON specifications: IETF RFC/schema, 22275:2018, etc.
- Updates to ISO specification dates; Dick will request official copies for working group use.
- Noted relationship to Fast Infoset compression
- Another vertical "bus" line indicating relationship of XML Security to multiple specs

So, this diagram appears to be nearly ready... but we made several changes.  Review remains welcome: please see attached.

Discussion: we will consider adding general requirements for security to X3D v4 Architecture.  In addition to XML Security recommendations there may be additional security specifications to consider for health records, CAD model protection, E-commerce, etc.  A white paper on security considerations (encryption, authentication, metadata for security assertions, etc.) would be helpful to communicate goals with other partners.  All known/relevant links for X3D security considerations follow.  Further additions welcome.

	X3D Resources: Security
	http://www.web3d.org/x3d/content/examples/X3dResources.html#Security

=========================

3. *AreaFog*.  Good discussion on dialog/threads regarding LocalFog ambiguities, including Michalis' excellent analysis.

	X3D Working Group meeting minutes, 27 July 2018: LocalFog
	http://web3d.org/pipermail/x3d-public_web3d.org/2018-August/009290.html

> This node still has important clarity and functionality gaps that prevent greater utility.  I suspect there is a potential future improvement for X3D v4.
> TODO: enter Mantis issue documenting dialog/threads regarding LocalFog, including Michalis' excellent analysis.  This node still has important clarity and functionality gaps that prevent greater utility.  I suspect there is a potential future improvement for X3D v4.

We had an excellent discussion of this issue.  A good example would be a car driving from the highway on the right into the fogbank downtown... using current X3D Fog/LocalFog techniques it would remain unclouded when it reaches downtown, which is unsatisfactory.  Helpful photographic example of desired effect.

	Fog rolls into Seattle from the sea
	https://en.wikipedia.org/wiki/Fog#/media/File:Seattle_Columbia_Pano2.jpg

FogVertex (correction: FogCoordinate) and shader techniques require prior preparation of objects, and thus are inflexible if Inline loading or motion are involved.

Curiously this use case possibly related to shadow algorithms: shadows affect rendering behind an object, and fog affects rendering in front of an object, so they are not the same but functionality of the these effects do need to be defined in compatible ways.

Candidate names: AreaFog, FogBank, FogPatch.  Avoid VolumeFog, it is not related to volume rendering.  Working name: AreaFog.

I'll eventually create Mantis issue and will add to list of X3D v4 potential features.

=========================

4. X3D ECMAScript (JavaScript) specification: Dick and Don continue as ISO editors to reconcile editorial issues, these are going into github.  Work is ongoing.

X3D/ISO-IEC 19777/ISO-IEC 19777-1/ISO-IEC 19777-1 V3.3/ISO-IEC 19777-1 V3.3 DIS Prep

https://github.com/Web3DConsortium/X3D/tree/master/ISO-IEC%2019777/ISO-IEC%2019777-1/ISO-IEC%2019777-1%20V3.3/ISO-IEC%2019777-1%20V3.3%20DIS%20Prep

=========================

5. Completion report X3D Regexes.  Regular expressions for all of the X3D types are complete!  Gosh what a saga.

Unit tests are available in the regex101 links and also in X3DJSAIL.

	X3D Regular Expressions (regexes)
	http://www.web3d.org/specifications/X3dRegularExpressions.html

Just added some error-detection regexes that are independently applied as part of X3D Examples Archives build.xml checking.

	http://www.web3d.org/specifications/X3dRegularExpressions.html#ErrorDetection

Am now performing X3D v4 regression testing against ~2900 open-source X3D Examples scenes using X3DJSAIL, which should apply regex testing against every single attribute found.

	X3D Resources: Examples, Scene Archives for X3D
	http://www.web3d.org/x3d/content/examples/X3dResources.html#QualityAssurance

	X3D Java Scene Access Interface Library (X3DJSAIL)
	http://www.web3d.org/specifications/java/X3DJSAIL.html

Following all due diligence, finally will then apply these improvements to X3D 3.0 through 3.3 schemas.

Thanks for all contributions to get to this high-water mark.  We have a seriously professional set of assets here.

	X3D Resources: X3D Quality Assurance (QA)
	http://www.web3d.org/x3d/content/examples/X3dResources.html#QualityAssurance

=========================

6. We definitely need work done on the table mapping specification status to Web3D process.

	ISO and Web3D Specification Process Timeline
	https://docs.google.com/spreadsheets/d/1Hy6b0kK-th0OEcyxy1taoXqv4liP7YHXjik3Jzhu9rI
     
	Web3d Recommended Standards
	http://www.web3d.org/standards

	Web3D Consortium Standards Strategy
	http://www.web3d.org/strategy

The timeline spreadsheet above might become very useful if restructured and updated.

=========================

7. Future meetings:

- 14 SEP: I will be away next week.  Nicholas and Dick will decide whether to have a meeting to try improving the process timeline.
- 21 SEP. Don can only attend first 30 minutes of X3D call (NPS graduation), remainder is available.
	Topic: consider adding KTX format (from Khronos) as alternative to DDS in ImageTexture3D

- 28 SEP. Michalis topic to clarify usage of quotes and backslashes.

	https://github.com/michaliskambi/x3d-tests/wiki/Clarify-the-usage-of-quotes-and-backslashes-for-MFString-and-SFString-in-XML-encoding

October: We need to discuss Physically Based Rendering and glTF, hopefully Fraunhofer experts can pick a date to participate.  We will

October: Somewhat elated follow-on issue: consistent handling of RGB and grayscale textures.

https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent
	
=========================

Thanks for much serious + productive effort during today's meeting.  Have fun with X3D!  8)

==================================================

[... plus helpful follow-up correction and clarification from Michalis, thanks! ...]

Don Brutzman <brutzman at nps.edu> wrote:
> FogVertex and shader techniques require prior preparation of objects, and thus are inflexible if Inline loading or motion are involved.

A small clarification to the sentence I quoted above:

1. It's not FogVertex, it's FogCoordinate

     The node we mentioned was FogCoordinate. It allows to specify fog
density per-vertex. There is no node in the specification called
FogVertex  The FogCoordinate spec is on
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/enveffects.html#FogCoordinate
.

     Indeed this node is unsuitable because it would require prior
preparation of the "FogCoordinate.depth" values, in the use-case of a
"car traveling through a dense fog like in that Seattle photo".

     (Although (I realized it after the meeting) it would be possible
to recalculate the "FogCoordinate.depth" values from a Script, as it
is an "[in,out]" field. However, this would still be uncomfortable,
you would need to write a script to do it. And it would be slow: each
frame (if the car is moving) you would perform an operation that does
something per-vertex on CPU (since you need to calculate a per-vertex
value). This is not a good idea for performance. If possible, it is
better to do per-vertex calculations in shaders (on GPU).)

2. Shaders are problematic, but for another reason. Namely, that
getting a shader code portable across all X3D browsers is hard.
Moreover, using shaders (as defined in the X3D spec) requires the
author to also implement lighting model from scratch.

     There are solutions for this. My own "Compositing Shaders" work (
https://castle-engine.io/compositing_shaders.php ) presents new nodes
Effect and EffectNode that allow to implement a lot of stuff in
shaders with ease (and without reimplementing lighting model from
scratch). In fact, one of the demos of "Compositing Shaders" presents
a volumetric fog, a more sophisticated effect, calculating fog based
on a 3D noise texture.

     However, this idea is not portable. CGE and FreeWRL are the only
X3D browsers implementing Effect node now.

     I want to emphasize that using shaders would *not* have trouble
handling dynamic stuff, like a moving car. Shaders are great for that.
Everything you see in modern 3D applications is actually done by
shaders, so moving stuff is not a problem

     It's only the "difficulty to make shaders portable across all X3D
browsers" that makes them problematic for this use.

Regards,
Michalis

==================================================

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: X3dSpecificationRelationships.draft.png
Type: image/png
Size: 144639 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180908/ea6531ed/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: X3dSpecificationRelationships.draft.vsd
Type: application/vnd.visio
Size: 113664 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180908/ea6531ed/attachment-0001.vsd>

More information about the x3d-public mailing list