[x3d-public] updates to X3DJSAIL, plus python andjavaversionsofX3DExamples,X3DPSAIL; let Python be Python
John Carlson
yottzumm at gmail.com
Thu Jun 27 08:54:29 PDT 2019
Also,
Should we have a similar discussion about fieldTypes.js and abstract items?
Thanks,
John
Sent from Mail for Windows 10
From: Brutzman, Donald (Don) (CIV)
Sent: Wednesday, June 26, 2019 8:16 PM
To: John Carlson
Cc: X3D Graphics public mailing list; Peitso, Loren (CIV)
Subject: Re: updates to X3DJSAIL, plus python andjavaversionsofX3DExamples,X3DPSAIL; let Python be Python
On 6/26/2019 7:13 AM, John Carlson wrote:
> The problem with this is that I am often given a node in XML and I don’t know what field to assign it to in Python. For example, if I get a X3DChildNode as a child of Collision in XML, I don’t know if I should use setProxy or addChildren. My best guess is addChildren, except when the proxy containerField is set.
That is correct and not a guess, because "children" is the default containerField value of any node that might be used for that field.
So yes, an XML element goes in the proxy field of a Collision node only if containerField="proxy"
X3D Example Archives: Basic, development, Proxy Shape Example
https://www.web3d.org/x3d/content/examples/Basic/development/ProxyShapeExampleIndex.html
If that sounds complex, it is not. The value of containerField is simply a way to label the typical field a child X3D node goes into, making XML encoding much terser.
See the following to determine containerField defaults, if you are ever unsure.
X3D Scene Authoring Hints: containerField
https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerField
"The X3D XML Schema, X3D DTD and X3D Tooltips each define all default containerField values, which are optional and typically can be omitted for scene terseness."
http://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0.html
http://www.web3d.org/specifications/X3dDoctypeDocumentation4.0.html
https://www.web3d.org/x3d/content/X3dTooltips.html
https://www.web3d.org/x3d/content/X3dTooltips.html#Shape.containerField
Note that X3DUOM provides even greater information, extracted from X3D XML Schema, showing what alternatives are allowed. For example:
http://www.web3d.org/specifications/X3dUnifiedObjectModel-4.0.xml
<SimpleType name="containerFieldChoicesGroupLODShapeTransform"
baseType="xs:NMTOKEN"
appinfo="containerFieldChoicesGroupLODShapeTransform lists the allowed containerField enumeration values for Shape, Transform and LOD nodes: "children" if parent node has abstract type X3DGroupingNode, otherwise "metadata" default."
documentation="http://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerField">
<enumeration value="children"
appinfo="parent node has abstract type X3DGroupingNode"/>
<enumeration value="proxy" appinfo="parent node is Collision"/>
<enumeration value="rootNode" appinfo="parent node is GeoLOD"/>
<enumeration value="shape" appinfo="parent node is CADFace or CollidableShape"/>
<enumeration value="skin" appinfo="parent node is HAnimHumanoid"/>
</SimpleType>
These variations are also documented, here is link and an excerpt:
X3D Scene Authoring Hints 🔖 Variations from containerField defaults
https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerFieldVariations
"Collision can contain a single nonrendered proxy Shape (or X3DGroupingNode) node with containerField='proxy' (rather than default containerField='children'). See containerFieldChoicesGroupLODShapeTransform."
and
X3D Scene Authoring Hints 🔖 Validation choices for containerField
https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerFieldChoices
d. containerFieldChoicesGroupLODShapeTransform for Group, LOD, Shape, Transform.
http://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_containerFieldChoicesGroupLODShapeTransform.html
> It is likely I can get a lot of info re: containerField simple types in X3DUOM. I usually don’t use X3DUOM when translating from XML to Python, so this is a fresh step!
Hope you like it. Please holler if you find anything missing, variations are important to document.
Please note that we have come all the way up to an important refinement for X3Dv4. The containerField variations sometimes reveal that we have been inconsistent in naming conventions of field names in X3D architecture itself. Please see next section as well, which lists 10 recommended improvements for consistency within X3D.
X3D Scene Authoring Hints 🔖 Potential future changes for improving containerField
https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerFieldChoices
* Collision: content model definitions for contained nodes are insufficiently strict. See issue Mantis 1149.
http://www.web3d.org/member-only/mantis/view.php?id=1149
Current work with X3D Semantic Web ontology is underscoring this need for best-possible consistency throughout X3D. Field names must be consistent if we want to pose meaningful queries about parent-child node relationships. For example, in pseudo-SPARQL, "what are children of GeoLOD node" won't work because those nodes are unnecessarily named differently as /rootNode/.
Isn't interesting how interlocking the X3D data model is within so many issues.
Web3D Membership has value: also there is bottom line,
"These changes will be considered by Web3D Consortium members with subsequent review by the X3D Community. Companies, institutions, agencies and individuals are invited to Join Web3D Consortium to participate and influence this important continuing evolution of X3D."
> If I am parsing XML scenegraph, should I use X3DUOM or RDF at this point for information on fields, types etc.?
Absolutely prefer the preceding references rather than RDF. The ontology is derivative from X3DUOM (and thus X3D XML Schema), also it is experimental.
> *I’m going to rename packagemaker.py to packageGenerator.py.* The generators are currently access the X3DUOM, not the serializers directly. This will make the files easier to understand.
Very good, clarity always helps. We will take an independent swoop at Python and meet you at downstream merging fork in the road.
> Thanks,
>
> John
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>
> *From: *John Carlson <mailto:yottzumm at gmail.com>
> *Sent: *Wednesday, June 26, 2019 8:28 AM
> *To: *Brutzman, Donald (Don) (CIV) <mailto:brutzman at nps.edu>
> *Cc: *X3D Graphics public mailing list <mailto:x3d-public at web3d.org>; Peitso, Loren (CIV) <mailto:lepeitso at nps.edu>
> *Subject: *RE: updates to X3DJSAIL, plus python and javaversionsofX3DExamples,X3DPSAIL; let Python be Python
>
> Warped mapToMethod2.js Will check in.
>
> $ grep Collision data/X3dHeaderPrototypeSyntaxExamples.* data/CoordinateAxes.assign.py
>
> data/X3dHeaderPrototypeSyntaxExamples.assign.py:Collision54 = Collision()
>
> data/X3dHeaderPrototypeSyntaxExamples.assign.py:# note that Collision proxy Shape is not rendered
>
> data/X3dHeaderPrototypeSyntaxExamples.assign.py:Collision54.proxy = Shape55
>
> data/X3dHeaderPrototypeSyntaxExamples.assign.py:Collision54.addChildren([Group59])
>
> data/X3dHeaderPrototypeSyntaxExamples.assign.py:Scene17.addChildren([Collision54])
>
> data/X3dHeaderPrototypeSyntaxExamples.kwargs.py: Collision54 = Collision( Shape55 = Shape( # note that Collision proxy Shape is not rendered
>
> data/X3dHeaderPrototypeSyntaxExamples.pipe.py: .addChildren([Collision() .setProxy(Shape()# note that Collision proxy Shape is not rendered
>
> data/X3dHeaderPrototypeSyntaxExamples.serial.py:Collision54 = Collision()
>
> data/X3dHeaderPrototypeSyntaxExamples.serial.py:Shape55 = Shape(proxy = Collision54)
>
> data/X3dHeaderPrototypeSyntaxExamples.serial.py:# note that Collision proxy Shape is not rendered
>
> data/X3dHeaderPrototypeSyntaxExamples.serial.py:Collision54.setProxy(Shape55)
>
> data/X3dHeaderPrototypeSyntaxExamples.serial.py:Collision54.addChildren(Group59)
>
> data/X3dHeaderPrototypeSyntaxExamples.serial.py:Scene17.addChildren(Collision54)
>
> data/X3dHeaderPrototypeSyntaxExamples.x3d: <Collision>
>
> data/X3dHeaderPrototypeSyntaxExamples.x3d: <!-- note that Collision proxy Shape is not rendered -->
>
> data/X3dHeaderPrototypeSyntaxExamples.x3d: </Collision>
>
> data/CoordinateAxes.assign.py:Collision8 = Collision()
>
> data/CoordinateAxes.assign.py:Collision8.DEF = "DoNotCollideWithVisualizationWidget"
>
> data/CoordinateAxes.assign.py:Collision8.enabled = True
>
> data/CoordinateAxes.assign.py:Collision8.addChildren([Group9])
>
> data/CoordinateAxes.assign.py:Collision8.addChildren([Transform26])
>
> data/CoordinateAxes.assign.py:Collision8.addChildren([Transform43])
>
> data/CoordinateAxes.assign.py:Scene7.addChildren([Collision8])Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>
> *From: *John Carlson <mailto:yottzumm at gmail.com>
> *Sent: *Wednesday, June 26, 2019 7:53 AM
> *To: *Brutzman, Donald (Don) (CIV) <mailto:brutzman at nps.edu>
> *Cc: *X3D Graphics public mailing list <mailto:x3d-public at web3d.org>; Peitso, Loren (CIV) <mailto:lepeitso at nps.edu>
> *Subject: *RE: updates to X3DJSAIL, plus python and java versionsofX3DExamples,X3DPSAIL; let Python be Python
>
> I’m now having problems with “set Proxy” called twice in generated python scenegraph. Checked in:
>
> data/X3dHeaderPrototypeSyntaxExamples.assign.py:Collision54 = Collision()
>
> data/X3dHeaderPrototypeSyntaxExamples.assign.py:Collision54.proxy = Shape55
>
> data/X3dHeaderPrototypeSyntaxExamples.assign.py:Collision54.proxy = Group59
>
> data/X3dHeaderPrototypeSyntaxExamples.assign.py:Scene17.addChildren([Collision54])
>
> data/X3dHeaderPrototypeSyntaxExamples.kwargs.py: Collision54 = Collision( Shape55 = Shape( # note that Collision proxy Shape is not rendered
>
> data/X3dHeaderPrototypeSyntaxExamples.serial.py:Collision54 = Collision()
>
> data/X3dHeaderPrototypeSyntaxExamples.serial.py:Shape55 = Shape(proxy = Collision54)
>
> data/X3dHeaderPrototypeSyntaxExamples.serial.py:Collision54.setProxy(Shape55)
>
> data/X3dHeaderPrototypeSyntaxExamples.serial.py:Collision54.setProxy(Group59)
>
> data/X3dHeaderPrototypeSyntaxExamples.serial.py:Scene17.addChildren(Collision54)
all of our models validate and roundtrip effectively in XML Java JSON (Classic)VRML so any problems are unlikely to be in the source model. the key is to get HelloWorld.py always round-tripping, we currently have that working 190% of the time for two pythong alternatives to date.
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>
> *From: *John Carlson <mailto:yottzumm at gmail.com>
> *Sent: *Wednesday, June 26, 2019 7:39 AM
> *To: *Brutzman, Donald (Don) (CIV) <mailto:brutzman at nps.edu>
> *Cc: *X3D Graphics public mailing list <mailto:x3d-public at web3d.org>; Peitso, Loren (CIV) <mailto:lepeitso at nps.edu>
> *Subject: *RE: updates to X3DJSAIL, plus python and java versions ofX3DExamples,X3DPSAIL; let Python be Python
>
> Don, read this.
>
> My response:
>
> 1 a) mapToMethod.js is overridden by mapToMethod2.js. You need to study JavaScript objects, and how values are written over by keys and values appearing later in a file. Two equal keys ends up as a single key, and the last value that appears in order in the file takes.
>
> I know this isn’t ideal, which is why I created mapToMethod2.js for a fallback.
>
> For example, print out this object:
>
> { " a": 1, " a" : 2 }
>
> As far as I know, the mapToMethod*.js files only affect the Serializers.
>
> The best way to think of JavaScript Objects is as arrays with a non whole number indexes and interned keys (a la Java) I think. Now you **will** understand that there are no double entries left once the whole file is read in the JavaScript? You can also combine an array with an object in JavaScript, last I’ve heard (probably not a good idea).
>
> We can easily remove the abstract classes by modifying what gets sent to the ClassPrinter in packagemaker.py and avoiding going up the hierarchy into interfaces and abstract classes. (Search for Abstract to begin)
>
> I don’t have a good methods for fixing this yet, and I have tried different things in mapToMethod.py, like not traversing to parents or children, but haven’t found a good solution.
Two issues for me.
a. Sorry but mapToMethod.js and mapToMethod2.js are so far different that they appear complementary.
b. You have greater confidence than me that pyjnius is as scrupulous as you think. We know that pyjnius is mistakenly returning abstract types, we know that abstract types are not correct return types for any external/pipelined call, we know that pyjnius uses Java reflection which contains multiple confusable layers of redirection. I am saying that we should restrict our python-to-X3DJSAIL mappings to solely include concrete classes, no abstracts. Results at that point will hopefully be much better and less obscure, making any remaining bugs fixable.
If mapToMethod has no influence on pyjnius invocations, then redirect our focus towards what else needs to get fixed for pyjnius.
> b) We can remove abstract classes, unless there some implementation in the abstract class we need to access??? I didn’t know whether I should follow the parent chain up the inheritance hierarchy or not? Are there concrete classes which inherit from concrete classes?
yes, no, no, no
yes, remove abstract classes.
no, X3DJSAIL handles internals and only concretes should be sought by pyjnius.
no, don't follow parent chain. let X3DJSAIL do its own work, no need to interfere.
no, not applicable, the concrete classes map to X3D nodes and the abstract classes map to X3D abstract node types.
You never have an X3DNode abstract node type in an X3D model saved as a file. *Stay concrete* please.
> Show me an example of a Python file where the translation from XML was wrong, and we can work on an example. I don’t want to work without an example at this point, unless you want me to get rid of the interfaces and abstract classes. Since we’re converting to Python from X3D scenegraphs, there won’t be interfaces or abstract classes in the generated Python, because they aren’t in X3D XML scenegraphs. If we’re talking methods that are abstract, that’s a different story. Those shouldn’t appear in mapToMethod.js, so the methods won’t be used in the generated scenegraph in Python. The key is to find out what method should be used, and put that in mapToMethod2.js in the short term. Ideally, we’d have a single
> file with correct entries.
HelloWorld.x3d -> HelloWorld.py remains our canonical example. We haven't nailed that one yet. First things first please.
> c) I’m waiting for you to show me something that has fewer errors than using the wrappers, like use a different serializer.
Imagine every python programmer using a wrapper every time they use any node or any field... ouch.ouch.ouch.ouch. Way too clumsy.
Loren has explained why we will likely need to use package naming for every node, to avoid possibility that python model authors are inadvertently overloading/clobbering the X3D classes. So we will likely have x3d.X3D, x3d.Shape, x3d.Transform etc. Then simple-type changes occur on that class so no further prefixing necessary. Further work and explanatory documentation to follow.
> 2) Welcome aboard. We can leave the pyjnius version available to Java programmers who want to use a “Java-like” syntax for ease of porting, but we should get to X3DJSAIL production of Python scenegraphs soon. I suggest using PythonSerializer.js output, if it’s in good shape for the “set API” so we don’t get a bunch of errors. Let’s toss Pipelining/Chaining altogether, then the user can make a choice as to what they want to program, instead of us ruling what they have to do. They are better to decide how to work around the error, but we can make suggestions, like don’t use Pipelining.
We seek the tersest most concise pythonic form possible. Once there, re-examination of alternatives to date may be helpful to compare.
> That said, there are 3 left over styles we can use instead of the pipelining. Examples of different styles can be found in the data folder under pythonapi on sourceforge. I suggest using the PythonAssignSerializer.js. But we may need to do something for initializeOnly, in which case, I recommend the Kwargs serializer.
>
> 3) A word:
>
> https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/java/src/python/pythonapi/packagemaker.py
>
> created the X3DPackage.py file, so probably the packagemaker.py file would be a good launching point. No need to make your changes to X3DPackage.py file if they’re going to be overwritten in the next build.
>
> I am thinking we need a RDF to X3DPackage.py converter? Is that the mad science Loren was talking about?
>
> Here’s where I gave up on the pythonapi. I was able to generate classes from X3DUOM, but I was unable to generate XML from the generated classes. Perhaps that’s the best place to start on the new effort.
Getting the python syntax is the key. We have written many serializers to output various forms of X3D, that will be easy. Don't push cart before the horse.
> I think the best thing we can do is work with RDF to generate the appropriate classes that generate XML during run-time.
No. Steer clear of RDF please. The ontology is derivative (no new information there) and going in different directions.
> But we will need to generate documentation for these “shadow” classes that don’t appear in any source code. Perhaps Loren has a solution? Hmm! My brain is foggy. I will get a frappe and take a nap.
OK now that's alarming, frappe before nap! :0
> John
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>
> *From: *Brutzman, Donald (Don) (CIV) <mailto:brutzman at nps.edu>
> *Sent: *Tuesday, June 25, 2019 9:39 PM
> *To: *John Carlson <mailto:yottzumm at gmail.com>
> *Cc: *X3D Graphics public mailing list <mailto:x3d-public at web3d.org>; Peitso, Loren (CIV) <mailto:lepeitso at nps.edu>
> *Subject: *Re: updates to X3DJSAIL, plus python and java versions ofX3DExamples, X3DPSAIL; let Python be Python
>
> 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
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190627/0e9acd1f/attachment-0001.html>
More information about the x3d-public
mailing list