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

[Michalis Kamburelis]

Changing the avatarSize from MFFloat to SFVec3f *is* a
content-breaking change too.

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.

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.

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.

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 }
}

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
> >>
> >> _______________________________________________
> >> x3d-public mailing list
> >> x3d-public at web3d.org
> >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> 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