<div dir="ltr"><div dir="ltr">Timo Sturm provided these nodes. The main work is to get to the gltf data to a special shader which in itself is not complex. I think the goal is to proceed to an overdue x3dom release after consolidating into development release with what we have. There would be some time to make adjustments to node signatures perhaps focusing on PhysicalMaterial.<div><br></div><div>The flipped Y axis for texture coordinate is handled in the fragment shader:</div><div><br></div><div><a href="https://github.com/x3dom/x3dom/blob/webVR/src/shader/ShaderPBRMaterial.js#L124">https://github.com/x3dom/x3dom/blob/webVR/src/shader/ShaderPBRMaterial.js#L124</a><br></div><div><br></div><div>The 1 - coord.y should not have a noticeable performance impact. There is currently no way to access the gltf texture coordinates from the x3d scene.</div><div><br></div><div>glTF supports animation of transformation components but does not define exactly when an animation is played, just how long a cycle is. x3dom just plays and loops them but could opt to play once or not play and just provide the equivalent Timesensor, Interpolator and ROUTE nodes for the scene to use as it wants. On the other hand there is no way to EXPORT from a gltf inline.</div><div><br></div><div>-Andreas</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jan 20, 2019 at 3:21 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@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">Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
><br>
> For glTF inline support, PBR shading will be required. The glTF spec. has an example implementation for PBR but for anybody who wants to dive in more, there is the free<br>
><br>
> <a href="http://www.pbr-book.org" rel="noreferrer" target="_blank">http://www.pbr-book.org</a><br>
><br>
> It seems somewhat artificially inflated and is based on ray tracing but explains the foundational PBR concepts in depth, and in code.<br>
><br>
> I just wanted to share that resource but will point out that x3dom will have a PhysicalMaterial node and an EnvironmentLight node which are used by the glTF loader.<br>
><br>
<br>
Cool! I also want to define PhysicalMaterial and EnvironmentLight in<br>
Castle Game Engine, for interoperability with glTF. It will be good to<br>
converge on a single specification for these nodes, and eventually add<br>
it to the X3D 4 specification :) We have the same goals (achieve PBR<br>
in X3D, and achieve it in a way that makes glTF 2.0 -> X3D conversion<br>
straightforward), so I'm sure this will be possible.<br>
<br>
I don't have an exact specification yet (my rough ideas are on<br>
<a href="https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F" rel="noreferrer" target="_blank">https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F</a><br>
, this page collects thoughts and info from our talks on x3d-public :)<br>
).<br>
<br>
Regards,<br>
Michalis<br>
</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>