[x3d-public] Recall--Re: X3D 4.0 specification problem: OrthoViewpoint.fieldOfView
John Carlson
yottzumm at gmail.com
Fri Jul 25 07:23:44 PDT 2025
Michalis,
I read your second message after my response to your first message.
People can find lots of issues with my software, but no one cares to.
The point is that I am distracted from my work, because of issues
with other authors, and then they paper over my bug reports.
I get it so much, I tend to have a bad reaction now.
I am now debugging X3DJSAIL in order to find the issue with X3DJSAIL.
This code in MFFloat.java looks suspicious, but I understand there may be a
variable and a class with the same name. I wouldn't code it this way,
because I program in JavaScript a lot. You're going to confuse the heck
out of a JavaScript programmer looking at this code.
public MFFloat(MFFloat newValue)
{
if (newValue == null)
{
MFFloat = java.util.Arrays.copyOf(DEFAULT_VALUE,
DEFAULT_VALUE.length); // must be separate copy
return;
}
MFFloat = newValue.getPrimitiveValue();
}
Another section might use .equals(), but I've not verified if Array has
equals(), especially due to generics:
public boolean equals(MFFloat comparisonMFFloat)
{
if (comparisonMFFloat == null)
return false;
else return (getPrimitiveValue() ==
comparisonMFFloat.getPrimitiveValue());
}
Now, I've verified that Array doesn't use equals() except it uses
Object.equals(). I'm guessing that code will always return false, unless
you're comparing one MFFloat to itself. Equals() is more about comparing
the Object, not the pointer, so there might be a semantics issue. Anyway,
AFAIK, equals() should return false, for the most part.
Looking at fundamentals, I see again, some weird class/variable issues,
where MFFloat is both a class and a float[] variable. I wonder how that
flies in something like GraalJS?
public float[] getPrimitiveValue()
{
return MFFloat;
}
Here's where the default comparison in OrthoViewpoint.java, before it's
written to XML:
if ((((getFieldOfView().length > 0) &&
!getFieldOfViewList().equals(FIELDOFVIEW_DEFAULT_VALUE)) ||
!ConfigurationProperties.getStripDefaultAttributes()) /* ArrayList .x3d
compare */ && !hasUSE())
{
stringX3D.append("
fieldOfView='").append(MFFloat.toString(getFieldOfView())).append("'");
}
I am attaching my intermediate XML output from X3DJSAIL.
Some notes:
// A little lesson in Java:
class Aray {
public static void main(String[] args) {
float[] array1 = new float[] { 1.0f, 2.0f, 3.0f };
float[] array2 = new float[] { 1.0f, 2.0f, 3.0f };
System.out.println(array1.equals(array2)); // false
System.out.println(array1.equals(array1)); // true
System.out.println(array1 == array2); // false
System.out.println(array1 == array1); // true
}
// From OrthoViewpoint.java
// public static final ArrayList<Float> FIELDOFVIEW_DEFAULT_VALUE =
new ArrayList<>(Arrays.asList(-1f,-1f,1f,1f));
// since I'm constructing the array from numbers in a X3D to JSON
to DOM to Java, it will never have the default value, unless I explicitly
hand code the constant or test for the default value before writing out in
generated Java field value. But if I pass in the constant, it *might* be
converted to MFFloat, which is a float[] array.
/// From MFFloat.java
// private float[] MFFloat = java.util.Arrays.copyOf(DEFAULT_VALUE,
DEFAULT_VALUE.length);/
}
Indeed, Don makes care to test for default values in the X3dTo*.xslt
stylesheets. He's a better man than me!
On Fri, Jul 25, 2025 at 8:10 AM Michalis Kamburelis <
michalis.kambi at gmail.com> wrote:
> Thank you for the bugreport about Castle Model Viewer, I'll fix it.
> Quick testing shows that this Castle Model Viewer problem is unrelated
> to "OrthoViewpoint.fieldOfView", since even removing entire
> OrthoViewpoint node from the testcase -> still causes the error. We
> mix up something during the PROTO expansion, I'll debug it over the
> weekend and fix.
>
> BTW, I'm uncertain why did you use this tone ("Maybe mend your own
> ship?"). I didn't criticize your work, I didn't even point to any bug
> in any software in the message I wrote today. When I said "I know
> nothing about what X3DJSAIL supports", I meant it very literally, I
> just have no knowledge about what X3DJSAIL supports in regards
> toOrthoViewpoint.fieldOfValue. This statements was meant to express my
> state of my knowledge about X3DJSAIL, not anything else.
>
> My point in this thread was just to explain the conclusion we have
> reached about the state of "OrthoViewpoint.fieldOfValue" in the X3D
> spec.
>
> At no point do I claim that my own software is bug-free, and all
> bugreports are welcome.
>
> Regards,
> Michalis
>
> pt., 25 lip 2025 o 13:00 John Carlson <yottzumm at gmail.com> napisał(a):
> >
> > Nice of you to say, Michalis. Further emails suggest:
> >
> > 1. X3dToJava.xslt is producing 4 distinct parameters. There should
> only be one array with 4 values.
> >
> > 2. X3DJSAIL is not producing OrthoViewpoint.fieldOfValue for the
> MFFloat, based on passing the result (a double[] array)of this Java code:
> >
> > private class MFFloat3 {
> > private org.web3d.x3d.jsail.fields.MFFloat getArray() {
> > return new org.web3d.x3d.jsail.fields.MFFloat(new double[]
> {0f,0f,10f,10f});
> > }
> > }
> >
> > 3. There is a distinct possibility that Sunrize doesn't handle
> OrthoViewpoint.fieldOfView properly...so let's try Castle Model Viewer:
> >
> > $
> ~/Downloads/castle-model-viewer-5.3.0-win64-x86_64/castle-model-viewer/castle-model-viewer.exe
> Connectors.x3d
> > Segmentation fault
> >
> > Maybe mend your own ship? I try to mend mine, but stumble on to other
> problems.
> >
> > Here's the original: Playground | X_ITE X3D Browser
> >
> > Thanks!
> >
> > John
> >
> > On Fri, Jul 25, 2025 at 5:46 AM Michalis Kamburelis <
> michalis.kambi at gmail.com> wrote:
> >>
> >> Re-reading that old thread, from the emails you cite: I don't think
> >> anything was forgotten.
> >>
> >> In short: the resolution was to not change anything in
> >> OrthoViewpoint.fieldOfView. It remains MFFloat. And that's what it is
> >> in 4.1, see
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/navigation.html#OrthoViewpoint
> >> .
> >>
> >> See last answer from Don and the one before it from me, in the thread.
> >> And I still think our conclusion was correct.
> >>
> >> - The changes that have been considered were all, in one way or
> >> another, causing some issues. E.g. "just change it to SFVec4f" was
> >> breaking compatibility for X3D content with classic encoding.
> >> "Changing X3D classic parser rules", to adjust for this one change to
> >> one field in one node... would be also unoptimal IMHO, that would mean
> >> escalating a small local need -> to significant change.
> >> - All in all, "not doing anything" and "just living with the fact that
> >> OrthoViewpoint.fieldOfView would be nicer as SFVec4f vector, but long
> >> time ago someone defined it as MFFloat and models already use it" is
> >> just simpler.
> >> - The constructive result from that discussion were that we have
> >> improved X3D classic encoding spec, so that prose clearly reflects
> >> when [ ] are used and when not. (And this reflects the grammar and the
> >> implemented browser's behavior).
> >>
> >> Regards.
> >> Michalis
> >>
> >> pt., 25 lip 2025 o 11:39 John Carlson <yottzumm at gmail.com> napisał(a):
> >> >
> >> > 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
> >> >> >
> >> >> > 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
> >> >> > > >
> >> >> > > >
> >> >> > > > 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://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
> >> >> > > >> 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
> >> >> > > >>
> >> >> > > >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250725/a9054d98/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Connectors.new.javaPrettyPrint.intermediate.x3d
Type: model/x3d+xml
Size: 14324 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250725/a9054d98/attachment-0001.x3d>
More information about the x3d-public
mailing list