[x3d-public] JSweet translation of X3DJSAIL to JavaScript: need specific design goals first

John Carlson yottzumm at gmail.com
Thu Apr 9 16:52:15 PDT 2020


Matrix transform class implementation in different toolkits:

X3DOM:
https://github.com/x3dom/x3dom/blob/master/src/nodes/Grouping/Transform.js

X_ITE:
https://github.com/create3000/x_ite/blob/master/src/x_ite/Components/Grouping/Transform.js

Three.js:
https://threejs.org/docs/#manual/en/introduction/Matrix-transformations

TypeScript: TBD, not checked in.  Cannot unpack zip on my server.


On Thu, Apr 9, 2020 at 12:07 AM John Carlson <yottzumm at gmail.com> wrote:

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


More information about the x3d-public mailing list