<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">It seems to me that importing glTF
defeats the entire purpose of glTF. It is optimized to deliver
data to the graphics card. An attempt to import that data into X3D
not only looses all of the optimization, it adds overhead
converting into the player's X3D data structure, then back to the
graphics card calls. Also, as others have pointed out, there is no
reason that glTF would be an archive format. It may change as
graphics cards change. That would require the specification and
player to track the changes and make the necessary adjustments.<br>
<br>
glTF animations are potentially full skin animations (weighted and
moved according to bone). These are not necessary H-Anim type
models (they may be trees, mechanical parts, etc.). That would
need to be implemented highly efficiently in X3D before this would
work. There are ways to control animation. I'll get to that below.<br>
<br>
It seems to me that it is much better to use glTF as it was
designed -- import everything into the graphics card. It was the
developer's choice to use that glTF file. Trying to give an X3D
player control over all aspects of the file is the 3D equivalent
of trying to give an X3D player control of individual pixels in an
imported image.<br>
<br>
glTF animations are named; however, there is nothing that requires
the names to be anything useful. A named animation may not even be
a complete motion. For example. the glTF monster (it's in the
repository) has over 20 named animations. All contribute to the
full motion cycle of the monsters. Individual animations are
things like the tail motion, or the movement of the right front
foot. It is possible to identify animations (by name) that are
needed for any particular effect and control them on a
frame-by-frame basis. I don't know all of the details, but it is
available in THREE.js so it can be implemented.<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
<br>
</div>
<blockquote type="cite"
cite="mid:CAKdk67vg1upFR73N_-F_-Zdj32x1cc=w-1EOJdZhGZijM5wA9w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">brutzman@nps.edu</a>><br>
To: X3D Graphics public mailing list <<a
href="mailto:x3d-public@web3d.org"
rel="noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
x3d-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Past Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>