<div dir="ltr"><div dir="ltr">Added note to glTF lights below:<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 20, 2018 at 1:23 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">ad point clouds: </div><div dir="auto"><br></div><div dir="auto">massive, lighted point clouds should be possible to implement in x3dom/x_ITE as webgl shaders exist. But still significant investment in resources/time.</div><div dir="auto"><br></div><div>ad glTF inline:</div><div dir="auto"><br></div><div dir="auto">EXPORT/IMPORT: I would favor default exporting/importing of all glTF nodes as equivalent X3D nodes using their glTF names or index as DEF names, probably under an inline provided namespace name as prefix.</div><div dir="auto"><br></div><div dir="auto">Scenes: a glTF without a scene but just a collection of nodes is valid. Since the scene graph is then incomplete, it is required not to be rendered. It can be used as a library of resources to be included somewhere else in the X3D. This way a by default imported glTF which only contains a material can be used in a Shape node's material field. Referencing a geometry is trickier since in glTF geometries do not have a name or an index. They are part of a mesh (Shape in X3D). So 'mesh_1' could refer to the complete mesh as a Shape, and 'meshgeometry_1' or just 'geometry_1' to just the geometry of mesh_1.</div><div dir="auto">A single glTF can contain multiple scenes although I have not seen one. X3D could just bail and say undefined, or always render the first one only.</div><div dir="auto"><br></div><div dir="auto">Cameras: almost 1:1 mappable to Viewpoint, except for near/far which correspond to NavigationInfo fields. As such added to Viewpoint list and stack.</div><div dir="auto"><br></div><div dir="auto">Animations: can be mapped to TimeSensor/Interpolator/Route combos. But glTF does not define when an animation begins playing. It is expected that after import the player/app decides that. Most glTF viewer just start playing all animations after loading. Control in X3D would be via imported TimeSensor.</div><div dir="auto"><br></div><div dir="auto">cubicspline: as mode of interpolator.</div><div dir="auto"><br></div><div dir="auto">Lights: glTF itself does not define lights. A proposed material commons extension defines lights but is in limbo.</div></div></blockquote><div><br></div><div>There is now another extension: <a href="https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_lights_punctual">https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_lights_punctual</a> . It defines point, directional and spot lights, largely compatible with X3D lights but has a different recommended attenuation law, and required non-rendering/culling beyond the max. distance. The extension is supported by the glTF blender exporter. There is no ambient light.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">PBR material: cannot be mimicked by Blinn-Phong shading and requires a different set of parameters. In effect, a new PBRMaterial X3D node is needed. Equations for an example shader are provided, but not normative. While not included in glTF, image based lighting (IBL) is often used in glTF viewers. An EnvironmentLight X3D node was proposed.</div><div dir="auto"><br>That became longer than expected. Thanks for reading,</div><div dir="auto"><br></div><div dir="auto">Andreas<br><div dir="auto">---</div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Message: 2<br>
Date: Fri, 16 Nov 2018 18:06:11 +0000<br>
From: "Brutzman, Donald (Don) (CIV)" <<a href="mailto:brutzman@nps.edu" rel="noreferrer noreferrer noreferrer" target="_blank">brutzman@nps.edu</a>><br>
To: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" rel="noreferrer noreferrer noreferrer" target="_blank">x3d-public@web3d.org</a>><br>
Subject: [x3d-public] X3D working group meeting minutes16 NOV 2018:<br>
X3D Semantic Web, X3Dv4<br>
Message-ID: <<a href="mailto:d5aaf236-0290-f122-cb15-1dbcc0954f69@nps.edu" rel="noreferrer noreferrer noreferrer" target="_blank">d5aaf236-0290-f122-cb15-1dbcc0954f69@nps.edu</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
0. Attendees: Anita Havele, Michalis Kamburelis, Vince Marchetti, Christophe Mouton, Nicholas Polys, Dick Puk and Don Brutzman.<br>==============================<br>
3. Primary working group goal is X3D version 4.0.<br>
<br>
X3D Version 4.0 Development<br>
<a href="http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development</a><br>
<br>
New. Can we propose certain parts of X3Dv4 as recommended for implementation testing by the end of the year? Our motivation is encourage accelerated development of the most important capabilities and get them widely available for testing and demonstration. Intended target implementations are X3DOM, X_ITE, Castle Game Engine and perhaps others.<br>
<br>
Candidates:<br>
<br>
a. *3D Printing and Scanning Profile*. Addition of Point size, Point normals, possibly point sprites. Leonard correctly notes that we need to look ASTM E57 mappability/portability as well. Anything else?<br>
<br>
Wikipedia E57: A file format developed by ASTM International for storing point clouds and images.<br>
<br>
ASTM Committee E57 on 3D Imaging Systems<br>
<a href="https://www.astm.org/COMMITTEE/E57.htm" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.astm.org/COMMITTEE/E57.htm</a><br>
<br>
Wikipedia: Point cloud<br>
<a href="https://en.wikipedia.org/wiki/Point_cloud" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://en.wikipedia.org/wiki/Point_cloud</a><br>
<br>
b. *Inline support for glTF and Physically Based Rendering*.<br>
- Michalis notes that required, well-defined glTF lighting model implies experimental X3D lighting-model changes that correspond to).<br>
- Vince described how we need to scope this to Shape/mesh capabilities, or possibly other glTF capabilities also e.g. Camera etc.<br>
<br>
c. Others? *RenderedTexture* might be easy.<br>
<br>
<a href="http://www.xj3d.org/extensions/render_texture.html" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">http://www.xj3d.org/extensions/render_texture.html</a><br>
<br>
TODO: Michalis will post further information<br>
<br>
For CAD Design Printing Scanning group's arena, there is a lot of work going on with STEP. It would be good to consider our best strategies for STEP support in 2019: encourage translators/import/export? Best practices? Native support in X3D?<br>
<br>
This is a year-end opportunity to prioritize the most feasible and valuable next steps for progress. We would publish and prioritize a "short list" of what nodes need to be implemented next.<br>
<br>
Great discussion today! Nicholas and Michalis each have blogs in preparation for release Real Soon Now (RSN).<br>
<br>
We intend to proceed in this direction. I will need help to get this properly proposed publicly by year's end. Who is willing to lead each category?<br>
<br><br>
------------------------------<br>
<br>
End of x3d-public Digest, Vol 116, Issue 20<br>
*******************************************<br>
</blockquote></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Andreas Plesch<br>Waltham, MA 02453</div></div></div></div></div>