<div dir="ltr">Matrix transform class implementation in different toolkits:<div><br>X3DOM: <a href="https://github.com/x3dom/x3dom/blob/master/src/nodes/Grouping/Transform.js">https://github.com/x3dom/x3dom/blob/master/src/nodes/Grouping/Transform.js</a><br><br>X_ITE: <a href="https://github.com/create3000/x_ite/blob/master/src/x_ite/Components/Grouping/Transform.js">https://github.com/create3000/x_ite/blob/master/src/x_ite/Components/Grouping/Transform.js</a><br><br>Three.js: <a href="https://threejs.org/docs/#manual/en/introduction/Matrix-transformations">https://threejs.org/docs/#manual/en/introduction/Matrix-transformations</a><br><br>TypeScript: TBD, not checked in. Cannot unpack zip on my server.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 9, 2020 at 12:07 AM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@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="ltr">Trying to understand why SAI is so difficult to take out of X_ITE and put in X3DOM.<div><br></div><div>Under x3dom, there's:</div><div><br></div><div><font face="monospace">~/x3dom/src/nodes (master)<br>$ ls<br>BVHRefiner/ Geometry3D/ Navigation/ Sound/<br>CADGeometry/ Geometry3DExt/ Networking/ Text/<br>Core/ Geospatial/ NURBS/ Texturing/<br>CubeMapTexturing/ Grouping/ PointingDeviceSensor/ Texturing3D/<br>EnvironmentalEffects/ H-Anim/ Rendering/ Time/<br>EventUtilities/ Interpolation/ RigidBodyPhysics/ VolumeRendering/<br>Followers/ Layout/ Shaders/<br>Geometry2D/ Lighting/ Shape/<br></font></div><div><div><br></div><div>Under X_ITE, there's:</div><div><br></div><div></div></div><div><font face="monospace">~/x_ite/src/x_ite (master)<br>$ ls Browser/ Components<br>Browser/:<br>Core/ Navigation/ Sound/<br>EnvironmentalEffects/ Networking/ Text/<br>Followers/ NURBS/ Texturing/<br>Geometry2D/ ParticleSystems/ Texturing3D/<br>Geometry3D/ Picking/ Time/<br>Geospatial/ PointingDeviceSensor/ VERSION.js<br>Interpolation/ Rendering/ VolumeRendering/<br>KeyDeviceSensor/ RigidBodyPhysics/ X3DBrowser.js<br>Layering/ Scripting/ X3DBrowserContext.js<br>Layout/ Shaders/<br>Lighting/ Shape/<br><br>Components:<br>Annotation/ H-Anim/ Rendering/<br>CADGeometry/ Interpolation/ Rendering.js<br>Core/ Interpolation.js RigidBodyPhysics/<br>Core.js KeyDeviceSensor/ Scripting/<br>CubeMapTexturing/ Layering/ Shaders/<br>DIS/ Layering.js Shaders.js<br>EnvironmentalEffects/ Layout/ Shape/<br>EnvironmentalEffects.js Lighting/ Shape.js<br>EnvironmentalSensor/ Lighting.js Sound/<br>EnvironmentalSensor.js Navigation/ Sound.js<br>EventUtilities/ Navigation.js Text/<br>Followers/ Networking/ Text.js<br>Followers.js Networking.js Texturing/<br>Geometry2D/ NURBS/ Texturing.js<br>Geometry3D/ ParticleSystems/ Texturing3D/<br>Geometry3D.js Picking/ Time/<br>Geospatial/ PointingDeviceSensor/ Time.js<br>Grouping/ PointingDeviceSensor.js VolumeRendering/<br>Grouping.js ProjectiveTextureMapping/ X_ITE/</font></div><div><font face="monospace"><br><br></font></div><div><font face="monospace">Suggestion: We create test cases with X3dToES5.xslt (or similar) targeting X_ITE's SAI. Once we have that working satisfactorily, we go ahead and write either an XSLT file or Python file to generate additional classes not currently covered by X_ITE.</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">I think that Holger would appreciate the additional help on testing and fleshing out the X_ITE SAI.</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">This seems like a good thing to do, and I am accepting of it.</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">John</font></div><div><font face="monospace"><br></font></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 25, 2020 at 8:47 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">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">Hi John, Don,<br>
<br>
I am trying to follow the discussion somewhat but have quite limited<br>
availability now.<br>
<br>
Here are some considerations, unfortunately quite unconnected.<br>
<br>
Ecmascript best practices<br>
<br>
It is not clear that there are commonly accepted standards since the<br>
language is forgiving having evolved so much. But here are perhaps<br>
some guides. An often encountered viewpoint is that the language is<br>
not very OO oriented but rather functional in nature. So OO principles<br>
do not necessarily apply but could be used anyways. There are now<br>
classes in Ecmascript although my understanding is that they are<br>
largely considered syntactical sugar. Another principle is that since<br>
it is a largely interpreted language which relies on garbage<br>
collection, object reuse is favored over object creation and<br>
destruction. Three.js, for example, is very strict about this, and<br>
part of the reason why it is performing well. x3dom is not very strict<br>
about this on the other hand, and still does ok. As node.js is a<br>
target one needs to be careful to distinguish between DOM/browser<br>
features and language features. Node.js natively does not have DOM<br>
methods but a DOM and methods can be added with a library. Also, keep<br>
in mind that currently there is no X3D runtime for node.js.<br>
x3dom/x_ite cannot be run in node.js. So one, expensive, experiment<br>
would be to try to extract a node compatible runtime by separating the<br>
rendering and input controls out of these engines.<br>
<br>
Scene Authoring/Construction versus Scene Access<br>
<br>
Ecmascript differs from Python or Java in that it is the primary<br>
language for X3D scripts used internally in scenes, and externally to<br>
access scenes in running browsers. This is what the current SAI spec.<br>
defines, and what I understand to be Scene Access. This includes but<br>
is not limited to constructing new nodes and entire scenes<br>
programmatically. In addition to construction, SAI also allows for<br>
controling a browser, and modifying a running scene. In contrast,<br>
X3DJ/PSAIL is limited to constructing and authoring a scene which can<br>
eventually be serialized as xml or json, and be used to load into X3D<br>
browser. It seems perhaps prudent for now to parallel X3DJSAIL and<br>
just focus on scene authoring, and not be concerned about live scene<br>
control and modification.<br>
<br>
JSON<br>
<br>
Since the X3D JSON encoding now exists, a useful and specific question<br>
is if the Ecmascript JSON.parse() function<br>
(<a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse" rel="noreferrer" target="_blank">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse</a>)<br>
should return a value which can be immediately used by the envisioned<br>
library given a JSON encoded string. Conversely, should the Ecmascript<br>
JSON.stringify() function generate directly X3D JSON encoding if given<br>
a library generated object ?<br>
<br>
-Andreas<br>
<br>
<br>
<br>
On Tue, Mar 24, 2020 at 9:20 AM Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br>
><br>
> John, certainly we need to pay attention to "how" a library conversion is performed. JSweet is promising, and we have a number of conversion approached demonstrated already.<br>
><br>
> But that is distracting and confusing way to solve a problem and leads to "fire, ready, aim!" implementation pathologies.<br>
><br>
> A further risk might be that JSweet might carry through unnecessary Java programming idioms, but presumably they have sorted through that well already.<br>
><br>
> First things first, please. Let's begin with defining design goals. That's how we accomplished creating Java and Python programming-language bindings for X3D.<br>
><br>
> What we really need to understand is "what" a sharable X3D JavaScript library looks like, and how JavaScript programmers might then use it to author interactive X3D models.<br>
><br>
> Authoring use-case environments are<br>
> 1. Script inside X3D scene graph,<br>
> 2. Script in outer HTML5 web page,<br>
> 3. Standalone programmatic use in node.js<br>
><br>
> Now get specific. Recommend listing pseudocode and design patterns for JavaScript Transform class and JavaScript X3D types, comparing:<br>
><br>
> a. X3D ECMAScript specification,<br>
> b. X3D Script code fields (class variables) and methods,<br>
> c. good general-practice OO design pattern(s) in common use,<br>
> d. current X3D JSON approach, is it OK or improvable further?<br>
> e. compare/contrast Transform approach with X3DJSONLD,<br>
> f. compare/contrast Transform approach with X_ITE,<br>
> g. compare/contrast Transform approach with X3DOM,<br>
> h. compare/contrast Transform approach with three.js,<br>
> j. compare/contrast Transform approach with any other javascript libraries of interest,<br>
> i. compatibility of Transform approach with Angular, React, jquery, other common JavaScript frameworks for HTML.<br>
><br>
> We did this kind of comparison for X3D JSON design and it helped make a confusing understandable, eventually leading to good design decisions.<br>
><br>
> If interested parties prepare this kind of comparison, and understand "what" we want that has general appeal, then progress refinement will be straightforward.<br>
><br>
> Many people use JavaScript these days, especially with node.js - check whether they like the result.<br>
><br>
> When you have solid patterns then we convert 4,000 X3D example scenes (from .x3d -> .js) to match, providing unit tests. Lather, rinse, repeat...<br>
><br>
> Hope this outline helps. Good luck out there! 8)<br>
><br>
> all the best, Don<br>
> --<br>
> Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>
> X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br>
<br>
<br>
<br>
--<br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</blockquote></div>
</blockquote></div>