<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Thanks for thinking about alternatives. In general, however, we don't repeat functionality, in accordance with DRY principles:</div>
<ul data-editing-info="{"applyListStyleFromLevel":false,"unorderedStyleType":1}" style="list-style-type: disc;">
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">Wikipedia: Don't repeat yourself</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">https://en.wikipedia.org/wiki/Don't_repeat_yourself</div>
</li></ul>
<div id="Signature" class="elementToProof">
<p style="margin: 0in; font-family: Calibri, sans-serif; font-size: 11pt;"><span style="font-family: "Courier New"; font-size: 9pt;">all the best, Don</span></p>
<p style="margin: 0in; font-family: Calibri, sans-serif; font-size: 11pt;"><span style="font-family: "Courier New"; font-size: 9pt;">--</span></p>
<p style="margin: 0in; font-family: Calibri, sans-serif; font-size: 11pt;"><span style="font-family: "Courier New"; font-size: 9pt;">Don Brutzman Naval Postgraduate School, Code USW/Br brutzman@nps.edu</span></p>
<p style="margin: 0in; font-family: Calibri, sans-serif; font-size: 11pt;"><span style="font-family: "Courier New"; font-size: 9pt;">Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149</span></p>
<p style="margin: 0in; font-family: Calibri, sans-serif; font-size: 11pt;"><span style="font-family: "Courier New"; font-size: 9pt;">X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman</span></p>
<p style="margin: 0in; font-family: Calibri, sans-serif; font-size: 11pt;"><span style="font-family: "Courier New"; font-size: 9pt;"> </span></p>
</div>
<div id="appendonsend"></div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div dir="ltr" id="divRplyFwdMsg"><span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> GPU Group <gpugroup@gmail.com><br>
<b>Sent:</b> Thursday, December 19, 2024 10:55 AM<br>
<b>To:</b> Extensible 3D (X3D) Graphics public discussion <x3d-public@web3d.org><br>
<b>Cc:</b> Brutzman, Donald (Don) (CIV) <brutzman@nps.edu>; Michalis Kamburelis <michalis.kambi@gmail.com>; khyoo@chungbuk.ac.kr <khyoo@chungbuk.ac.kr>; Myeong Won Lee <myeongwonlee@gmail.com><br>
<b>Subject:</b> Re: [x3d-public] X3D 4.0 specification problem: TextureProjectorparallel.fieldOfView</span>
<div class="elementToProof"> </div>
</div>
<div style="direction: ltr;">IDEA: _add_ another field with different name, with a sentinel value default</div>
<div style="direction: ltr;">fieldOfView4f SFVec4f -1 -1 -1 -1</div>
<div style="direction: ltr;">Then in run code, if that field is set at its default, use the original MFFloat field, else use the new SFVec4f field.</div>
<div style="direction: ltr;">-Doug</div>
<div style="direction: ltr;"><br>
</div>
<br>
<div style="direction: ltr;">On Wed, Dec 18, 2024 at 9:39 PM Michalis Kamburelis via x3d-public <<a href="mailto:x3d-public@web3d.org" id="OWA49784f7d-2262-5dce-8c9a-d8595faed3b3" class="OWAAutoLink">x3d-public@web3d.org</a>> wrote:</div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);">
Hi Don,<br>
<br>
AD A -<br>
<br>
No, when writing the SFVec4f in X3D classic encoding, the square<br>
brackets "[ ... ]" cannot be used. I believe my understanding matches<br>
both the spec and all existing X3D implementations.<br>
<br>
1. The example you noticed (on<br>
<a href="https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/EncodingOfFields.html#SFVec4f" id="OWAf983fcb5-7a96-a0a0-330c-19f871955bc2" class="OWAAutoLink" data-auth="NotApplicable">https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/EncodingOfFields.html#SFVec4f</a><br>
) ... shows MFVec4f, not SFVec4f .<br>
<br>
It's indeed a bit misleading, as the spec section titled "5.20<br>
SFVec3f and MFVec3f" describes both MF- and SF- variants. And the<br>
example "fooVec3d [ 1.000000000001 42 666.35357878 32.6, 7 94<br>
0.100000000007 143.998 ]" lacks any annotation. Adding there a<br>
description would help: "This is an example of MFVec4f in classic<br>
encoding, fooVec3d contains here two 4-dimensional vectors." .<br>
<br>
2. On the same page, the text higher makes it clear that "square<br>
brackets" are used for multiple-value fields: """Multiple-valued<br>
fields are written as an ordered list of values enclosed in square<br>
brackets and separated by whitespace."""<br>
<br>
3. The grammar on<br>
<a href="https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html" id="OWA17a20e87-306e-3028-5a7d-cf082560e45c" class="OWAAutoLink" data-auth="NotApplicable">https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html</a><br>
confirms it:<br>
<br>
"""<br>
mffloatValue ::=<br>
sffloatValue |<br>
[ ] |<br>
[ sffloatValues ] ;<br>
<br>
....<br>
<br>
sfvec4fValue ::=float float float float ;<br>
""""<br>
<br>
No square brackets for sfvec4fValue . (And that's good I think; square<br>
brackets are consistently used in X3D classic encoding for lists of<br>
values.)<br>
<br>
I do find the grammar very helpful to resolve such questions :) It's<br>
unambiguous, and implementations (using my own) follow it literally.<br>
<br>
So, I think my concern still stands. Changing<br>
OrthoViewport.fieldOfView type (MFFloat -> SFVec4f) would break<br>
parsing of all the models in X3D classic encoding (and VRML 2.0) that<br>
specify value of this field. They use right now square brackets [ .. ]<br>
(necessary for MFFloat with > 1 value), which are not allowed for<br>
SFVec4f.<br>
<br>
I honestly don't think there's a way to avoid it, except reverting<br>
this spec change. I cannot change in our implementation<br>
OrthoViewport.fieldOfView to SFVec4f -- I have users using classic<br>
encoding, and VRML 2.0 too, we cannot really break it. And maintaining<br>
exceptional treatment in the parser (to allow both MFFloat and<br>
SFVec4f) is not maintainable, we cannot have special rules like this<br>
(that depend on node and field name) at the parser level.<br>
<br>
I know that we could change the grammar (to allow [ ... ] in SFVec4f)<br>
but IMHO we should not change the grammar (which will complicate<br>
parsing) just to account this one single exceptional change to one<br>
field in one node.<br>
<br>
AD B - No, I didn't describe any special handling in our parser. And<br>
such exceptions during parsing would be really hard to maintain, I<br>
deliberately don't want them. Parser should not have any special rules<br>
for specific nodes or fields -- this makes parser code more obvious.<br>
<br>
On the contrary -- we parse OrthoViewport.fieldOfView as MFFloat<br>
now. Only later (after parsing) we just look at the count of MFFloat.<br>
When it's less than 4, we treat the remaining numbers as if they were<br>
default. But this is nice "local" code near OrthoViewport.fieldOfView<br>
logic. It's *not* part of the parser.<br>
<br>
Regards,<br>
Michalis<br>
<br>
czw., 19 gru 2024 o 03:06 Brutzman, Donald (Don) (CIV)<br>
<<a href="mailto:brutzman@nps.edu" id="OWA6850ab23-3681-af53-7f77-dd84a8ff3b31" class="OWAAutoLink">brutzman@nps.edu</a>> napisał(a):<br>
><br>
> Thanks for looking at this Michalis.<br>
><br>
> A. Sorry but I'm not clear about what you are saying... Went to look at the existing ClassicVRML encoding and it is showing [square brackets] for SFVec4f:<br>
><br>
> X3D Classic VRML encoding, clause 5 encoding of fields, 5.22 SFVec4f and MFVec4f<br>
> <a href="https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/EncodingOfFields.html#SFVec4f" id="OWA0bab0774-fb47-068e-54b2-3bc864548609" class="OWAAutoLink" data-auth="NotApplicable">
https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/EncodingOfFields.html#SFVec4f</a><br>
><br>
> The SFVec4f field specifies a four-dimensional (4D) single-precision vector. An MFVec4f field specifies zero or more 4D single-precision vectors. SFVec4f's and MFVec4f's are encoded as four ISO C floating point values (see ISO/IEC 9899) separated by whitespace.<br>
> EXAMPLE<br>
> fooVec3f [ 1 42 666 -43.8, 7 94 0 0.0001 ]<br>
><br>
> ... And so am expecting your SFVec4f example would look the same, with [square brackets] around numeric values. Please advise what you think.<br>
><br>
> OrthoViewpoint { fieldOfView [ -1 -1 1 1 ] }<br>
><br>
><br>
> B. Depending on that, am next wondering... you describe how the current MFFloat approach already requires additional special handling by your parser if an incorrect number of values is encountered. If there is a difference regarding [square brackets] for
SFVec4f then maybe a parser adjustment for that might be possible too... Or, even if they are the same, maybe just keeping your error-handling parser for v3.3 content the same (also for backwards reliability) is a good idea also.<br>
><br>
> C. We are currently working on ClassicVRML Encoding spec for v4.0 now, so if any problems are found then we can resolve them.<br>
><br>
> D. I found several problems with the Grammar... Dick and I also discussed them yesterday. When time permits, will post about that soon.<br>
><br>
> Have fun with X3D ClassicVRML Encoding! 🙂<br>
><br>
><br>
> all the best, Don<br>
><br>
> --<br>
><br>
> Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" id="OWA2a76db3a-4b1a-0fae-a855-b51c30a82602" class="OWAAutoLink">
brutzman@nps.edu</a><br>
><br>
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>
><br>
> X3D graphics, virtual worlds, navy robotics <a href="https://faculty.nps.edu/brutzman" id="OWAad1c3b81-8764-ebae-1696-2f8f75db23d7" class="OWAAutoLink" data-auth="NotApplicable">
https://faculty.nps.edu/brutzman</a><br>
><br>
><br>
><br>
><br>
> ________________________________<br>
> From: x3d-public <<a href="mailto:x3d-public-bounces@web3d.org" id="OWA1671db9e-d881-4934-7670-017ac25f74bb" class="OWAAutoLink">x3d-public-bounces@web3d.org</a>> on behalf of Michalis Kamburelis via x3d-public <<a href="mailto:x3d-public@web3d.org" id="OWA6aeb6d94-f30b-fcad-2999-4eb0d0c199cf" class="OWAAutoLink">x3d-public@web3d.org</a>><br>
> Sent: Wednesday, December 18, 2024 5:37 PM<br>
> To: Extensible 3D (X3D) Graphics public discussion <<a href="mailto:x3d-public@web3d.org" id="OWA79146cbb-297c-f1ea-d425-2716ca0447d3" class="OWAAutoLink">x3d-public@web3d.org</a>><br>
> Cc: Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" id="OWAd8e6274b-f509-a84e-5cce-ff734de3e66f" class="OWAAutoLink">michalis.kambi@gmail.com</a>>;
<a href="mailto:khyoo@chungbuk.ac.kr" id="OWA941a77bb-1590-4a7c-85a1-79d330068574" class="OWAAutoLink">
khyoo@chungbuk.ac.kr</a> <<a href="mailto:khyoo@chungbuk.ac.kr" id="OWAa3d373ff-75f7-5da4-a250-e7d9220f5c53" class="OWAAutoLink">khyoo@chungbuk.ac.kr</a>>; Myeong Won Lee <<a href="mailto:myeongwonlee@gmail.com" id="OWA56e5b870-78f1-3911-5ed8-8dd54202b681" class="OWAAutoLink">myeongwonlee@gmail.com</a>><br>
> Subject: Re: [x3d-public] X3D 4.0 specification problem: TextureProjectorparallel.fieldOfView<br>
><br>
> The change of OrthoViewpoint.fieldOfView from MFFloat to SFVec4f<br>
> breaks compatibility (badly) for X3D classic encoding, from what I can<br>
> see.<br>
><br>
> Previously (when OrthoViewpoint.fieldOfView is MFFloat, so in X3D <=<br>
> 4.0 and VRML 2.0) this was valid:<br>
><br>
> OrthoViewpoint { fieldOfView [ -1 -1 1 1 ] }<br>
><br>
> And this was "undefined how it works (spec doesn't say what happens<br>
> for < 4 values), but at least parsing was OK" (CGE made some effort to<br>
> tolerate it):<br>
><br>
> OrthoViewpoint { fieldOfView [ -1 -1 ] }<br>
><br>
> Now (when OrthoViewpoint.fieldOfView is SFVec4f) both above are<br>
> invalid, at parsing. One has to write this:<br>
><br>
> OrthoViewpoint { fieldOfView -1 -1 1 1 }<br>
><br>
> ... but the new form is invalid if loaded into a browser that expects<br>
> OrthoViewpoint.fieldOfView to be old MFFloat.<br>
><br>
> And, before anyone suggests this: It's not reasonable for X3D browsers<br>
> to define OrthoViewpoint.fieldOfView with one type for X3D >= 4.1, and<br>
> another type for older X3D versions. At least I cannot imagine<br>
> maintaining this exceptional behavior throughout the codebase :) We<br>
> need to have a one definition of OrthoViewpoint with one type for<br>
> fieldOfView, otherwise we cause a big complication (also for<br>
> developers using our API).<br>
><br>
> So, I'm a bit baffled what to do. If I change<br>
> OrthoViewpoint.fieldOfView to SFVec4f, I *will* break some X3D models<br>
> for users and I will get bugreports about it. If I don't, I will not<br>
> be compatible with X3D 4.1. For now, I choose the latter.<br>
><br>
> Regards,<br>
> Michalis<br>
><br>
> czw., 19 gru 2024 o 01:42 John Carlson via x3d-public<br>
> <<a href="mailto:x3d-public@web3d.org" id="OWA10fece92-7292-1c83-9b95-91d02e33018c" class="OWAAutoLink">x3d-public@web3d.org</a>> napisał(a):<br>
><br>
><br>
><br>
> ><br>
> > 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.<br>
> ><br>
> > 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.<br>
> ><br>
> > Bug reports are welcome:<br>
> ><br>
> > <a href="https://github.com/coderextreme/X3DJSONLD/issues" id="OWA2c6495a9-bbdb-77d4-3b96-126a84381327" class="OWAAutoLink" originalsrc="https://github.com/coderextreme/X3DJSONLD/issues" data-auth="Verified">
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcoderextreme%2FX3DJSONLD%2Fissues&data=05%7C02%7Cbrutzman%40nps.edu%7Ce9332497b70d43ca087608dd1fcdf4fb%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638701691653049383%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AyqHZlOjY8eQ4Dx8jOZXNzIJ7rhJhKGMcK3%2BJdCwiJw%3D&reserved=0</a><br>
> ><br>
> ><br>
> > AFAIK, this does not affect X3D JSON, since MFFloat and SFVec4f are represented by arrays.<br>
> ><br>
> > 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.<br>
> ><br>
> > Someone speaking up can change the priority.<br>
> ><br>
> > John<br>
> ><br>
> > On Wed, Dec 18, 2024 at 6:00 PM Brutzman, Donald (Don) (CIV) via x3d-public <<a href="mailto:x3d-public@web3d.org" id="OWA08f6bc64-e8aa-5ecb-bfe7-32d1e9e01a9d" class="OWAAutoLink">x3d-public@web3d.org</a>> wrote:<br>
> >><br>
> >> During a specification editors' meeting yesterday, Dick and I made another step forward.<br>
> >><br>
> >> Mantis 1398: OrthoViewpoint fieldOfView type needs to be SFVec4f, not MFFloat<br>
> >> <a href="https://mantis.web3d.org/view.php?id=1398" id="OWA1593513d-06e7-9ea9-40c6-30157c97a066" class="OWAAutoLink" data-auth="NotApplicable">
https://mantis.web3d.org/view.php?id=1398</a><br>
> >><br>
> >> namely<br>
> >><br>
> >> If specialty methods for homogeneous transformations (or other operations) are needed by SAI implementations, they can receive specialized definitions to match.<br>
> >> 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.<br>
> >> 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."<br>
> >><br>
> >> We applied that change in draft X3D 4.1 Architecture, also committed into git and pushed online.<br>
> >><br>
> >> 5.3.20 SFVec4d and MFVec4d<br>
> >> <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/fieldTypes.html#SFVec4dAndMFVec4d" id="OWA50acd3e3-6054-e9af-bdc9-ee58603fb3ec" class="OWAAutoLink" data-auth="NotApplicable">
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/fieldTypes.html#SFVec4dAndMFVec4d</a><br>
> >> 5.3.21 SFVec4f and MFVec4f<br>
> >> <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/fieldTypes.html#SFVec4fAndMFVec4f" id="OWA3f4ebf2a-870c-ac27-f38b-874041e9d59e" class="OWAAutoLink" data-auth="NotApplicable">
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/fieldTypes.html#SFVec4fAndMFVec4f</a><br>
> >><br>
> >> ==========================<br>
> >> 5.3.20 SFVec4d and MFVec4d<br>
> >> 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.<br>
> >> The default value of an uninitialized SFVec4d field is (0 0 0 1). The default value of an MFVec4d field is the empty list.<br>
> >> 5.3.21 SFVec4f and MFVec4f<br>
> >> 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.<br>
> >> The default value of an uninitialized SFVec4f field is (0 0 0 1). The default value of an MFVec4f field is the empty list.<br>
> >> ==========================<br>
> >><br>
> >> 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.<br>
> >><br>
> >> Have fun with high-quality X3D! 🙂<br>
> >><br>
> >><br>
> >> all the best, Don<br>
> >><br>
> >> --<br>
> >><br>
> >> Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" id="OWAcb155801-bf71-ce28-44be-e71596665653" class="OWAAutoLink">
brutzman@nps.edu</a><br>
> >><br>
> >> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>
> >><br>
> >> X3D graphics, virtual worlds, navy robotics <a href="https://faculty.nps.edu/brutzman" id="OWAaafdab32-b0b4-8019-fe92-ba6dba1810aa" class="OWAAutoLink" data-auth="NotApplicable">
https://faculty.nps.edu/brutzman</a><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >> ________________________________<br>
> >> From: Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" id="OWA34a0f401-7d29-c964-62de-60d3fd388c6b" class="OWAAutoLink">brutzman@nps.edu</a>><br>
> >> Sent: Friday, December 13, 2024 1:14 PM<br>
> >> To: Holger Seelig <<a href="mailto:holger.seelig@yahoo.de" id="OWA5d71f84e-5692-9b38-586e-5762122ef69c" class="OWAAutoLink">holger.seelig@yahoo.de</a>>; X3D <<a href="mailto:x3d-public@web3d.org" id="OWA537ebee8-d5db-7944-9ded-d54580526c24" class="OWAAutoLink">x3d-public@web3d.org</a>><br>
> >> Cc: <a href="mailto:khyoo@chungbuk.ac.kr" id="OWA1fdecbba-1b55-fcc7-1a8c-9ff003fa1647" class="OWAAutoLink">
khyoo@chungbuk.ac.kr</a> <<a href="mailto:khyoo@chungbuk.ac.kr" id="OWA05d5cc66-4041-e2e9-e667-45cc98ba1af6" class="OWAAutoLink">khyoo@chungbuk.ac.kr</a>>; Myeong Won Lee <<a href="mailto:myeongwonlee@gmail.com" id="OWAe47b6388-9f21-a1cd-4d3b-e4329deb93c2" class="OWAAutoLink">myeongwonlee@gmail.com</a>><br>
> >> Subject: Re: [x3d-public] X3D 4.0 specification problem: TextureProjectorparallel.fieldOfView<br>
> >><br>
> >> Excellent question, thanks for asking Holger.<br>
> >><br>
> >> This issue has been carefully tracked and regularly revisited since July 2022.<br>
> >><br>
> >> Mantis 1398: OrthoViewpoint fieldOfView type needs to be SFVec4f, not MFFloat<br>
> >> <a href="https://mantis.web3d.org/view.php?id=1398" id="OWAa5438b7a-f9f0-69db-ff1a-f2d4425d84f3" class="OWAAutoLink" data-auth="NotApplicable">
https://mantis.web3d.org/view.php?id=1398</a><br>
> >> Mantis 1468: must SFVec4f/SFVec4d fields be homogeneous?<br>
> >> <a href="https://mantis.web3d.org/view.php?id=1468" id="OWA26749e77-3efe-0ad6-e4bf-e91f572617a9" class="OWAAutoLink" data-auth="NotApplicable">
https://mantis.web3d.org/view.php?id=1468</a><br>
> >><br>
> >> 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.<br>
> >><br>
> >> 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.<br>
> >><br>
> >> Reviewing the Mantis issues, additional concerns included:<br>
> >><br>
> >> 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.<br>
> >><br>
> >> SFVec4f fields are actually not homogenous coordinates. The spec uses the word "homogenous" when referring to<br>
> >><br>
> >> X3D4 Architecture, Clause 5 Field type reference, 5.3.20 SFVec4d and MFVec4d<br>
> >> <a href="https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/fieldTypes.html#SFVec4dAndMFVec4d" id="OWAe0833ed4-6e99-f7cd-1624-c6a4d1f53f78" class="OWAAutoLink" data-auth="NotApplicable">
https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/fieldTypes.html#SFVec4dAndMFVec4d</a><br>
> >> "The SFVec4f field or event specifies a three-dimensional (3D) homogeneous vector." (and similarly for SFVec4d, SFVec4f and MFVec4f).<br>
> >> However none of these fields are mathematically homogeneous, see<br>
> >> <a href="https://en.wikipedia.org/wiki/Homogeneous_coordinates" id="OWA1f6fe4a0-1099-52ef-3cf5-89123fec2d0a" class="OWAAutoLink" originalsrc="https://en.wikipedia.org/wiki/Homogeneous_coordinates" data-auth="Verified">
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FHomogeneous_coordinates&data=05%7C02%7Cbrutzman%40nps.edu%7Ce9332497b70d43ca087608dd1fcdf4fb%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638701691653068388%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GIqJEb5%2BdfBuqVtr4n6p7LMFOISOe5GWdBTfPAa4iZM%3D&reserved=0</a><br>
> >> <a href="https://en.wikipedia.org/wiki/Homogeneous_coordinates#/media/File:RationalBezier2D.svg" id="OWAe96c1049-957c-f123-e01f-156c4a0daeaa" class="OWAAutoLink" originalsrc="https://en.wikipedia.org/wiki/Homogeneous_coordinates#/media/File:RationalBezier2D.svg" data-auth="Verified">
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FHomogeneous_coordinates%23%2Fmedia%2FFile%3ARationalBezier2D.svg&data=05%7C02%7Cbrutzman%40nps.edu%7Ce9332497b70d43ca087608dd1fcdf4fb%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638701691653080970%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3yaU6Q9ggPxLGxQLF6kjaJDIRWPvbufWap41LalVcSY%3D&reserved=0</a><br>
> >> Of related note is that ClipPlane 4-tuple "plane" field is also SFVec4f.<br>
> >> <a href="https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#ClipPlane" id="OWA15fc2b80-44a5-fb5d-42c5-66ac860ad60e" class="OWAAutoLink" data-auth="NotApplicable">
https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#ClipPlane</a><br>
> >><br>
> >> All review welcome, hopefully I have correctly synopsized all concerns.<br>
> >><br>
> >> I think it would be beneficial to resolve this issue by reaching consensus and applying remedies as follow.<br>
> >><br>
> >> Omitting the over-strict word "homogenous" from the four SF/MF Vec 4f/4d definitions in future X3D 4.1 prose,<br>
> >> Updating future X3D 4.1 prose to use SFVec4f for TextureProjectorParallel fieldOfView,<br>
> >> 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.<br>
> >><br>
> >> Is consensus now possible? Thanks for all careful consideration.<br>
> >><br>
> >> all the best, Don<br>
> >><br>
> >> --<br>
> >><br>
> >> Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" id="OWA9df11465-ec26-af1f-2cd2-57d46a9b38c2" class="OWAAutoLink">
brutzman@nps.edu</a><br>
> >><br>
> >> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>
> >><br>
> >> X3D graphics, virtual worlds, navy robotics <a href="https://faculty.nps.edu/brutzman" id="OWA7185865d-7f29-a654-b039-32e97d4712fe" class="OWAAutoLink" data-auth="NotApplicable">
https://faculty.nps.edu/brutzman</a><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >> ________________________________<br>
> >> From: Holger Seelig <<a href="mailto:holger.seelig@yahoo.de" id="OWAddfc7a69-0c46-639e-653b-78b3d1474941" class="OWAAutoLink">holger.seelig@yahoo.de</a>><br>
> >> Sent: Friday, December 13, 2024 11:29 AM<br>
> >> To: X3D <<a href="mailto:x3d-public@web3d.org" id="OWA9c569e0b-4a60-773f-9a7f-b54320bb4be1" class="OWAAutoLink">x3d-public@web3d.org</a>><br>
> >> Cc: Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" id="OWAb69c7090-5b89-7eb9-f8a8-09cb00f8fd48" class="OWAAutoLink">brutzman@nps.edu</a>>;
<a href="mailto:khyoo@chungbuk.ac.kr" id="OWA2fd65859-0902-1094-2ee3-3bd948068575" class="OWAAutoLink">
khyoo@chungbuk.ac.kr</a> <<a href="mailto:khyoo@chungbuk.ac.kr" id="OWAdc9542f2-d9ac-b0c1-8701-94a2c2c39892" class="OWAAutoLink">khyoo@chungbuk.ac.kr</a>>; Myeong Won Lee <<a href="mailto:myeongwonlee@gmail.com" id="OWA3ad36fbc-65b8-e803-4171-4fdb8b5d18b2" class="OWAAutoLink">myeongwonlee@gmail.com</a>><br>
> >> Subject: Re: [x3d-public] X3D 4.0 specification problem: upVector field for TextureProjector, TextureProjectorParallel<br>
> >><br>
> >> I just realised that TextureProjectorparallel.fieldOfView is of type SFVec4f, but OrthoViewpoint.fieldOfView is of type MFFloat.<br>
> >><br>
> >> Which of the two is better?<br>
> >><br>
> >> OrthoViewpoint is definitely older.<br>
> >><br>
> >> I think of SFVec4f as a mathematical 4d vector.<br>
> >><br>
> >> <a href="https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/textureProjection.html#TextureProjectorParallel" id="OWAac679bbc-8db8-2abe-f224-5ffc5fde0606" class="OWAAutoLink" data-auth="NotApplicable">
https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/textureProjection.html#TextureProjectorParallel</a><br>
> >> <a href="https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/navigation.html#OrthoViewpoint" id="OWA64553042-0d8b-1bab-a557-aa42a3460897" class="OWAAutoLink" data-auth="NotApplicable">
https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/navigation.html#OrthoViewpoint</a><br>
> >><br>
> >> Best regards,<br>
> >> Holger<br>
> >><br>
> >> --<br>
> >> Holger Seelig<br>
> >> Leipzig, Germany<br>
> >><br>
> >> <a href="mailto:holger.seelig@yahoo.de" id="OWAce556ba6-04d7-df6d-8351-d5bb2f9ce929" class="OWAAutoLink">
holger.seelig@yahoo.de</a><br>
> >> <a href="https://create3000.github.io/x_ite/" id="OWAb520de07-2b53-72a3-1c37-a033124b26dc" class="OWAAutoLink" originalsrc="https://create3000.github.io/x_ite/" data-auth="Verified">
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2F&data=05%7C02%7Cbrutzman%40nps.edu%7Ce9332497b70d43ca087608dd1fcdf4fb%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638701691653095384%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KaG%2FqZ%2BPaMukrNf9LQIC%2BzeWjCq6JIN1LvKYWWybAbU%3D&reserved=0</a><br>
> >><br>
> >> Am 08.12.2024 um 05:21 schrieb Brutzman, Donald (Don) (CIV) via x3d-public <<a href="mailto:x3d-public@web3d.org" id="OWA3738b718-37a4-2394-317b-ad272b0ea8cc" class="OWAAutoLink">x3d-public@web3d.org</a>>:<br>
> >><br>
> >> However<br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> x3d-public mailing list<br>
> >> <a href="mailto:x3d-public@web3d.org" id="OWA9a9fbcac-ea74-68be-00df-abb88e91b7e8" class="OWAAutoLink">
x3d-public@web3d.org</a><br>
> >> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" id="OWAdbe2eaa7-79b3-4eb2-51b5-11494236e851" class="OWAAutoLink" data-auth="NotApplicable">
http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
> ><br>
> > _______________________________________________<br>
> > x3d-public mailing list<br>
> > <a href="mailto:x3d-public@web3d.org" id="OWA71c05c45-4f49-59b4-12a2-9237e4d5ce9f" class="OWAAutoLink">
x3d-public@web3d.org</a><br>
> > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" id="OWAbde2c466-2ebf-ea31-9462-122219e3f345" class="OWAAutoLink" data-auth="NotApplicable">
http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
><br>
> _______________________________________________<br>
> x3d-public mailing list<br>
> <a href="mailto:x3d-public@web3d.org" id="OWA7a6348db-76fc-cade-ff55-4a7da18d84fa" class="OWAAutoLink">
x3d-public@web3d.org</a><br>
> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" id="OWA45d78cba-2068-e109-f36b-a44e343a47dd" class="OWAAutoLink" data-auth="NotApplicable">
http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" id="OWA85bcd0ad-35a5-2f38-6d13-cd85fe4d0cfe" class="OWAAutoLink">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" id="OWA8497e570-34d9-723c-4a1b-fa63f84e9b66" class="OWAAutoLink" data-auth="NotApplicable">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote>
</body>
</html>