[x3d-public] Recall--Re: X3D 4.0 specification problem: OrthoViewpoint.fieldOfView
John Carlson
yottzumm at gmail.com
Sun Jul 27 00:39:30 PDT 2025
Okay, it seems to compile now, whew! Apparently something got messed up
with /c symbolic link when I was messing with Arch. When I replaced with
C: file system, the CLASSPATH worked.
Please view this model and see that the fieldOfView is wrong (it's not in
the Java code either)
$ npx sunrize at latest Connectors_JavaExport.x3dv
The .x3d export from Java is similar.
I grabbed a new copy of X3DJSAIL from the website, I will now try
generating Java from .x3d using X3DJSAIL.
Note, if I redirect CommandLine.java -toJava to standard out, say
Connectors.java, there's a bunch of stuff in the header which doesn't
compile.
Anyway, the error from JavaC is the same as before:
$ javac -cp ~/Downloads/X3DJSAIL.4.0.full.jar":." Connectors.java
Connectors.java:280: error: no suitable method found for
setFieldOfView(double,double,double,double)
.addChild(new
OrthoViewpoint().setDescription("OthoViewpoint").setCenterOfRotation(-3.13496,-4.19776,0.0).setFieldOfView(0.0,0.0,10.0,10.0).setPosition(-3.13496,-4.19776,10.0))
^
method OrthoViewpoint.setFieldOfView(float[]) is not applicable
(actual and formal argument lists differ in length)
method OrthoViewpoint.setFieldOfView(MFFloat) is not applicable
(actual and formal argument lists differ in length)
method OrthoViewpoint.setFieldOfView(ArrayList<Float>) is not applicable
(actual and formal argument lists differ in length)
method OrthoViewpoint.setFieldOfView(int[]) is not applicable
(actual and formal argument lists differ in length)
method OrthoViewpoint.setFieldOfView(double[]) is not applicable
(actual and formal argument lists differ in length)
1 error
Please check in changes to X3dToJava.xslt and X3DJSAIL jars.
On Sun, Jul 27, 2025 at 2:12 AM John Carlson <yottzumm at gmail.com> wrote:
> Don, can you double check that you checked in the X3dToJava.xslt?
>
> I have the most up-to-date version from sourceforge:
>
> PS C:\Users\jcarl\www.web3d.org\x3d\stylesheets> svn-diff .\X3dToJava.xslt
> PS C:\Users\jcarl\www.web3d.org\x3d\stylesheets>
>
> Then there's this weird thing, which I don't get????
>
> $ diff /c/Users/jcarl/www.web3d.org/x3d/stylesheets/X3dToJava.xslt
> ./X3dToJava.xslt
> 4629d4628
> < ($parentElementName='OrthoViewpoint' and
> $attributeName='fieldOfView') or
> 4814a4814
> > ($parentElementName='OrthoViewpoint' and
> $attributeName='fieldOfView') or
>
> Git diff shows there was a blank added at the end of a line:
>
> $ git diff X3dToJava.xslt
> warning: in the working copy of 'src/main/lib/stylesheets/X3dToJava.xslt',
> LF will be replaced by CRLF the next time Git touches it
> diff --git a/src/main/lib/stylesheets/X3dToJava.xslt
> b/src/main/lib/stylesheets/X3dToJava.xslt
> old mode 100755
> new mode 100644
> index 1237d9eb9..957564ccd
> --- a/src/main/lib/stylesheets/X3dToJava.xslt
> +++ b/src/main/lib/stylesheets/X3dToJava.xslt
> @@ -4626,6 +4626,7 @@ POSSIBILITY OF SUCH DAMAGE.
> ($parentElementName='MetadataFloat' and
> $attributeName='value') or
> ($parentElementName='NavigationInfo' and
> $attributeName='avatarSize') or
> ($parentElementName='NurbsTextureCoordinate' and
> $attributeName='weight') or
> + ($parentElementName='OrthoViewpoint' and
> $attributeName='fieldOfView') or
> ($parentElementName='ParticleSystem' and
> ($attributeName='colorKey' or $attributeName='texCoordKey')) or
> ($parentElementName='ScalarInterpolator' and
> $attributeName='keyValue') or
> ($parentElementName='SplineScalarInterpolator' and
> ($attributeName='keyValue' or $attributeName='keyVelocity')) or
> @@ -4811,7 +4812,6 @@ POSSIBILITY OF SUCH DAMAGE.
> <xsl:when test="
> ($localFieldType='SFVec4f') or
> ($parentElementName='ClipPlane' and
> $attributeName='plane') or
> - ($parentElementName='OrthoViewpoint' and
> $attributeName='fieldOfView') or
> ($parentElementName='TextureProjectorParallel' and
> $attributeName='fieldOfView')">
> <xsl:text>SFVec4f</xsl:text>
> </xsl:when>
>
> Also, please convert this Connectors.x3d to Java or see file produced from
> X3dToJava.xslt. I will attach the Java and the X3D. I will try converting
> to Java using X3DJSAIL.
>
> It looks like something didn't get checked in?
>
> On Fri, Jul 25, 2025 at 1:16 PM Don Brutzman <don.brutzman at gmail.com>
> wrote:
>
>> Part of X3D Architecture 4.0 final decisions was to keep OrthoViewpoint
>> fieldOfView with type MFFloat for backwards compatibility, rather than the
>> more-strict (and more-correct) type SFVec4f.
>>
>> Apologies but this type change was not applied to X3dToJava.xslt and so
>> the conversion you observed was erroneous. I have applied and checked in
>> this change, it now works for your example.
>>
>> When diagnosing a problem like this, the Javadoc is always helpful. It
>> shows three different methods for OrthoViewpoint setFieldOfView:
>>
>> -
>> https://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/Navigation/OrthoViewpoint.html#setFieldOfView(float%5B%5D)
>> -
>> https://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/Navigation/OrthoViewpoint.html#setFieldOfView(org.web3d.x3d.jsail.fields.MFFloat)
>> -
>> https://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/Navigation/OrthoViewpoint.html#setFieldOfView(java.util.ArrayList)
>>
>> Looking ahead, have added a goal TODO for X3DJSAIL that might flexibly
>> handle reasonable variations like this.
>>
>> - *Under consideration.* Add utility methods for variable-length
>> arguments (varargs
>> <https://docs.oracle.com/javase/8/docs/technotes/guides/language/varargs.html>)
>> to basic types.
>> -
>> https://docs.oracle.com/javase/8/docs/technotes/guides/language/varargs.html
>>
>> Thanks John for reporting this problem.
>>
>> all the best, Don
>>
>>
>> On Fri, Jul 25, 2025 at 2:40 AM John Carlson via x3d-public <
>> x3d-public at web3d.org> wrote:
>>
>>> Apparently, this got thrown in the forgotten pile? I'm not sure if I
>>> have the latest message here. I guess the messages happened over the Xmas
>>> holidays.
>>>
>>> X3DJSAIL is not compiling the setFieldOfView with 4 parameters,and my
>>> MFFloat separate class is not emitting anything either!
>>>
>>> Details on SourceForge.
>>>
>>> Thanks for looking at this!
>>>
>>> So while this views in Sunrize, the Java generated from it fails to
>>> produce XML or JSON that can immediately be seen (remove
>>> OrthoViewpoint.fieldOfView to see).
>>>
>>>
>>> https://github.com/create3000/Library/blob/main/Tests/Components/Shape/Connectors.x3d
>>>
>>> John
>>>
>>> On Fri, Dec 20, 2024 at 10:03 AM Brutzman, Donald (Don) (CIV) via
>>> x3d-public <x3d-public at web3d.org> wrote:
>>>
>>>> [changed subject line to match topic]
>>>>
>>>> To be clear, no changes have been applied anywhere for changing the
>>>> type from (MFFloat of length 4) to SFVec4f. Further we are not near
>>>> consensus. Here are the fields:
>>>>
>>>> - ClipPlane plane is *SFVec4f*
>>>> - TextureProjectorParallel fieldOfView is *SFVec4f*
>>>> - OrthoViewpoint fieldOfView is *MFFloat of length 4* (which is not
>>>> easily validatable, and inconsistent)
>>>>
>>>> Until our email discussion this past week, I had mistakenly thought
>>>> that such a potential v4.1 change did not break backwards compatibility
>>>> with any of our existing file encodings... Thanks for patiently helping to
>>>> achieve that realization. The cause of this misunderstanding was due to
>>>> omissions in the v3.3 ClassicVRML specification regarding use of brackets -
>>>> they are not applied to SF types. We are now working on corrections with
>>>> rationale and preliminary changes in the draft v4.0 ClassicVRML
>>>> specification.
>>>>
>>>> - Mantis 1484: ClassicVRML field reference does not include proper
>>>> SFVec examples
>>>> - https://mantis.web3d.org/view.php?id=1484
>>>>
>>>> - X3D Classic VRML encoding version 4.0 draft, clause 5 Encoding of
>>>> fields
>>>> -
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-2v4.0-WD1/Part02/EncodingOfFields.html
>>>> - One of several suggested revisions in progress:
>>>> - "Single-valued fields (SF types) are written as a list of one or
>>>> more values, depending on the type. (For example, an SFVec3f type is a
>>>> three-tuple array of three float values.) No square brackets ("[ ]") are
>>>> written."
>>>>
>>>> The best time to fix this inconsistent typing would have been when we
>>>> approved a number of corrections in X3D 4.0. We did not reach agreement
>>>> during that long effort.
>>>>
>>>> The strict typing of X3D is very powerful. Given our long efforts to
>>>> achieve a unified object model, there are very few inconsistencies...
>>>> offhand, am unable to think of any others. Validatable fast parsing is
>>>> also very powerful. We won't be breaking that by engineering hacks into
>>>> the field grammars.
>>>>
>>>> This keeps us unchanged at your option (1) below, Michalis. Due to
>>>> being unable to reconcile a change for an early X3D design choice (in
>>>> version 3.2) for OrthoViewpoint fieldOfView: we live with this
>>>> inconsistency, allowing the presence of undetected invalid content in
>>>> models. Example errors:
>>>>
>>>> <OrthoViewpoint DEF='Error1' fieldOfView='0'/>
>>>> <OrthoViewpoint DEF='Error2' fieldOfView='0 0'/>
>>>> <OrthoViewpoint DEF='Error3' fieldOfView='0 0 1'/>
>>>> <OrthoViewpoint DEF='Error5' fieldOfView='0 0 1 1 1'/>
>>>>
>>>> As before during X3D 4.0 review, I don't recommend this state of
>>>> affairs but can live with it.
>>>>
>>>> If there is willingness to change, the only remaining path forward is
>>>>
>>>> - Agreeing to fix this type inconsistency in X3D 4.1,
>>>> OrthoViewpoint fieldOfView becomes SFVec3f
>>>> - VRML parsers support either form of encoding (perhaps adapting
>>>> Doug's suggestion). For example
>>>> - DEF Original3.2 OrthoViewpoint { fieldOfView [1, -1, 1, 1] } #
>>>> with square brackets
>>>> - DEF Revised4.x OrthoViewpoint { fieldOfView -1 -1 1 1
>>>> } # without square brackets
>>>>
>>>> Onward we go. Happy Holidays everyone.
>>>>
>>>>
>>>> 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:* Friday, December 20, 2024 12:34 AM
>>>> *To:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>>>> *Cc:* GPU Group <gpugroup at gmail.com>; 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
>>>>
>>>> Personally, I like Doug solution with "fieldOfView4f SFVec4f" .
>>>>
>>>> As for DRY -- indeed it would be perfect to not have 2 fields doing
>>>> the same thing, but in the current situation we don't have a luxury of
>>>> doing a perfect solution :) Next steps, in my order of preference:
>>>>
>>>> 1. Simply revert this change. Make OrthoViewport.fieldOfView again
>>>> MFFloat.
>>>>
>>>> The problems introduced by this change are not worth the gain,
>>>> IMHO. Changing OrthoViewport.fieldOfView to SFVec4f is a consistency
>>>> improvement for a single field in single node. It's not worth now
>>>> checking / changing encodings and APIs to make sure that everything
>>>> that gets/sets MFFloat can also get/set SFVec4f.
>>>>
>>>> 2. Add 2nd field with SFVec4f, like "fieldOfView4f". Keep
>>>> "fieldOfView" as MFFloat.
>>>>
>>>> I propose a modified version of Doug suggestion (different
>>>> fallback order, because it seems more natural to check MFFloat count):
>>>>
>>>> - new field "fieldOfView4f SFVec4f -1 -1 -1 -1"
>>>> - change existing "fieldOfView MFFloat" default to []
>>>> - spec says:
>>>> Authors: please use fieldOfView4f, consider fieldOfView
>>>> deprecated.
>>>> Implementors: if fieldOfView.count <> 0 then use fieldOfView,
>>>> else use fieldOfView4f
>>>>
>>>> 3. (Please let's not do this :) ) Modify X3D classic encoding grammar
>>>> to allow [ ] around SFVec4f values.
>>>>
>>>> I can see that Don may be leaning towards this (since you thought
>>>> this is already how X3D classic encoding works a few days ago) but it
>>>> would be a very unoptimal solution IMHO:
>>>>
>>>> - One, because it means escalating a small change into a big
>>>> change. Changing "OrthoViewport.fieldOfView" is about one single field
>>>> in single node. Changing X3D classic grammar means changing the
>>>> grammar and parsing. And the grammar should be consistent, so it would
>>>> likely spiral into allowing [ ] for other types as well, like SFVec3f.
>>>>
>>>> - The 2nd reason is that it's an incomplete fix anyway. While it
>>>> will allow new browsers (that implement new grammar) to handle both
>>>> old and new X3D models (whether author used [ ] or not aroud
>>>> "OrthoViewport.fieldOfView")... But
>>>>
>>>> A. The old browsers (implementing original grammar) will not be
>>>> able to read files using "OrthoViewpoint { fieldOfView -1 -1 1 1 }",
>>>> they will throw parsing
>>>> error exceptions. I understand it's a minor issue, old browsers are
>>>> not supposed to handle X3D 4.1, but users do not like paying attention
>>>> to version changes. Users assume (correctly!) that versions changes
>>>> generally don't cause problems.
>>>>
>>>> B. We still have compatibility break if someone used PROTO with
>>>> IS for "OrthoViewport.fieldOfView". This PROTO field type will need to
>>>> change.
>>>>
>>>> C. We still have compatibility break for other APIs using X3D
>>>> (like CGE Pascal API, but I suspect all other API like from Java etc.
>>>> -- unless one introduces overloads to handle both types).
>>>>
>>>> Thanks for the discussion. Let's keep going toward a solution that is
>>>> the best compromise :)
>>>>
>>>> Regards,
>>>> Michalis
>>>>
>>>>
>>>> czw., 19 gru 2024 o 20:26 Brutzman, Donald (Don) (CIV)
>>>>
>>>>
>>>> <brutzman at nps.edu> napisał(a):
>>>> >
>>>> > Thanks for thinking about alternatives. In general, however, we
>>>> don't repeat functionality, in accordance with DRY principles:
>>>> >
>>>> > Wikipedia: Don't repeat yourself
>>>> >
>>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDon%27t_repeat_yourself&data=05%7C02%7Cbrutzman%40nps.edu%7Ca798d8810015488b460008dd20d133db%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638702806790110709%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=EUA%2FyLVNpeDBd9%2FvGiI%2FBdWCee3S8PjV%2FsD9vDFO2U0%3D&reserved=0
>>>> <https://en.wikipedia.org/wiki/Don't_repeat_yourself>
>>>> >
>>>> > 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: GPU Group <gpugroup at gmail.com>
>>>> > Sent: Thursday, December 19, 2024 10:55 AM
>>>> > To: Extensible 3D (X3D) Graphics public discussion <
>>>> x3d-public at web3d.org>
>>>> > Cc: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; 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
>>>> >
>>>> > IDEA: _add_ another field with different name, with a sentinel value
>>>> default
>>>> > fieldOfView4f SFVec4f -1 -1 -1 -1
>>>> > Then in run code, if that field is set at its default, use the
>>>> original MFFloat field, else use the new SFVec4f field.
>>>> > -Doug
>>>> >
>>>> >
>>>> > On Wed, Dec 18, 2024 at 9:39 PM Michalis Kamburelis via x3d-public <
>>>> x3d-public at web3d.org> wrote:
>>>> >
>>>> > 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%7Ca798d8810015488b460008dd20d133db%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638702806790133840%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=RD2m3DWAfH1d5QDVg9p4%2FNlXnkSInA%2FxG5bnd%2F1pHIM%3D&reserved=0
>>>> <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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FHomogeneous_coordinates&data=05%7C02%7Cbrutzman%40nps.edu%7Ca798d8810015488b460008dd20d133db%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638702806790151701%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=%2B0692Ipq84A8Mo8IxSIa9LaK8DV1PD%2B9nMWL%2FjvYUbg%3D&reserved=0
>>>> <https://en.wikipedia.org/wiki/Homogeneous_coordinates>
>>>> > > >>
>>>> 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%7Ca798d8810015488b460008dd20d133db%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638702806790164107%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=WDz40uRYwtPE3R%2FLIFURKLUaHvA%2BcuK%2BQIdfIwLebb0%3D&reserved=0
>>>> <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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2F&data=05%7C02%7Cbrutzman%40nps.edu%7Ca798d8810015488b460008dd20d133db%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638702806790176380%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=LboRmmKHHvcVGr3DesWxfIea4ahYZNkm8bj0JQ%2FTXrE%3D&reserved=0
>>>> <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
>>>> > > >
>>>> > > > _______________________________________________
>>>> > > > 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
>>>>
>>> _______________________________________________
>>> 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/20250727/ebedfbda/attachment-0001.html>
More information about the x3d-public
mailing list