[x3d-public] [...] HAnim2 X3D4 BoxMan update

[Joseph D Williams]

➢ Classic VRML does not allow to declare ROUTEs inside MFNode fields. Move them outside.

HI Patrick, 
Gee, I wish the tool would have told me that directly. Expecting DEF and finding ROUTE didn’t really lead me to the solution which to me now is specific to this tool. But really, what is special about Classic? This code was wrung from old VRML. 

Statement Object: 

ROUTE {
  X3DNode  [in,out] FromNode  [IDREF]
  X3DField [in,out] FromField [fieldName]
  X3DNode  [in,out] ToNode    [IDREF]
  X3DField [in,out] ToField   [fieldName]
}


There may be other x3d Statements and some rules, but I don’t see any spec language for what you describe regarding ROUTE. Really, not too much about built-in Statement Objects in the Abstract standard that I see yet. Also, first experience I see this requirement enforced. 

Of course I will expect that all routes everywhere in live scene graph must be assembled from everywhere every frame I had no idea there was a rule like this. Glad I’m not hearing that all routes have to be at the end.  

Same rule for XML? XML is easier because Route can be allowed anywhere comment can appear? Oops, if same rule, which it must be, No Route(s) in children, or, only as childs of scene?

If Route can not be child of children or embedded like a field in an SFNode or not between any SFNode(s)in an MFNode field does that mean Route always has to be at root (scene) level in the user code. I want to leave them wherever it serves me best, any competent browser should be able to find them. Or, is it because we don’t want them to cause a problem being included in add/removeChildren or some other technical reason? 

Again, since I have never encountered this before, to me it was/is a bug. I will check more with other tools, but as far as I can find not in spec. 

The SAI only needs the specific execution context, then add or delete route(s). Thus, I assume that regardless where the statement is located in the scene, it is regarded as part of the root scene or a specific child scene. 
So, my main idea is to collect the timer(s), interpolator(s), and route(s) into  
Group {children[actions routes]} 
but view3dscene would only let me do 
Group {children[actions]} routes  

As usual, when a browser rule appears we look at the spec for abstract and sai to figure it out. Please help either find this rule in the spec, make the use case and comparison with other tools and add the rule to the spec, or remove that demand from your tool. I am now getting the latest view3dscene downloaded.

I think Thanks for finding what might be a gap in the spec.
Joe



From: Patrick Dähne
Sent: Wednesday, January 4, 2023 12:17 PM
To: X3D Public Mailing List (x3d-public at web3d.org)
Subject: Re: [x3d-public] [...] HAnim2 X3D4 BoxMan update


> Am 04.01.2023 um 20:32 schrieb Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>:
> 
> 	• The online BoxMan4 is flawed because converters were unable to import your hand-edited .x3dv version properly.  During our last call, it sounded like you isolated the problem, occurring due to ROUTE children within a Group not getting handled.  If able to diagnose and fix VRML/ClassicVRML import problems, that is worthwhile.

Classic VRML does not allow to declare ROUTEs inside MFNode fields. Move them outside.


_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230104/59114356/attachment.html>