[x3d-public] X3D 4.0 specification problem: TextureProjectorparallel.fieldOfView
Brutzman, Donald (Don) (CIV)
brutzman at nps.edu
Sun Dec 15 10:38:28 PST 2024
Joe, thanks for thinking about these things. Yes, it can be a little confusing since the two texture projection nodes have merged some of the characteristics of both image texturing and viewpoints/cameras simultaneously. Hopefully the two diagrams make it clear what is going on.
The fields for these two nodes have gone through several stages of evolution already. Since they are both approved in X3D 4.0 we are not doing any redesign of the features or fields that are there. I think they are well designed and look forward to further implementation experience as more support emerges.
X3D 4.0 Architecture has already received final ISO approval as an international standard last December, so that document will not be changing. Meanwhile, implementers and modelers own the present, while our consensus-based community and Consortium owns what is best for the future.
Please note that the current proposed adjustments for upVector default value validation have no effect on prior model content and are considered beneficial for continuing model consistency.
At this stage, only a few additional steps are possible. First, please. review the X3D tooltips to see if they appear clearly phrased to you, Improvements are always welcome. Second, we can look at the mantis issue details and the suggested prose changes for 4.1 as we proceed forward. Example models are always welcome too.
Have fun with X3D! 😀
v/r Don
(Power outage here, on cell phone)
________________________________
From: x3d-public <x3d-public-bounces at web3d.org> on behalf of Joe D Williams via x3d-public <x3d-public at web3d.org>
Sent: Friday, December 13, 2024 21:05
To: Extensible 3D (X3D) Graphics public discussion <x3d-public at web3d.org>; Extensible 3D (X3D) Graphics public discussion <x3d-public at web3d.org>; Konstantin Smirnov <konstantin.e.smirnov at gmail.com>
Cc: joedwil at earthlink.net <joedwil at earthlink.net>; 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
Hi,
I'm just trying to see why the parameters are so different from viewpoint and other lights.
17.4.1 DirectionalLight
SFVec3f [in,out] direction 0 0 -1
17.4.3 SpotLight
SFVec3f [in,out] direction 0 0 -1
42.4.1 TextureProjector
SFVec3f [in,out] direction 0 0 1
should be default 0 0 -1 toward -z
(Really should be orientation?)
SFVec3f [in,out] upVector 0 0 1
this not needed (see orientation)
or should be default 0 1 0 (Yup) in Viewpoint coordinate system
Using like a Viewpoint with headlight as textureprojector but
viewpoint can be animated independently of textureprojector
Animating this coordinated with Viewpoint is typical
TP Needs to use:
default Viewpoint coordinate system
(0 0 1 0 = Yup, +x right of viewer, facing -z)
and orientation navigation using axis-angle,
Not simple and weaker directon x y z angles
spotlight movement.
notes:
23.4.6 Viewpoint
SFRotation [in,out] orientation 0 0 1 0 [-1,1],(-8,8)
SFVec3f [in,out] position 0 0 10 (-8,8)
17.4.1 DirectionalLight
SFVec3f [in,out] direction 0 0 -1 (-8,8)
17.4.3 SpotLight
SFVec3f [in,out] direction 0 0 -1 (-8,8)
SFVec3f [in,out] location 0 0 0 (-8,8)
42.4.1 TextureProjector
SFVec3f [in,out] direction 0 0 1 (-8,8)
SFVec3f [in,out] location 0 0 0 (-8,8)
SFVec3f [in,out] upVector 0 0 1
(missing (-8,8) notation)
18.4.2 MovieTexture
(nothing)
Figure 42.5 shows upVector and location
"The direction is the way the perspective projector
is heading, and this implies to perspective projection
direction. "
Thanks,
Joe
-----Original Message-----
From: Extensible 3D (X3D) Graphics public discussion <x3d-public at web3d.org>
Sent: Dec 13, 2024 3:39 PM
To: Extensible 3D (X3D) Graphics public discussion <x3d-public at web3d.org>, Konstantin Smirnov <konstantin.e.smirnov at gmail.com>
Cc: John Carlson <yottzumm at gmail.com>, 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
I have no issue with SFVec4f. My only concern is system which require field names like x:, y:, z:, … prior to a number. That would seem strange. In that case, MFFloat might be better, or an interval field type, which might not participate in many vital events. Konstantin might be a good source of information.
Food for thought.
John
On Fri, Dec 13, 2024 at 3:15 PM Brutzman, Donald (Don) (CIV) via x3d-public <x3d-public at web3d.org<mailto:x3d-public at web3d.org>> wrote:
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<mailto: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<mailto:holger.seelig at yahoo.de>>
Sent: Friday, December 13, 2024 11:29 AM
To: X3D <x3d-public at web3d.org<mailto:x3d-public at web3d.org>>
Cc: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu<mailto:brutzman at nps.edu>>; khyoo at chungbuk.ac.kr<mailto:khyoo at chungbuk.ac.kr> <khyoo at chungbuk.ac.kr<mailto:khyoo at chungbuk.ac.kr>>; Myeong Won Lee <myeongwonlee at gmail.com<mailto: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<mailto: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<mailto:x3d-public at web3d.org>>:
However
_______________________________________________
x3d-public mailing list
x3d-public at web3d.org<mailto: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/20241215/121b143a/attachment-0001.html>
More information about the x3d-public
mailing list