[x3d-public] X3D 4.0 specification problem: TextureProjectorparallel.fieldOfView

Wed Dec 18 15:59:06 PST 2024

During a specification editors' meeting yesterday, Dick and I made another step forward.

  *
Mantis 1398: OrthoViewpoint fieldOfView type needs to be SFVec4f, not MFFloat
  *
https://mantis.web3d.org/view.php?id=1398

namely

  *
If specialty methods for homogeneous transformations (or other operations) are needed by SAI implementations, they can receive specialized definitions to match.
  *
It is important to remember that (a) no nodes currently use homogenous coordinates, and (b) ClipPlane definition of a half-plane is different than the two parallel-projection extents.
  *
A graceful approach not requiring implementation changes might be adding prose to Clause 5 field definitions noting alternate usages may occur. For example, appended to the fist sentence, "or other usage of a 4-tuple."

We applied that change in draft X3D 4.1 Architecture, also committed into git and pushed online.

  *
5.3.20 SFVec4d and MFVec4d
  *
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/fieldTypes.html#SFVec4dAndMFVec4d
  *
5.3.21 SFVec4f and MFVec4f
  *
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/fieldTypes.html#SFVec4fAndMFVec4f

==========================
5.3.20 SFVec4d and MFVec4d
The SFVec4d field or event specifies a three-dimensional (3D) homogeneous vector, or other usage of a 4-tuple. An MFVec4d field or event specifies zero or more SFVec4d values. 3D homogeneous vectors. SFVec4d's and MFVec4d's are represented as a 4-tuple of double-precision floating point values (see 5.3.4 SFDouble and MFDouble). The allowable form for a double-precision floating point number is defined in the specific encoding.
The default value of an uninitialized SFVec4d field is (0 0 0 1). The default value of an MFVec4d field is the empty list.
5.3.21 SFVec4f and MFVec4f
The SFVec4f field or event specifies a three-dimensional (3D) homogeneous vector, or other usage of a 4-tuple. An MFVec4f field or event specifies zero or more SFVec4f values. 3D homogeneous vectors. SFVec4f's and MFVec4f's are represented as a 4-tuple of single-precision floating point values (see 5.3.5 SFFloat and MFFloat). The allowable form for a single-precision floating point number is defined in the specific encoding.
The default value of an uninitialized SFVec4f field is (0 0 0 1). The default value of an MFVec4f field is the empty list.
==========================

If anyone can think of any reason not to restrict validation of OrthoViewpoint fieldOfView to SFVec4f, instead of an MFFloat array of length 4, please speak up.  Am hoping to apply this change next to validation tools next, improving quality assurance and author confidence that a model is valid.  Avoiding run-time errors and maintaining consistency, with no harm to existing X3D models or implementations, is important.

Have fun with high-quality X3D!  🙂

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 https://faculty.nps.edu/brutzman

________________________________
From: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
Sent: Friday, December 13, 2024 1:14 PM
To: Holger Seelig <holger.seelig at yahoo.de>; X3D <x3d-public at web3d.org>
Cc: khyoo at chungbuk.ac.kr <khyoo at chungbuk.ac.kr>; Myeong Won Lee <myeongwonlee at gmail.com>
Subject: Re: [x3d-public] X3D 4.0 specification problem: TextureProjectorparallel.fieldOfView

Excellent question, thanks for asking Holger.

This issue has been carefully tracked and regularly revisited since July 2022.

  *
Mantis 1398: OrthoViewpoint fieldOfView type needs to be SFVec4f, not MFFloat
  *
https://mantis.web3d.org/view.php?id=1398
  *
Mantis 1468: must SFVec4f/SFVec4d fields be homogeneous?
  *
https://mantis.web3d.org/view.php?id=1468

The X3D Working Group was unable to reach consensus on this issue prior to conclusion of version 4.0, unfortunately.  Dick Puk and I took a close look at this recently too. Here is a synopsis of the Mantis issues.

I advocate use of SFVec4f for all parallel fieldOfView values because it is the strictest appropriate datatype that can validate content. Retaining the legacy MFFloat type definition for fieldOfView allows 3d models (produced by humans or tools) to define arrays of illegal length, making failures mysterious.  Conceptual consistency is important too.

Reviewing the Mantis issues, additional concerns included:

  *
Incompatibility with prior X3D implementations.  Since a 4-tuple content value is a valid MFFloat array, I'm not seeing any backwards incompatibility if a prior X3D 3.3 implementation encounters the four values of a SFVec4f array.  There are no representation problems since value syntax is compatible for our various encodings as well.

  *
SFVec4f fields are actually not homogenous coordinates.  The spec uses the word "homogenous" when referring to
     *
 X3D4 Architecture, Clause 5 Field type reference, 5.3.20 SFVec4d and MFVec4d
     *
https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/fieldTypes.html#SFVec4dAndMFVec4d
     *
"The SFVec4f field or event specifies a three-dimensional (3D) homogeneous vector." (and similarly for SFVec4d, SFVec4f and MFVec4f).
     *
However none of these fields are mathematically homogeneous, see
     *
https://en.wikipedia.org/wiki/Homogeneous_coordinates
     *
https://en.wikipedia.org/wiki/Homogeneous_coordinates#/media/File:RationalBezier2D.svg
     *
Of related note is that ClipPlane 4-tuple "plane" field is also SFVec4f.
     *
https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#ClipPlane

All review welcome, hopefully I have correctly synopsized all concerns.

I think it would be beneficial to resolve this issue by reaching consensus and applying remedies as follow.

  *
Omitting the over-strict word "homogenous" from the four SF/MF Vec 4f/4d definitions in future X3D 4.1 prose,
  *
Updating future X3D 4.1 prose to use SFVec4f for TextureProjectorParallel fieldOfView,
  *
Using SFVec4f in X3D 4.0 DTD, Schema, X3DUOM validation and X3D Tooltips, since that type strictly confirms fieldOfView correctness with no backwards compatibility problems.

Is consensus now possible?  Thanks for all careful consideration.

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 https://faculty.nps.edu/brutzman

________________________________
From: Holger Seelig <holger.seelig at yahoo.de>
Sent: Friday, December 13, 2024 11:29 AM
To: X3D <x3d-public at web3d.org>
Cc: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; khyoo at chungbuk.ac.kr <khyoo at chungbuk.ac.kr>; Myeong Won Lee <myeongwonlee at gmail.com>
Subject: Re: [x3d-public] X3D 4.0 specification problem: upVector field for TextureProjector, TextureProjectorParallel

I just realised that TextureProjectorparallel.fieldOfView is of type SFVec4f, but OrthoViewpoint.fieldOfView is of type MFFloat.

Which of the two is better?

OrthoViewpoint is definitely older.

I think of SFVec4f as a mathematical 4d vector.

https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/textureProjection.html#TextureProjectorParallel
https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/navigation.html#OrthoViewpoint

Best regards,
Holger

--
Holger Seelig
Leipzig, Germany

holger.seelig at yahoo.de
https://create3000.github.io/x_ite/

Am 08.12.2024 um 05:21 schrieb Brutzman, Donald (Don) (CIV) via x3d-public <x3d-public at web3d.org>:

However

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20241218/2e286efa/attachment-0001.html>