[x3d-public] X3D 4.0 specification problem: TextureProjectorparallel.fieldOfView
John Carlson
yottzumm at gmail.com
Wed Dec 18 16:41:39 PST 2024
I’m imagining there will be changes to C++ SAI. Once new types are in
place I can attempt to test. I suggest getting an X3DUOM out soon, so I
can regenerate my fieldTypes.js file, which affects all my serializers.
No one is using my serializers that I know of, so this particular change
won’t probably affect anyone. They would have to update, and I don’t
currently recommend that.
Bug reports are welcome:
https://github.com/coderextreme/X3DJSONLD/issues
AFAIK, this does not affect X3D JSON, since MFFloat and SFVec4f are
represented by arrays.
If you recommend tweaking X3DUOM before your release, I can see what I can
do, but it’s not currently a priority for me. Reading the X_ITE component
into Blender is higher priority.
Someone speaking up can change the priority.
John
On Wed, Dec 18, 2024 at 6:00 PM Brutzman, Donald (Don) (CIV) via x3d-public
<x3d-public at web3d.org> wrote:
> 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
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20241218/a3630004/attachment-0001.html>
More information about the x3d-public
mailing list