[x3d-public] X3D 4.0 specification problem: ClassicVRML Encoding, clause 5 Encoding of fields
John Carlson
yottzumm at gmail.com
Tue Dec 24 07:53:57 PST 2024
Note that this might come up in the JSON encoding, and I recommend that
arrays are always used to encode MF field values to avoid ballooning the
schema (eeps!). Unless we want our own JSON schema standard.
I also noticed that I was slightly incorrect in previous message. An MF
field value with brackets is not a valid SF field value.
Apologies !
John
On Tue, Dec 24, 2024 at 9:46 AM John Carlson <yottzumm at gmail.com> wrote:
> This says that an SF field value is a valid MF field value, so I retract
> the enclosed:
>
>
> https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html
>
> An MF field value is not valid SF field value anywhere, but I haven’t
> checked the grammar yet.
>
> Apologies!
>
> John
>
>
> On Tue, Dec 24, 2024 at 9:36 AM John Carlson <yottzumm at gmail.com> wrote:
>
>> Thanks, Michalis!
>>
>> I think I found one more, where an MFInt32 is shown as an SFInt32 under
>> Example 1, without brackets: “value 1”. I believe all MF nodes should have
>> brackets. Note if brackets are added, the example would be a duplicate.
>>
>> Question: is an MF field value with just brackets valid?
>>
>> John
>>
>>
>> On Tue, Dec 24, 2024 at 3:36 AM Michalis Kamburelis via x3d-public <
>> x3d-public at web3d.org> wrote:
>>
>>> Hi,
>>>
>>> I looked at
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-2v4.0-WD1/Part02/EncodingOfFields.html
>>> --- looks like a great improvement, thank you! The new prose with new
>>> examples is indeed more immediately obvious. It's also a good idea to
>>> use real nodes / fields for the examples, not only artificial fooXxx
>>> (as before), this makes things even more clear.
>>>
>>> One minor thing I noticed: in "5.1.2 Description" there's a typo,
>>> "around ingle-valued field types". You missed "s" in "single-valued"
>>> :)
>>>
>>> John also has good points (kudos for noticing):
>>>
>>> - SFVec2d example in 5.17 is wrong (" inputOutput SFVec2d field20 [
>>> 0.0 0.0 ]"), it should *not* use [ ].
>>>
>>> - SFVec4d in 5.21 is also indeed wrong, "inputOutput SFVec4d field24a
>>> [ 1.000000000001 42 666.35357878 32.6 ]" -> should have no brackets.
>>>
>>> Regards,
>>> Michalis
>>>
>>> wt., 24 gru 2024 o 02:18 Brutzman, Donald (Don) (CIV)
>>>
>>> <brutzman at nps.edu> napisał(a):
>>> >
>>> > It took several days of effort but this clause is now fixed up.
>>> Review and comments welcome.
>>> >
>>> > Mantis 1484: ClassicVRML Encoding of Fields clause does not include
>>> proper SFVec examples
>>> > https://mantis.web3d.org/view.php?id=1484
>>> >
>>> > X3D encodings Part 2: Classic VRML encoding, 5 Encoding of fields
>>> >
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-2v4.0-WD1/Part02/EncodingOfFields.html
>>> >
>>> > Happy holidays with X3D and VRML! 🙂
>>> >
>>> >
>>> > 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: x3d-public <x3d-public-bounces at web3d.org> on behalf of
>>> Brutzman, Donald (Don) (CIV) via x3d-public <x3d-public at web3d.org>
>>> > Sent: Thursday, December 19, 2024 10:43 AM
>>> > To: Michalis Kamburelis <michalis.kambi at gmail.com>
>>> > Cc: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; Extensible 3D
>>> (X3D) Graphics public discussion <x3d-public at web3d.org>;
>>> 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: ClassicVRML
>>> Encoding, clause 5 Encoding of fields
>>> >
>>> > [changed subject line to reflect changed focus]
>>> >
>>> > Thanks again for your patient explanations Michalis, totally helpful.
>>> We have finally zoomed in on the real problem.
>>> >
>>> > It is surprising (and maybe a little disappointing) that we have had
>>> such egregious and misleading omissions in the ClassicVRML field
>>> descriptions clause, unreported for so many years (since VRML97
>>> apparently). That was the cause of my mistaken thinking that encoding of
>>> values were similar. Nevertheless, it is a nice holiday present that we
>>> have finally identified this source of confusion so that it might finally
>>> get fixed.
>>> >
>>> > X3D 3.3 ClassicVRML Encoding, clause 5 Encoding of fields
>>> >
>>> https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/EncodingOfFields.html
>>> >
>>> > Have checked X3dToClassicVRML.xslt and X3dToVRML97.xslt stylesheet
>>> converters, X3DJSAIL export, and our many many X3D Example Archives
>>> scenes. They match what you are saying (thank goodness).
>>> >
>>> > I am adding this problem to the issue tracker. Dick and I will work
>>> on a revision for community review.
>>> >
>>> > Mantis 1484: ClassicVRML field reference does not include proper SFVec
>>> examples
>>> > https://mantis.web3d.org/view.php?id=1484
>>> >
>>> > Future revisions will appear in github and as follows. Let's watch
>>> for similar unintended errors in the specification, the ripples from spec
>>> errors spread a wide wake.
>>> >
>>> > X3D 4.0 ClassicVRML Encoding, clause 5 Encoding of fields
>>> >
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-2v4.0-WD1/Part02/EncodingOfFields.html
>>> >
>>> > Of course I also agree that fast efficient rigorous parsing holds
>>> essential importance. Your castle-model-viewer and castle-model-converter
>>> continue to be essential in our sustained efforts to get ClassicVRML
>>> exactly right.
>>> >
>>> > Castle Model Converter (formerly tovrmlx3d))
>>> > https://castle-engine.io/castle-model-converter
>>> >
>>> > Looking forward to continuing relentless progress with ClassicVRML and
>>> 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: Michalis Kamburelis <michalis.kambi at gmail.com>
>>> > Sent: Wednesday, December 18, 2024 8:38 PM
>>> > To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>>> > Cc: Extensible 3D (X3D) Graphics public discussion <
>>> x3d-public at web3d.org>; 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
>>> >
>>> > NPS WARNING: *external sender* verify before acting.
>>> >
>>> >
>>> > Hi Don,
>>> >
>>> > AD A -
>>> >
>>> > No, when writing the SFVec4f in X3D classic encoding, the square
>>> > brackets "[ ... ]" cannot be used. I believe my understanding matches
>>> > both the spec and all existing X3D implementations.
>>> >
>>> > 1. The example you noticed (on
>>> >
>>> https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/EncodingOfFields.html#SFVec4f
>>> > ) ... shows MFVec4f, not SFVec4f .
>>> >
>>> > It's indeed a bit misleading, as the spec section titled "5.20
>>> > SFVec3f and MFVec3f" describes both MF- and SF- variants. And the
>>> > example "fooVec3d [ 1.000000000001 42 666.35357878 32.6, 7 94
>>> > 0.100000000007 143.998 ]" lacks any annotation. Adding there a
>>> > description would help: "This is an example of MFVec4f in classic
>>> > encoding, fooVec3d contains here two 4-dimensional vectors." .
>>> >
>>> > 2. On the same page, the text higher makes it clear that "square
>>> > brackets" are used for multiple-value fields: """Multiple-valued
>>> > fields are written as an ordered list of values enclosed in square
>>> > brackets and separated by whitespace."""
>>> >
>>> > 3. The grammar on
>>> >
>>> https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html
>>> > confirms it:
>>> >
>>> > """
>>> > mffloatValue ::=
>>> > sffloatValue |
>>> > [ ] |
>>> > [ sffloatValues ] ;
>>> >
>>> > ....
>>> >
>>> > sfvec4fValue ::=float float float float ;
>>> > """"
>>> >
>>> > No square brackets for sfvec4fValue . (And that's good I think; square
>>> > brackets are consistently used in X3D classic encoding for lists of
>>> > values.)
>>> >
>>> > I do find the grammar very helpful to resolve such questions :) It's
>>> > unambiguous, and implementations (using my own) follow it literally.
>>> >
>>> > So, I think my concern still stands. Changing
>>> > OrthoViewport.fieldOfView type (MFFloat -> SFVec4f) would break
>>> > parsing of all the models in X3D classic encoding (and VRML 2.0) that
>>> > specify value of this field. They use right now square brackets [ .. ]
>>> > (necessary for MFFloat with > 1 value), which are not allowed for
>>> > SFVec4f.
>>> >
>>> > I honestly don't think there's a way to avoid it, except reverting
>>> > this spec change. I cannot change in our implementation
>>> > OrthoViewport.fieldOfView to SFVec4f -- I have users using classic
>>> > encoding, and VRML 2.0 too, we cannot really break it. And maintaining
>>> > exceptional treatment in the parser (to allow both MFFloat and
>>> > SFVec4f) is not maintainable, we cannot have special rules like this
>>> > (that depend on node and field name) at the parser level.
>>> >
>>> > I know that we could change the grammar (to allow [ ... ] in SFVec4f)
>>> > but IMHO we should not change the grammar (which will complicate
>>> > parsing) just to account this one single exceptional change to one
>>> > field in one node.
>>> >
>>> > AD B - No, I didn't describe any special handling in our parser. And
>>> > such exceptions during parsing would be really hard to maintain, I
>>> > deliberately don't want them. Parser should not have any special rules
>>> > for specific nodes or fields -- this makes parser code more obvious.
>>> >
>>> > On the contrary -- we parse OrthoViewport.fieldOfView as MFFloat
>>> > now. Only later (after parsing) we just look at the count of MFFloat.
>>> > When it's less than 4, we treat the remaining numbers as if they were
>>> > default. But this is nice "local" code near OrthoViewport.fieldOfView
>>> > logic. It's *not* part of the parser.
>>> >
>>> > Regards,
>>> > Michalis
>>> >
>>> > czw., 19 gru 2024 o 03:06 Brutzman, Donald (Don) (CIV)
>>> > <brutzman at nps.edu> napisał(a):
>>> > >
>>> > > Thanks for looking at this Michalis.
>>> > >
>>> > > 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:
>>> > >
>>> > > X3D Classic VRML encoding, clause 5 encoding of fields, 5.22 SFVec4f
>>> and MFVec4f
>>> > >
>>> https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/EncodingOfFields.html#SFVec4f
>>> > >
>>> > > 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.
>>> > > EXAMPLE
>>> > > fooVec3f [ 1 42 666 -43.8, 7 94 0 0.0001 ]
>>> > >
>>> > > ... And so am expecting your SFVec4f example would look the same,
>>> with [square brackets] around numeric values. Please advise what you
>>> think.
>>> > >
>>> > > OrthoViewpoint { fieldOfView [ -1 -1 1 1 ] }
>>> > >
>>> > >
>>> > > 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.
>>> > >
>>> > > C. We are currently working on ClassicVRML Encoding spec for v4.0
>>> now, so if any problems are found then we can resolve them.
>>> > >
>>> > > D. I found several problems with the Grammar... Dick and I also
>>> discussed them yesterday. When time permits, will post about that soon.
>>> > >
>>> > > Have fun with X3D ClassicVRML Encoding! 🙂
>>> > >
>>> > >
>>> > > 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: x3d-public <x3d-public-bounces at web3d.org> on behalf of
>>> Michalis Kamburelis via x3d-public <x3d-public at web3d.org>
>>> > > Sent: Wednesday, December 18, 2024 5:37 PM
>>> > > To: Extensible 3D (X3D) Graphics public discussion <
>>> x3d-public at web3d.org>
>>> > > Cc: Michalis Kamburelis <michalis.kambi 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
>>> > >
>>> > > The change of OrthoViewpoint.fieldOfView from MFFloat to SFVec4f
>>> > > breaks compatibility (badly) for X3D classic encoding, from what I
>>> can
>>> > > see.
>>> > >
>>> > > Previously (when OrthoViewpoint.fieldOfView is MFFloat, so in X3D <=
>>> > > 4.0 and VRML 2.0) this was valid:
>>> > >
>>> > > OrthoViewpoint { fieldOfView [ -1 -1 1 1 ] }
>>> > >
>>> > > And this was "undefined how it works (spec doesn't say what happens
>>> > > for < 4 values), but at least parsing was OK" (CGE made some effort
>>> to
>>> > > tolerate it):
>>> > >
>>> > > OrthoViewpoint { fieldOfView [ -1 -1 ] }
>>> > >
>>> > > Now (when OrthoViewpoint.fieldOfView is SFVec4f) both above are
>>> > > invalid, at parsing. One has to write this:
>>> > >
>>> > > OrthoViewpoint { fieldOfView -1 -1 1 1 }
>>> > >
>>> > > ... but the new form is invalid if loaded into a browser that expects
>>> > > OrthoViewpoint.fieldOfView to be old MFFloat.
>>> > >
>>> > > And, before anyone suggests this: It's not reasonable for X3D
>>> browsers
>>> > > to define OrthoViewpoint.fieldOfView with one type for X3D >= 4.1,
>>> and
>>> > > another type for older X3D versions. At least I cannot imagine
>>> > > maintaining this exceptional behavior throughout the codebase :) We
>>> > > need to have a one definition of OrthoViewpoint with one type for
>>> > > fieldOfView, otherwise we cause a big complication (also for
>>> > > developers using our API).
>>> > >
>>> > > So, I'm a bit baffled what to do. If I change
>>> > > OrthoViewpoint.fieldOfView to SFVec4f, I *will* break some X3D models
>>> > > for users and I will get bugreports about it. If I don't, I will not
>>> > > be compatible with X3D 4.1. For now, I choose the latter.
>>> > >
>>> > > Regards,
>>> > > Michalis
>>> > >
>>> > > czw., 19 gru 2024 o 01:42 John Carlson via x3d-public
>>> > > <x3d-public at web3d.org> napisał(a):
>>> > >
>>> > >
>>> > >
>>> > > >
>>> > > > 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcoderextreme%2FX3DJSONLD%2Fissues&data=05%7C02%7Cbrutzman%40nps.edu%7C98ebb53e439741334cb708dd1fe70c37%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638701800556379299%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=sNGbCXeuSBEnFH2Mnp8RVNttmB%2FqDIKHhbv6YaxdOjE%3D&reserved=0
>>> > > >
>>> > > >
>>> > > > 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FHomogeneous_coordinates&data=05%7C02%7Cbrutzman%40nps.edu%7C98ebb53e439741334cb708dd1fe70c37%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638701800556398488%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=%2F3CZD9IDEdkAZaIJ9BWi4dKFk0mblQfkBstpx0lEsg0%3D&reserved=0
>>> > > >>
>>> 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%7C98ebb53e439741334cb708dd1fe70c37%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638701800556410503%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=Q%2BWMcMy2W%2FYzedb2wd7Efsgd28M1of%2FFy3pO2GKRTF4%3D&reserved=0
>>> > > >> 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2F&data=05%7C02%7Cbrutzman%40nps.edu%7C98ebb53e439741334cb708dd1fe70c37%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638701800556422280%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=EyAy636i6iNSYFBrRDdqg178Wi93D3sVzQJQ%2FqGIxDc%3D&reserved=0
>>> > > >>
>>> > > >> 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
>>> > > >
>>> > > > _______________________________________________
>>> > > > x3d-public mailing list
>>> > > > x3d-public at web3d.org
>>> > > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>> > >
>>> > > _______________________________________________
>>> > > x3d-public mailing list
>>> > > x3d-public at web3d.org
>>> > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>>> _______________________________________________
>>> 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/20241224/7f86aef2/attachment-0001.html>
More information about the x3d-public
mailing list