[x3d-public] 0001239: NavigationInfo avatarSize type should be SFVec3f rather than MFFloat - Web3D MantisBT

[Don Brutzman]

On 12/16/2020 2:23 AM, Michalis Kamburelis wrote:
> 
> Changing the avatarSize from MFFloat to SFVec3f *is* a
> content-breaking change too.

Please advise what you mean.  No change for XML content, or binary, or Java or python, or validation rules.

Perhaps the brackets change in ClassicVRML and JSON?  Aha yes, your example below.

> For this reason, I would say to either 1. do not change it at all
> (leave as MFFloat), 2. or change it into 3 independent SFFloat fields.

Agreed that doing nothing to improve this particular problem is an acceptable option.  We have lived with it for many years.

> I'm fine with 1 (no change), I'm fine with 2 (change to 3x SFFloat).
> 
> Doing it "half-way" (changing to SFVec3f) isn't really useful in my
> eyes -- we break compatibility, and do not get all the possible
> benefits.

Don't forget the benefit of validation, content with avatarSize [ 1 2 ] or avatarSize [ 1 2 3 4 ] is typically undetectable except at run time or X3D Schematron / X3D-Tidy.

> How is changing MFFloat->SFVec3f breaking?
> 
> 1. E.g.
> 
> NavigationInfo {
>    avatarSize [ 1 2 3 ]
> }
> 
> (in classic encoding) will no longer work (fail at parsing) if you
> chane avatarSize to SFVec3f.
> 
> 2. Also if someone used avatarSize with more items than 3 (to provide
> some browser-specific settings) then it breaks.

well, that is actually good to detect since it is incorrect content

> 3. Also if someone wrapped NavigationInfo in a PROTO, like this, then it breaks:
> 
> PROTO MyNavigation [
>    inputOutput MFFloat myAvatarSize 1 2 3
> ] {
>    NavigationInfo { avatarSize IS myAvatarSize }
> }

Another good point.

Have updated mantis issue 1239 as:

"Multiple tradeoffs are confirmed as unavoidable regardless of approach in this possible change.  No changes accepted for current round of X3D4."

Have also added warning to X3D Tooltips for NavigationInfo avatarSize:

* "Warning: data type is MFFloat rather than SFVec3f, be sure that three values are provided in the array since validation tools are typically unable to detect erroneous data prior to run time. "
   https://www.web3d.org/x3d/tooltips/X3dTooltips.html#NavigationInfo.avatarSize

OK, back to review of draft specification - and member voting!

> Regards,
> Michalis
> 
> śr., 16 gru 2020 o 10:56 Don Brutzman <brutzman at nps.edu> napisał(a):
>>
>> Thanks.  Everything is now locked for a member vote, but we are allowed to issue comments against it via mantis.
>>
>> It would be good to have feedback from other browser implementers regarding the perceived complexity of this improvement.
>>
>> We would also have to consider compatibility of content in prior versions of VRML and X3D.  This didn't quite rise above threshold of acceptance last time we considered it.
>>
>> Addition of near/far clipping plane and a contained navigationInfo field altogether in X3DViewpoint node reduces a lot of pressure for further splitting.
>>
>> Recommended choices to consider:
>> a. SFVec3F avatarSize for correct typing (minimalist, no affect on content)
>> b. splitting subfields as modifiable parameters (more animatable, perhaps no longer needed)
>>
>> On 12/16/2020 12:45 AM, Michalis Kamburelis wrote:
>>>
>>> As far as I recall, we actually wondered about changing it to 3
>>> independent SFFloat fields. This would make the intention and
>>> modification obvious.
>>>
>>> So a change like
>>>
>>>       MFFloat [in,out] avatarSize [0.25 1.6 0.75] [0,?)
>>>
>>> ->
>>>
>>>       SFFloat [in,out] avatarCollisionRadius 0.25 # [0,?)
>>>       SFFloat [in,out] avatarHeight               1.6   # [0,?)
>>>       SFFloat [in,out] avatarClimbAllowed    0.75 # [0,?)
>>>
>>> The fact that these 3 values are now "packed' in a one field is
>>> probably more confusing than helpful. Also, the above change could be
>>> implemented in browsers in a backward-compatible manner (i.e. browsers
>>> may decide to still support "MFFloat avatarSize" and internally
>>> convert it to 3 new independent fields, when encountered.)
>>>
>>> Regards,
>>> Michalis
>>>
>>> śr., 16 gru 2020 o 08:32 Don Brutzman <brutzman at nps.edu> napisał(a):
>>>>
>>>> During Mantis review rediscovered this overlooked issue, which I had thought was already taken care of.  Schema and X3DUOM remain MFFloat rather than SFVec3f.
>>>>
>>>> Recommend we change.  Any objections or observations out there?
>>>>
>>>> =========================================================
>>>> https://www.web3d.org/member-only/mantis/view.php?id=1239
>>>>
>>>> Summary 0001239: NavigationInfo avatarSize type should be SFVec3f rather than MFFloat
>>>>
>>>> Description     23.4.4 NavigationInfo avatarSize always contains 3 values. Thus type should be SFVec3f rather than MFFloat for proper assignment.
>>>>
>>>> Additional Information  Posted by John Carlson 13 May 2018
>>>> http://web3d.org/pipermail/x3d-public_web3d.org/2018-May/008743.html
>>>>
>>>> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/navigation.html
>>>> 23.4.4 NavigationInfo
>>>>
>>>> NavigationInfo : X3DBindableNode {
>>>>      MFFloat [in,out] avatarSize [0.25 1.6 0.75] [0,?)
>>>>
>>>> Should this be SFVec3f instead of MFFloat? Strict typing is always preferred since it detects errors.
>>>> =========================================================


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