[x3d-public] continuing route issue with X3DJSAIL. I must be doing somethingwrong. Please provide example generated Java output which runs from this X3D.Request for JavaScript based XML -> X3DJSON help

yottzumm at gmail.com yottzumm at gmail.com
Tue Apr 18 21:40:35 PDT 2017


Here’s the file the best I could do. There’s an error in X3D-Edit I think.  Give me  a moment to get the shaders on my website.

John

Sent from Mail for Windows 10

From: Don Brutzman
Sent: Wednesday, April 19, 2017 12:25 AM
To: yottzumm at gmail.com
Cc: X3D Graphics public mailing list; Roy Walmsley; Job at alexkern.de
Subject: Re: continuing route issue with X3DJSAIL. I must be doing somethingwrong. Please provide example generated Java output which runs from this X3D.Request for JavaScript based XML -> X3DJSON help

John, the diagnostic is telling us what it doesn't like.  It can't reconcile set_cycleTime with cycleTime.

Am doing my best to produce both valid .x3d and corresponding .java so that we can, in each case,
- decide if an .x3d scene is in error;
- decide if X3DJSAIL API is in error, or inadequate;
- decide if the .java program is in error; or, rarely,
- decide if the specification is in error.

You don't have to debug stylesheet unless you want too.  Whatever works, I'll keep plugging away whenever possible.  Sorry but I have my hands full right now with the library and conversion stylesheet and example archives... if we can isolate bugs, and debug our respective tools accordingly, that is great.

The guiding spec prose here is

	4.4.2.2 Field semantics
	http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#Routes

I believe that if a field has accessType inputOutput, then a ROUTE can refer to it as zzz or set_zzz or zzz_changed as appropriate - see following spec prose.

If correct, since most fields are accessType inputOutput, then there are two allowed forms within most ROUTE fromName and toName values.

============================================================================
4.4.2.2 Field semantics

Fields define the persistent state of nodes, and values which nodes may send or receive in the form of events. X3D supports four types of access to a node's fields:

     initializeOnly access, which allows content to supply an initial value for the field but does not allow subsequent changes to its value;
     inputOnly access, which means that the node may receive an event to change the value of its field, but does not allow the field's value to be read;
     outputOnly access, which means that the node may send an event when its value changes, but does not allow the field's value to be written; and
     inputOutput access, which allows full access to the field: content may supply an initial value for the field, the node may receive an event to change the value of its field, and the node may send an event when its value changes.

An inputOutput field can receive events like an inputOnly field, can generate events like an outputOnly field, and can be stored in X3D files like an initializeOnly field. An inputOutput field named zzz can be referred to as 'set_zzz' and treated as an inputOnly, and can be referred to as 'zzz_changed' and treated as an outputOnly field. Within ISO/IEC 19775, fields with inputOutput access or inputOnly access are collectively referred to as input fields, fields with inputOutput access or outputOnly access are collectively referred to as output fields, and the events these fields receive and send are called input events and output events, respectively.

The initial value of an inputOutput field is its value in the X3D file, or the default value for the node in which it is contained, if a value is not specified. When an inputOutput field receives an event it shall generate an event with the same value and timestamp. The following sources, in precedence order, shall be used to determine the initial value of the inputOutput field:

     the user-defined value in the instantiation (if one is specified);
     the default value for that field as specified in the node or prototype definition.

The recommendations for naming initializeOnly fields, inputOutput fields, outputOnly fields, and inputOnly fields for built-in nodes are as follows:

     All names containing multiple words start with a lower case letter, and the first letter of all subsequent words is capitalized (e.g., addChildren), with the exception of set_ and _changed, as described below.
     It is recommended that all inputOnly fields have the prefix “set_”, with the exception of the addChildren and removeChildren fields.
     Certain inputOnly fields and outputOnly fields of type SFTime do not use the "set_" prefix or "_changed" suffix.
     It is recommended that all other outputOnly fields have the suffix “_changed” appended, with the exception of outputOnly fields of type SFBool.
================================================================================

Have been striving to make X3DJSAIL exceptions sufficiently explanatory to enable author debugging and correction.  Let's try that...

And so, looking at the exception you caught below, it appears that the ROUTEObject validation output should accept either either name prior to checking type.  That would be an X3DJSAIL effort.

Please let me know if that diagnosis seems correct.  I will look at the ROUTEObject code when time permits.

I should likely also add words to tooltips to describe this allowed variance.

	http://www.web3d.org/x3d/content/X3dTooltips.html#ROUTE

Hope this email makes sense.  Step by step...


On 4/18/2017 10:24 AM, yottzumm at gmail.com wrote:
> Java code and X3D attached.   Please provide generated Java code back which runs, so I can look at it and get my java serializer working.  I will soon download X3dToJava.xslt, and play with it.  I guess you want me to test it too? 😊 or instead? LOL!  Not everyone wants to run a stylesheet.  I’ve been doing it because I don’t have a good XML to X3D JSON converter yet ☹.  Let’s break the monopoly!  This was my start of one: https://github.com/coderextreme/X3DJSONLD/blob/master/Standard.js  Let’s just say generating X3DJSON is hard.  I was even able to generate JSON for the three-x3d-loader.  The code is found here: https://github.com/coderextreme/X3DJSONLD/blob/master/Three2Serializer.js  so you might base it on that.  IDK, working with X3DJSON as a source seems easy enough.
> 
> John
> 
> $ java bubbles
> 
> org.web3d.x3d.sai.InvalidFieldValueException:  ROUTE details: FROM TourTime.cycleTime (TimeSensor.SFTime.outputOnly) TO RandomTourTime.set_cycle (Script.ERROR_UNKNOWN_FIELD_TYPE.inputOnly)
> 
> ROUTE has source-destination type mismatch, fromField='cycleTime' source and toField='set_cycle' destination have different types.
> 
> org.web3d.x3d.sai.InvalidFieldValueException:  ROUTE details: FROM TourTime.cycleTime (TimeSensor.SFTime.outputOnly) TO RandomTourTime.set_cycle (Script.ERROR_UNKNOWN_FIELD_TYPE.inputOnly)
> 
> ROUTE has source-destination type mismatch, fromField='cycleTime' source and toField='set_cycle' destination have different types.
> 
>          at org.web3d.x3d.jsail.Core.ROUTEObject.validate(ROUTEObject.java:721)
> 
>          at org.web3d.x3d.jsail.Core.SceneObject.validate(SceneObject.java:547)
> 
>          at org.web3d.x3d.jsail.Core.X3DObject.validate(X3DObject.java:1831)
> 
>          at org.web3d.x3d.jsail.Core.X3DObject.toFileJSON(X3DObject.java:730)
> 
>          at bubbles.main(bubbles.java:79)
> 
> Exception in thread "main" org.web3d.x3d.sai.InvalidFieldValueException:  ROUTE details: FROM TourTime.cycleTime (TimeSensor.SFTime.outputOnly) TO RandomTourTime.set_cycle (Script.ERROR_UNKNOWN_FIELD_TYPE.inputOnly)
> 
> ROUTE has source-destination type mismatch, fromField='cycleTime' source and toField='set_cycle' destination have different types.
> 
>          at org.web3d.x3d.jsail.Core.ROUTEObject.validate(ROUTEObject.java:721)
> 
>          at org.web3d.x3d.jsail.Core.SceneObject.validate(SceneObject.java:547)
> 
>          at org.web3d.x3d.jsail.Core.X3DObject.validate(X3DObject.java:1831)
> 
>          at org.web3d.x3d.jsail.Core.X3DObject.toFileJSON(X3DObject.java:730)
> 
>          at bubbles.main(bubbles.java:79)
> 
> John
> 


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/20170419/49b7b6a4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bubbles.x3d
Type: application/octet-stream
Size: 7953 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170419/49b7b6a4/attachment-0001.obj>


More information about the x3d-public mailing list