[x3d-public] X3D Specification Review minutes 14 JAN 2021: EnvironmentLight and Environment nodes, SAI 19775-2

Don Brutzman brutzman at nps.edu
Thu Jan 14 11:30:19 PST 2021


Attendees: Dick Puk, Don Brutzman

1. We came up with documentation for EnvironmentLight mantis 1336

2. We came up with documentation for Environment node mantis 1337, this is a stub that will include links to gamma correction dialog.

3. We looked at Scene Access Interface (SAI) 19775-2

* https://www.web3d.org/documents/specifications/19775-2/V3.3

a. Need to indicate version (e.g. this version was X3D 3.3, next version will be X3D 4.0)

b. It looks like github already has a draft 4.0 version present, which is good.

* https://github.com/Web3DConsortium/X3D/tree/master/ISO-IEC19775/ISO-IEC19775-2/ISO-IEC19775-2v4.0/ISO-IEC19775-2v4.0-WD1

c. Don will define tasks (i.e. ant targets) for processing this spec, similar to X3D4 draft spec tasks.  This includes validation and style checks.  Next steps will likely take some initial work to clean up ill-formed HTML, if prior experience is any guide.

d. *Scope*

At first glance the following appears to be focused on client side, which has been our historic context.

"This part of ISO/IEC 19775 specifies a standard set of services that are made available by a browser so that an author can access the scene graph while it is running. Such access is designed to support inspection and modification of the scene graph."

Typically we think of such use as part of Script node, or an HTML script (or maybe even another external program) running... but it might be more than an active node responding to (or modifying) a client scene.  In our last major revision of SAI, it was a merger of Script node functionality and original VRML97 (and early X3D 3.0) External Authoring Interface (EAI) with HTML.

Am thinking (and have stated many times) that we also need to consider headless (non-rendering) server-side use.  By that am thinking not just http server but also standalone applications, environments like Python Jupyter and JavaScript node.js, possibly cloud computing for data-driven data-science pipelines, etc.

If we consider that the terms "running" and "inspection and modification of the scene graph" do not necessary imply live rendering, it may be that the above definition is sufficient already.  But maybe scope needs to be adjusted, since a scene graph is not running when it is built.

Comment on this topic is welcome.

e. Normative references need to be checked up to date.

f. Concepts: recommended reading!  We should compare to X3D4 architecture document changes, which might deserve some matching information here.

More to follow, all contributions welcome.

So... we've started.  Onward we go.

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



More information about the x3d-public mailing list