[x3d-public] X3DGroupingNode interface has no method setIS in X3DJSAIL, FYI
John Carlson
yottzumm at gmail.com
Mon Jan 14 12:32:28 PST 2019
I there any desire to add methods on the fly in Java, instead of having them in a declared API? See Java Proxy class.
John
Sent from Mail for Windows 10
From: Brutzman, Donald (Don) (CIV)
Sent: Monday, January 14, 2019 10:33 AM
To: John Carlson; aono at tut.jp
Cc: X3D Graphics public mailing list
Subject: Re: X3DGroupingNode interface has no method setIS in X3DJSAIL, FYI
Continuing the analysis below...
I looked at whether get/set methods for DEF USE CssClass and IS might be handled more consistently - they already are, specified as abstract methods in X3DConcreteNode which then get specifically implemented in each concrete node class.
[11] http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/X3DConcreteNode.html#method.summary
Then looked further and experimented, taking things apart and putting them together again, to see if any better design pattern is possible.
The fundamental difficulty is that X3D SAI interfaces do not have any programmatic recognition of X3D statements: ROUTE Proto* IMPORT/EXPORT IS/connect X3D head meta Scene or comments.
[12] http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/sai/Core/X3DNode.html
namely
public interface X3DNode
with no interfaces for statements anywhere. This matches the specification X3D SAI 19775-2 and X3D SAI for Java 19776-2.
The x3djsail package does recognize X3D statements and comments programmatically, with a class hierarchy of
[13] http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/X3DConcreteElement.html
namely
java.lang.Object
+- org.web3d.x3d.jsail.X3DConcreteElement
+- org.web3d.x3d.jsail.X3DConcreteNode
+- org.web3d.x3d.jsail.Core.CommentsBlock
+- org.web3d.x3d.jsail.X3DConcreteStatement
In order to allow addition of X3D statements as valid children (of a Group, for example) they must be in the hierarchy somewhere. Specialty methods for single-child IS or Inline containing IMPORT/EXPORT pose no problem, but we want Proto* and ROUTE and comments etc. to remain in order within MFNode children[] arrays, since such order matters a lot.
So, following a bunch more experimentation that couldn't refactor or coalesce the object hierarchy any better, I now feel pretty sure that any further simplification of the object hierarchy (with respect to X3D statements) is only possible if we refactor the X3D SAI for Java to include statements. This might emerge someday, but I don't recommend such major work at this stage. We should first finalize X3D JSON and demonstrate X3D Python/C++/C# before such work. Experience with what works across multiple object-oriented languages needs to finish (or at least stabilize) before we consider further adjusting the SAI architecture. For broad interoperability, often what you leave out is just as important as what you put in.
*Therefore* it looks like you continue to have the same stable playing field in X3DJSAIL with which to map X3D Python using Pyjnius.
I'm confident that we can make Java/JSON/JavaScript/Python all work together nicely, building on numerous achievements already. Certainly does take time, but we are unwrapping these challenges steadily. Am still working and slowly catching up with you on Python and Pyjnius!
BTW it is interesting to consider that X3D SAI had no need of X3D statements because it was designed for use with Script nodes. We are making it a full-fledged scene graph. This seems reminiscent of the challenges that node.js faced when elevating JavaScript out of the HTML browser sandbox into standalone application/server operation.
I think this is pretty healthy for our X3D v4 development too. As an oh-by-the-way (OBTW) noticed that X_ITE has excellent support for the Browser class, we definitely need to make review of Browser interfaces part of X3Dv4 design. Not finding corresponding support for Browser object in X3DOM.
[14] X_ITE Accessing the External Browser
http://create3000.de/x_ite/accessing-the-external-browser
[15] X3DOM Documentation https://doc.x3dom.org
Thanks for all review John + everyone. Onward we go.
(deep breath) Having fun with development of X3D Java, JSON, JavaScript and Python! 8)
On 1/5/2019 6:29 PM, Brutzman, Donald (Don) (CIV) wrote:
> On 1/4/2019 10:49 PM, John Carlson wrote:
>> Thank you all for considering this code. Note that one works, and here is the failure for the other. It appears when you use concrete classes and not interfaces, it works. The interface does not have the method. We will have to figure out some kind of casting scheme, I think.
>>
>> John
>
> [Summary: interesting python examples, progress possible, analysis follows.]
>
> Original scene and alternatives at available at
>
> [1] http://www.web3d.org/x3d/content/examples/Basic/ChemicalMarkupLanguage/GlycerolDiacetate.x3d
>
> [2] http://www.web3d.org/x3d/content/examples/Basic/ChemicalMarkupLanguage/GlycerolDiacetateIndex.html
>
> [3] http://www.web3d.org/x3d/content/examples/Basic/javadoc/Basic/ChemicalMarkupLanguage/GlycerolDiacetate.html
>
> [4] http://www.web3d.org/x3d/content/examples/Basic/ChemicalMarkupLanguage/GlycerolDiacetate.java
>
> [5] http://www.web3d.org/x3d/tooltips/X3dTooltips.html#IS
>
> [6] http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/Core/ISObject.html
>
> [7] http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/Core/connectObject.html
>
> IS appears within a ProtoDeclare, saying that a node's field IS provided by an ancestor ProtoDeclare field declaration.
>
> ======================================================================
> XML scene excerpt matching your example below:
>
> <ProtoDeclare name='Hydrogen'>
> <ProtoInterface>
> <field accessType='inputOutput' name='position' type='SFVec3f' value='0 0 0'/>
> <field accessType='inputOutput' name='Mat' type='SFFloat' value='.6'/>
> </ProtoInterface>
> <ProtoBody>
> <Group>
> <Transform DEF='atoH'>
> <IS>
> <connect nodeField='translation' protoField='position'/>
> </IS>
> <Shape>
> <Appearance>
> <Material DEF='atoH_mat' ambientIntensity='.0933' diffuseColor='.38 .38 .42' shininess='0.5' specularColor='.53 .53 .53'>
> <IS>
> <connect nodeField='transparency' protoField='Mat'/>
> </IS>
> </Material>
> </Appearance>
> <Sphere radius='.32'/>
> </Shape>
> <Shape>
> <Appearance>
> <Material diffuseColor='0.9 0.9 0.9'/>
> </Appearance>
> <Text string='"H"'>
> <FontStyle size='.4'/>
> </Text>
> </Shape>
> </Transform>
> </Group>
> </ProtoBody>
> </ProtoDeclare>
> ======================================================================
> Java scene excerpt matching your example below:
>
> .addChild(new ProtoDeclareObject("Hydrogen").setName("Hydrogen")
> .setProtoInterface(new ProtoInterfaceObject()
> .addField(new fieldObject().setName("position").setType(fieldObject.TYPE_SFVEC3F).setAccessType(fieldObject.ACCESSTYPE_INPUTOUTPUT).setValue(new SFVec3fObject(0.0f,0.0f,0.0f)))
> .addField(new fieldObject().setName("Mat").setType(fieldObject.TYPE_SFFLOAT).setAccessType(fieldObject.ACCESSTYPE_INPUTOUTPUT).setValue(.6f)))
> .setProtoBody(new ProtoBodyObject()
> .addChild(new GroupObject()
> .addChild(new TransformObject("atoH")
> .setIS(new ISObject()
> .addConnect(new connectObject().setNodeField("translation").setProtoField("position")))
> .addChild(new ShapeObject()
> .setAppearance(new AppearanceObject()
> .setMaterial(new MaterialObject("atoH_mat").setAmbientIntensity(.0933f).setDiffuseColor(.38f,.38f,.42f).setShininess(0.5f).setSpecularColor(.53f,.53f,.53f)
> .setIS(new ISObject()
> .addConnect(new connectObject().setNodeField("transparency").setProtoField("Mat")))))
> .setGeometry(new SphereObject().setRadius(.32f)))
> .addChild(new ShapeObject()
> .setAppearance(new AppearanceObject()
> .setMaterial(new MaterialObject().setDiffuseColor(0.9f,0.9f,0.9f)))
> .setGeometry(new TextObject().setString(new MFStringObject("\"H\""))
> .setFontStyle(new FontStyleObject().setSize(.4f))))))))
> ======================================================================
>
> As you point out, IS gets defined by X3DJSAIL on a per-node basis. That is because each node might include a single IS statement (which in turn contains zero or more "connect" statements).
> - For example, TransformObject setIS()
> http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/Grouping/TransformObject.html#setIS-org.web3d.x3d.jsail.Core.ISObject-
> - For example, MaterialObject setIS()
> http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/Shape/MaterialObject.html#setIS-org.web3d.x3d.jsail.Core.ISObject-
>
> First reaction: looks like we might possibly migrate the setIS() getIS() methods upwards to org.web3d.x3d.sai.Core.X3DNode class. That way it would appear wherever set/get DEF and USE and CssClass accessor methods appear. However this is a spec-defined abstract X3D SAI class, not an X3DJSAIL class...
>
> [8] http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/sai/Core/X3DNode.html
>
> [9] http://www.web3d.org/documents/specifications/19777-2/V3.3/Part2/abstracts.html#X3DNode
>
> Of direct interest is that the DEF/USE/class methods are not defined there in that abstract SAI class... and can likely be moved to an X3DJSAIL instead.
>
> Aha, am remembering that DEF/USE access was originally controversial in all of the all of the language bindings (is it a string field? is it pointer? is it an object reference? is it programming-language specific? is it implementation specific?) and was left out of abstract SAI. Indeed checking back in abstract SAI specification, am not finding any general requirement to set/get DEF or USE values. This seems like a hole in the abstract SAI, frankly. Specification itself:
>
> [10] X3D Scene access interface (SAI)
> http://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/X3D_SAI.html
>
> hmmm another TODO: statements such as IMPORTObject ROUTEObject ExternProtoDeclareObject ProtoDeclareObject etc. should not be in list of implementing classes there... looks like a twist in the X3DJSAIL class hierarchy, these get @Deprecated where they implemented (since you cannot DEF or USE a ROUTE statement, for example).
>
> So, moving the DEF/USE/CssClass methods out of org.web3d.x3d.sai.Core.X3DNode does not violate abstract SAI, or Java SAI. Good, that gives us an opening for improvement here. Probably these methods should all go to org.web3d.x3d.jsail.X3DConcreteNode interface instead... hey wait a minute, there are some abstract methods already there for DEF/USE.
>
> [10] http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/X3DConcreteNode.html
>
> I will work on refactoring the x3djsail/sai class hierarchy accessor get/set methods for DEF USE CssClass and IS more consistently. The .x3d and .java scene source patterns above won't change, this is all internal.
>
> Tricky business indeed, please stand by for refactoring of X3DJSAIL class/interface hierarchy.
>
> So don't worry about casting at this stage. Thanks for triggering this analysis.
>
> p.s. looks like you have method pipelining going in the second version! 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190114/93e571ad/attachment-0001.html>
More information about the x3d-public
mailing list