[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