<div dir="ltr">Date: Thu, 3 Nov 2016 17:55:16 -0700<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
From: Leonard Daly <<a href="mailto:Leonard.Daly@realism.com">Leonard.Daly@realism.com</a>><br>
To: X3D Public <<a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>><br>
Subject: [x3d-public] X3Dng Specification Document<br>
Message-ID: <<a href="mailto:26bfe7d1-7876-e1f6-0581-f5fdb5e2066e@realism.com">26bfe7d1-7876-e1f6-0581-<wbr>f5fdb5e2066e@realism.com</a>><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
I have formally submitted the "X3D Next Generation" specification<br>
document for Working Group review. The document is also publicly<br>
available at <a href="http://tools.realism.com/specification/x3d-next-generation" rel="noreferrer" target="_blank">http://tools.realism.com/<wbr>specification/x3d-next-<wbr>generation</a>.<br>
This document describes how X3D (as declarative 3D) is integrated into<br>
the HTML and DOM environment. Many new nodes are added to bring some<br>
capabilities up to current industry practice.<br>
<br>
This document is the initial public draft and may be updated or revised<br>
at any time. The version submitted to the WG is a copy of this content<br>
taken on 2016-11-03.<br></blockquote></div><br></div><div class="gmail_extra">Thanks for taking on this large task and putting together a lot of good material in this initial public draft covering many aspects.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">I wonder if there is a way break up the large set of revisions into a progression of incremental steps to get tangible results (eg. a new spec.) sooner. So perhaps there could be X3D NG after a X3D V4.0 ?<br><br></div><div class="gmail_extra">Is it possible to divorce the introduction of (some) new nodes from HTML5 integration and event revisions ?<br><br></div><div class="gmail_extra">Just thinking about ways to make this task more manageable.<br><br></div><div class="gmail_extra">Here are some more specific reflections after reading:<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Events:<br></div><div class="gmail_extra">x3dom (and cobweb) still uses x3d (style) events for routing: <a href="https://github.com/x3dom/x3dom/blob/master/src/nodes/Core/X3DNode.js#L233">https://github.com/x3dom/x3dom/blob/master/src/nodes/Core/X3DNode.js#L233</a><br></div><div class="gmail_extra">So there may be still a need for x3d events in addition to only using dom events if only for performance reasons. x3dom calls x3d events 'messages' and never implemented timestamping as it does not have a need. (Test route loops ?).<br><br></div><div class="gmail_extra">GeoElevationgrid:<br>is marked deprecated or excluded from the full HTML profile, presumably because it is considered similar to Elevationgrid. However, it is probably the most used node in the Geospatial component and an equivalent geometry cannot easily be generated by Blender or automatic index generation of GeoCoordinates in an IndexedFaceset.<br></div><div class="gmail_extra">With regards to Elevationgrid, I find that my implementation of an equivalent component for A-Frame is relatively popular, more so than my implementation of IndexedFaceset. So for the casual user base there is probably demand and space for such a node.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Color Interpolation: [minor]<br></div><div class="gmail_extra">perhaps consider RGB and HSV (and other color spaces) either as alternatives for COLOR interpolation space (perhaps called COLORRGB and COLORHSV) or as alternative for LINEAR algorithm for COLOR interpolation space.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">-Andreas<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div>