[x3d-public] X3D Agenda 19 June 2020: Mantis issues

[Michalis Kamburelis]

Don Brutzman <brutzman at nps.edu> wrote:

> Thanks Michalis, very helpful.  Have added this to Mantis 1310.
>
> * Mantis 1310: near, far clipping planes indirectly specified by
> NavigationInfo, consider addition to X3DViewpointNode
>    https://www.web3d.org/member-only/mantis/view.php?id=1310
>
> So far so good, however: practice has shown an important use case that is
> difficult to handle: shifting between local views and faraway (e.g.
> terrain-oriented) views.
>
> ... so we might consider the ability to override these values in a
> Viewpoint, since they are typically needed when shifting between such views.
>
> Suggested specification addition:
>
> 23.3.1 X3DViewpointNode
>
> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/navigation.html#X3DViewpointNode
>
> Viewpoint : X3DViewpointNode {
>   SFFloat    [in,out] nearClippingPlane -1     -1 or [0,infinity)
>   SFFloat    [in,out]  farClippingPlane -1     -1 or [0,infinity)
> }
>
> "If specified and non-negative, the values specified for nearClippingPlane
> and farClippingPlane define the near and far clipping plane distances when
> the X3DViewpointNode is bound.  Otherwise these values are defined by the
> bound NavigationInfo node, including when the X3DViewpointNode is unbound."
>
> Hopefully this strikes a good balance... X3D3 defaults are maintained, and
> X3D4 authors have more straightforward options.
>
>
Sure, I can see the use-case.

However, 2 notes:

1. Clarify what happens when one value is -1, the other is not. E.g.
nearClippingPlane is 10, farClippingPlane is -1.

    The intention is (I guess) that X3DViewpointNode then determines
nearClippingPlane, but NavigationInfo still determines the far clipping
plane (if NavigationInfo.visibilityLimit is non-zero, otherwise browser
calculates it). So maybe add a prose that says it, like this:

    """It is allowed that only one of these values is non-negative (e.g.
nearClippingPlane is 10, farClippingPlane is -1). In this case the
non-negative value from X3DViewportNode shall be used for one clipping
plane, while the other clipping plane is still determined using bound
NavigationInfo."""

2. The ranges "[0,infinity)" do not reflect the actual requirements
perfectly. Although you cannot make them perfect with this design (you need
some special value to indicate "let this be determined by NavigationInfo"),
and because X3DViewpointNode is an ancestor for both Viewpoint and
OrthoViewpoint and their math has different requirements.

    So, possibly no change is necessary. But I just wanted to mention the
actual  limits:

    - For perspective viewpoints, both nearClippingPlane and
farClippingPlane must be > 0, never equal to zero. So the range would be
"-1 or (0,infinity)" .

    - For orthographic viewpoints, actually any values (including zero and
negative) are possible and make sense. CGE allows it (
https://castle-engine.io/apidoc-unstable/html/CastleCameras.TCastleCamera.html#ProjectionNear
). That said, I guess the specification can limit them to be >= 0 for
simplicity, otherwise you would have a problem with how to indicate "leave
as default".

Regards,
Michalis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200620/977ad7bc/attachment.html>