<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
Thank you for the update and excellent insights Andreas. Yes we are working towards some form of composition with gltf 2 for X3D v4 such as external shape, and the X3D working group has produced a comprehensive comparison spreadsheet following multiple meetings.
I believe this is undergoing member review and hope that it will be released soon for even broader comment. There is a lot of promise and potential here, further progress will be great!<br>
<br>
<div id="AppleMailSignature"><span style="font-family: Helvetica; font-size: medium; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-text-size-adjust: auto; ">Sent
from my handheld device</span></div>
<div><br>
On Dec 8, 2017, at 13:05, Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div><span>x3dom currently supports gltf 1.0 content with an ExternalGeometry and</span><br>
<span>an ExternalShape node. The ExternalGeometry node picks out just a</span><br>
<span>named geometry from a gltf scene, and the ExternalShape either a</span><br>
<span>single named node with geometry and material, or the complete scene,</span><br>
<span>as a group.</span><br>
<span></span><br>
<span>Lights, cameras (viewpoints), animations, skinning, morphing are all ignored.</span><br>
<span></span><br>
<span>gltf 2.0 is aggressively pushed to phase out gltf 1.0 because it has a</span><br>
<span>better design and has required material support in the form of</span><br>
<span>PBR-metallic-roughness. A lot of content is already available in gltf</span><br>
<span>2.0 format. So the question becomes if x3d should start to</span><br>
<span>interoperate with gltf directly or just in the form of translators.</span><br>
<span></span><br>
<span>The main benefit to support gltf for x3dom was to gain fast, efficient</span><br>
<span>loading of large meshes in a binary format (binary gltf or .glb is</span><br>
<span>very similar to src). It is possible to use blender for just geometry</span><br>
<span>modelling, and then to export as gltf 2.0. There are other and will be</span><br>
<span>more gltf exporting modellers as well. So this is still a valuable</span><br>
<span>goal and ExternalGeometry may persist.</span><br>
<span></span><br>
<span>If this is the case, we may start to ask if and how gltf geometry</span><br>
<span>support should be formalized in the standard. Presumably, gltf would</span><br>
<span>have to become an ISO standard first ?</span><br>
<span></span><br>
<span>It seems also nice to be able to place fully textured gltf models into</span><br>
<span>a x3d scenegraph (say a car) and then use x3d nodes to interact or</span><br>
<span>animate. But such ExternalShape integration requires quite a lot of</span><br>
<span>functionality. The x3d browser will have to know how to shade PBR</span><br>
<span>materials and how to use texture maps for all related parameters</span><br>
<span>similar to common surface shader nodes in view3dscene. Presumably</span><br>
<span>there will have to be then also consideration of how x3d lights work</span><br>
<span>with both, PBR and X3D materials. Since PBR materials would have to</span><br>
<span>able to be rendered, PBR materials may also be exposed outside of gltf</span><br>
<span>ExternalShape content, with a PhysicalMaterial node. However, in</span><br>
<span>x3dom, I think, it would be easier at first to restrict PBR to just</span><br>
<span>gltf content since it would use dedicated shader code anyways.</span><br>
<span></span><br>
<span>For ExternalShape use cases, a translator from gltf to x3d with</span><br>
<span>ExternalGeometry and PhysicalMaterial nodes may be also be a solution.</span><br>
<span></span><br>
<span>I think embedded keyframe animations would need a translator to</span><br>
<span>Interpolators rather than direct support.</span><br>
<span></span><br>
<span>I do not know enough about skinning and morphing and its relation to</span><br>
<span>HAnim to know if translation would be possible. One (key) aspect</span><br>
<span>aspect may be that morphing seems to be designed as deformation in the</span><br>
<span>shader. Not sure how collisions are then typically handled.</span><br>
<span></span><br>
<span>So thinking through this a bit, it may already be useful to start</span><br>
<span>supporting ExternalGeometry for gltf 2.0 in x3dom which may be</span><br>
<span>feasible.</span><br>
<span></span><br>
<span>Any feedback, comments, questions would be very welcome,</span><br>
<span></span><br>
<span>Andreas</span><br>
<span></span><br>
<span>-- </span><br>
<span>Andreas Plesch</span><br>
<span>Waltham, MA 02453</span><br>
<span></span><br>
<span>------------------------------------------------------------------------------</span><br>
<span>Check out the vibrant tech community on one of the world's most</span><br>
<span>engaging tech sites, <a href="http://Slashdot.org">Slashdot.org</a>! <a href="http://sdm.link/slashdot">
http://sdm.link/slashdot</a></span><br>
<span>_______________________________________________</span><br>
<span>X3dom-users mailing list</span><br>
<span><a href="mailto:X3dom-users@lists.sourceforge.net">X3dom-users@lists.sourceforge.net</a></span><br>
<span><a href="https://lists.sourceforge.net/lists/listinfo/x3dom-users">https://lists.sourceforge.net/lists/listinfo/x3dom-users</a></span><br>
</div>
</blockquote>
</body>
</html>