[x3d-public] JSweet translation of X3DJSAIL to JavaScript: need specific design goals first
John Carlson
yottzumm at gmail.com
Wed Apr 8 22:07:02 PDT 2020
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/5ec1e8d8/attachment.html>
More information about the x3d-public
mailing list