[x3d-public] updates to X3DJSAIL, plus python and java versions of X3DExamples, X3DPSAIL; let Python be Python

[Brutzman, Donald (Don) (CIV)]

Hi John, hope you are well.  Am busy for the next week but here is some more detail for you.

1. Found some possible problems with X3DPSAIL that might be provoking the problem with incorrect node types.

a. mapToMethod.js has a lot of duplication in it in the left-hand side of the associative arrays.  This is probably confusing the heck out of the Java reflection methodology inside pyjnius.   For example, note the repeated entries of "X3DMetadataObject" in the first example, then multiple duplications in the second example:

////////////////////////////
"X3DNode" : {
	"X3DMetadataObject" : "setMetadata",
	"MetadataBoolean" : "setMetadata",
	"MetadataDouble" : "setMetadata",
	"MetadataFloat" : "setMetadata",
	"MetadataInteger" : "setMetadata",
	"MetadataSet" : "setMetadata",
	"MetadataString" : "setMetadata",
	"X3DMetadataObject" : "setMetadata",
},
////////////////////////////
"Appearance" : {
	"FillProperties" : "setFillProperties",
	"FillProperties" : "setFillProperties",
	"X3DConcreteNode" : "setFillProperties",
	"X3DChildNode" : "setFillProperties",
	"X3DNode" : "setFillProperties",
	"X3DAppearanceChildNode" : "setFillProperties",
	"X3DNode" : "setFillProperties",
	"X3DNode" : "setFillProperties",
	"LineProperties" : "setLineProperties",
	"LineProperties" : "setLineProperties",
	"X3DConcreteNode" : "setLineProperties",
	"X3DChildNode" : "setLineProperties",
	"X3DNode" : "setLineProperties",
	"X3DAppearanceChildNode" : "setLineProperties",
	"X3DNode" : "setLineProperties",
	"X3DNode" : "setLineProperties",
	"X3DMaterialNode" : "setMaterial",
	"Material" : "setMaterial",
	"TwoSidedMaterial" : "setMaterial",
	"X3DMaterialNode" : "setMaterial",
	"X3DAppearanceChildNode" : "setMaterial",
	"X3DNode" : "setMaterial",
	"X3DNode" : "setMaterial",
	"X3DMetadataObject" : "setMetadata",
	"MetadataBoolean" : "setMetadata",
	"MetadataDouble" : "setMetadata",
	"MetadataFloat" : "setMetadata",
	"MetadataInteger" : "setMetadata",
	"MetadataSet" : "setMetadata",
	"MetadataString" : "setMetadata",
	"X3DMetadataObject" : "setMetadata",
	"PointProperties" : "setPointProperties",
	"PointProperties" : "setPointProperties",
	"X3DConcreteNode" : "setPointProperties",
	"X3DChildNode" : "setPointProperties",
	"X3DNode" : "setPointProperties",
	"X3DAppearanceChildNode" : "setPointProperties",
	"X3DNode" : "setPointProperties",
	"X3DNode" : "setPointProperties",
	"X3DShaderNode" : "addShaders",
	"ComposedShader" : "addShaders",
	"PackagedShader" : "addShaders",
	"ProgramShader" : "addShaders",
	"X3DShaderNode" : "addShaders",
	"X3DAppearanceChildNode" : "addShaders",
	"X3DNode" : "addShaders",
	"X3DNode" : "addShaders",
	"X3DTextureNode" : "setTexture",
	"X3DEnvironmentTextureNode" : "setTexture",
	"ComposedCubeMapTexture" : "setTexture",
	"GeneratedCubeMapTexture" : "setTexture",
	"ImageCubeMapTexture" : "setTexture",
	"X3DTexture2DNode" : "setTexture",
	"ImageTexture" : "setTexture",
	"MovieTexture" : "setTexture",
	"PixelTexture" : "setTexture",
	"X3DTexture3DNode" : "setTexture",
	"ComposedTexture3D" : "setTexture",
	"ImageTexture3D" : "setTexture",
	"PixelTexture3D" : "setTexture",
	"MultiTexture" : "setTexture",
	"X3DTextureNode" : "setTexture",
	"X3DAppearanceChildNode" : "setTexture",
	"X3DNode" : "setTexture",
	"X3DNode" : "setTexture",
	"X3DTextureTransformNode" : "setTextureTransform",
	"MultiTextureTransform" : "setTextureTransform",
	"TextureTransform" : "setTextureTransform",
	"TextureTransform3D" : "setTextureTransform",
	"TextureTransformMatrix3D" : "setTextureTransform",
	"X3DTextureTransformNode" : "setTextureTransform",
	"X3DAppearanceChildNode" : "setTextureTransform",
	"X3DNode" : "setTextureTransform",
	"X3DNode" : "setTextureTransform",
},
////////////////////////////

I believe you create this via mapToMethodGenerator.js - might you be able to filter duplicates?

------

b. Additionally, *all of the X3D node types on the left-hand side above are suspect* because X3DJSAIL only uses node types as a Java-based shorthand.  I am wondering if all are eliminated completely, that might force Pyjnius into only using methods for concrete nodes, as we wish.

------

c.  Python describes how we can "import as" to change package names when appropriate.  This capability is in most Python books too.  Reference:

Python Language Reference, 7.11. The import statement
https://docs.python.org/3/reference/simple_stmts.html#the-import-statement

Also note that simple Python data types are supported by X3DJSAIL, so we don't have to wrap non-node values with SFString SFFloat etc.  I think this might let us change our file syntax as follows:

http://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorld.py

============================================================
import x3dpsail
X3D0 = (x3dpsail.X3D().setProfile(x3dpsail.SFString("Immersive")).setVersion(x3dpsail.SFString("3.3"))
       .setHead(x3dpsail.head() # etc.
============================================================

to

============================================================
import x3dpsail as x3d
X3D0 = (x3d.X3D().setProfile("Immersive").setVersion("3.3")
       .setHead(x3d.head() # etc.
============================================================

Nodes would need the "x3d." prefix so that they were package specific and not clobbered by user-defined name collisions.

2.  Looking ahead.

So far our strategy has been to implement X3D Python via pyjnius and X3DJSAIL, expecting to work on a C-based Cython implementation in the future when the C-based SAI open source is available.

Not a bad plan, but maybe we can make things much easier.  Loren, Jakub and I spent three hours tearing everything apart and putting it back together last week.  We came to the realization that we were working awfully hard and still having difficulties getting different languages aligned... when a much simpler approach was possible.

We might do far better by implementing an X3D package for python in python.  That would make X3D support independent of any other language bindings.

This would enable us to be far more "pythonic" and mainstream in all our constructs, rather than worrying about other programming-language implementation dependencies.  In other words, let Python be Python!

Looks like you might have already been hard at work on such an alternative:

https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/java/src/python/pythonapi/X3Dpackage.py

Next week, Loren and I will take a clean white board and attempt to design a type-aware X3D package that allows careful terse construction of correct X3D scene graphs.  We will simply apply X3D data model to best Python package practices.  No doubt Loren will banish "set" and "get" from our lexicon, and other java/javascript idioms will be avoided.  We'll then compare diffs with yours X3Dpackage.py, should be interesting.  Onward we go.

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