[x3d-public] Minutes of X3D WG Meeting Wednesday 6th September 2017 [Public Release]
Roy Walmsley
roy.walmsley at ntlworld.com
Wed Sep 20 07:17:52 PDT 2017
Public Release of the Minutes of the X3D WG meeting held on Wednesday 6th
September 2017 at 0800 PST, 1600 BST 1500 UTC.
Attendees: Roy Walmsley, Leonard Daly, Don Brutzman, Dick Puk, Vince
Marchetti, Nicholas Polys
Apologies received: None
============================================================================
===========================
A. Outstanding matters
1. X3DUrlObject – Mantis issue 1171
New draft text for clause 9.2.3 in ISO/IEC 19775-1
Roy had a further question on this topic, specifically about the instance
when “encoded data” was included directly as one element of the array. He
asked if this encoded data should always commence with an approved scheme?
It was suggested that IETF 7595 (https://tools.ietf.org/html/rfc7595) might
help.
Further discussion ensured, including a short review of X3D’s usage of
Universal Resource Identifiers (URIs). ISO/IEC 19775-1, clause 9.2.1 URLs
(see
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components
/networking.html#URLs) details that X3D supports both Universal Resource
Locators (URLs) and Universal Resource Names (URNs), both of which are
forms of URI. In addition, as indicated by the text at the end of the first
paragraph in this clause, X3D also supports “in-line encoded data”.
It was agreed that “in-line encoded data”, such as script and shader code,
is not in accordance with any IETF standard.
It was noted that using the name “url” for the field is not accurate, since
it can contain more than URLs. This is acknowledged in the node signature
definitions, which is illustrated for the abstract type X3DUrlObject (see
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components
/networking.html#X3DUrlObject) where the url field has the permitted content
“[URI]”. It was also pointed out that HTML uses the name “src”, rather than
“url”.
It was agreed that listing all the permitted content types for the field
would help to clarify the issue.
============================================================================
===========================
B. Summary and Technical reports
Opportunity for anyone to make a short report on Web site, marketing,
communication, specification or technical matters that is not already on the
Agenda.
1. Design Printing and Scanning and Mantis subgroup meeting times
Roy reported that the Web3D calendar had been updated to reflect the new
meeting times agreed for the Design Printing and Scanning (DPS) working
group, and the Mantis subgroup. In addition, the new name for the old CAD WG
has been replaced as necessary.
2. Bugfix X3dToVrml97.xslt
Don reported that the automatic conversion of examples containing
ProtoInstance nodes from X3D to VRML 97 had a flaw. These have now all been
corrected. Furthermore, a better way to validate VRML would be preferred, if
anyone has any ideas.
3. Implementation support: OpenJSCAD and OpenSCAD
Don reported that the above two new resources have been reported on the
public list (see
http://web3d.org/pipermail/x3d-public_web3d.org/2017-September/007445.html).
These will be added to the X3D resources page.
Vince observed that he was seeing a general shift away from server based
computation to browser computation, using JavaScript. He believes that
OnShape is currently the best company offering online professional 3D CAD
modelling.
4. Player support updates: view3dscene (Castle Game Engine), FreeWRL
Don reported (see
http://web3d.org/pipermail/x3d-public_web3d.org/2017-September/007443.html)
that the node inventory comparison spreadsheet (see
http://www.web3d.org/specifications/X3dNodeInventoryComparison.xlsx) has
been updated. The players and tools have been moved to a separate worksheet.
Don noted that the old Wiki page was hard to maintain. Furthermore, the
spreadsheet is maintained under source code control.
This was followed by some general discussion on a potential HTML profile. It
was suggested that it may be better to resolve concept issues first, such as
event models, DEF/USE, Script, although the relevance of DEF/USE to node
selection was questioned.
It was also noted that example scenes are still required for some of the X3D
components.
5. X3DOM node additions, open-source development, community
encouragement
Don reported that there had been good discussions at the latest board
meeting, encouraging open source development. However, the final authority
for the X3DOM open source project still lies with Fraunhofer. Development
leadership changes usually occur by either of two mechanisms – either the
current owner agrees to transfer authority and/or ownership, or someone
forks the repository and takes it forward as a new separate project.
6. X3DOM, Three.js comparison by codeflügel
Don reported (see
http://web3d.org/pipermail/x3d-public_web3d.org/2017-September/007442.html)
that an interesting comparison of X3DOM and three.js has been published by
CodeFlügel.
7. X3D Unified Object Model progress
Don reported continuing progress in refining and improving the X3D Object
Model, with especial thanks to John Carlson. Indexed geometry nodes have
been the subject of the most recent changes.
8. Annotation
A call was made for annotation examples, with thanks to Leonard for the one
he provided (see
http://web3d.org/pipermail/x3d-public_web3d.org/2017-September/007460.html).
Leonard explained that his example, which crosses the 2D/3D boundary with
the label in HTML and the object in X3D, uses Coordinate conversion to link
to the 3D model part. This was done in HTML, since standard HTML processes
can be used to modify either the label, or the 3D object it links to.
============================================================================
===========================
C. Discussion Topics
1. X3D Features Missing list submitted by Michaelis Kamburelis
Reference:
http://web3d.org/pipermail/x3d-public_web3d.org/2017-April/006347.html
Michaelis has included four ‘larger features’ in his prioritized list.
a. CommonSurfaceShader
This has been implemented by X3DOM, InstantReality, and Castle Game
Engine/view3Dscene. Leonard asked if the specification would include code or
pseudo code, but no decision was reached. It was noted that Castle Game
Engine has some predefined extensions. X3DOM does not.
Dick reported that a material specification language has already been
defined, and was probably presented in a BOF at Siggraph 2017, called
Material definition language.
[Co-chair note: This is the NVIDIA Material Definition Language; see
http://www.nvidia.com/object/material-definition-language.html.]
It was proposed that we should look at glTF and see what they do. Leonard
agreed to do this and report.
[Co-chair note: Shortly after the meeting Leonard published his report; see
http://web3d.org/pipermail/x3d-public_web3d.org/2017-September/007470.html.]
It was agreed that the X3D standard needs to specify the parameters required
for an author to be able to define a material appearance in such a way that
it is reproducible by implementations. Put another way, it is preferable to
specify behaviour, rather than how it is to be done.
b. Texture
This proposal was noted to represent a significant change. X3D currently
uses a replacement approach, whereas the proposed method is mixing.
Reviewing the current X3D specification, applying an 8-bit texture to a
surface with a red material colour will result in a colour ranging from
black to bright red. This contrasts with the application of a 24-bit texture
to the red surface, which will replace the red colour entirely with the
texture colours. Both these behaviours are defined in clause 17.2.2.4
Lighting equations (see
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components
/lighting.html#Lightingequations).
Concepts for improving the X3D standard, such as addition of a field, or
even a new node, were put forward. It was agreed that examples showing both
alternatives would be helpful, with screen shots from implementations. It
was suggested that Michaelis be asked if he can supply these.
It was agreed that this topic should be added to the X3D V4 development page
at http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development. Roy
agreed to do this.
c. Shadows
This was not separately discussed, although it was noted the proposals for
CommonSurfaceShader could also be helpful for shadows.
d. Binary Meshes
It was noted that this topic is related to ExternalShape/ExternalGeometry,
and how to include glTF support. These are subjects for further discussion.
Furthermore, compression of scenes, as in an encoding, would be a separate
topic.
Michaelis’ stated goal, of fast delivery to the GPU, was also noted.
============================================================================
===========================
D. Specification work, GitHub, and Mantis issues
Future features Mantis issues review:
* Mantis issue 322 -
http://www.web3d.org/member-only/mantis/view.php?id=322 – 40.4.5
ParticleSystem – Particle Size Control
* Mantis issue 289 -
http://www.web3d.org/member-only/mantis/view.php?id=351 – 8.3.1
X3DTimeDependentNode – New field
Not discussed.
============================================================================
===========================
E. Schedule review
Other topics for discussion not yet assigned are:
Investigate other 3D display capabilities: Glam and CSS.
* GLAM see https://tparisi.github.io/glam/
Timo Sturm of Fraunhofer to talk about advanced materials. Also with Max
Limper re SRC/glTF interoperability, X3DOM support and repeatability.
X3D Integration into HTML: Events
Binary meshes.
September 13th –
September 20th –
September 27th –
October 4th –
============================================================================
===========================
F. Date and time of next meeting
September 13th 2017 at 0800 PDT 1600 BST 1500 UTC
Roy Walmsley
X3D WG co-chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170920/e9f47aef/attachment-0001.html>
More information about the x3d-public
mailing list