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

[Don Brutzman]

Sounds smart, we will integrate your concerns in the draft specification prose as we try to see whether this all hangs together.  Candidate addition to your words, perhaps redundant:

* "A default value of -1 for nearClippingPlane or farClippingPlane means that the field has no effect on currently active view-frustum boundaries."

Note I tried to carefully handle "which node is in charge" in the suggested prose, by only letting Viewpoint/OrthoViewpoint/GeoViewpoint fields override NavigationInfo active values at the time the individual X3DViewpointNode is bound.  If that node is subsequently unbound, then values revert to what we currently specify, i.e. the currently bound NavigationInfo.

We don't want to duplicate functionality (see the DRY principle) in the scene graph, but proper support of terrain in combination with models has always been distressingly difficult to achieve in practice.

One might also imagine animation of nearClippingPlane/farClippingPlane to be an excellent exploration/visualization technique, far easier and more flexible than modeling a ClipPlane node and a feature that players can optionally support as a viewer assist.  (ClipPlane still has important uses, of course.)

Hopefully this extra assist (Viewpoint near/far custom frustum, with NavigationInfo defaults otherwise) is helpful to authors and users, without a significant complication for implementations.

Again thanks for review and improvements.


On 6/19/2020 7:05 PM, Michalis Kamburelis wrote:
> Don Brutzman <brutzman at nps.edu <mailto: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

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