[x3d-public] Recall--Re: X3D 4.0 specification problem: OrthoViewpoint.fieldOfView
John Carlson
yottzumm at gmail.com
Fri Jul 25 08:03:14 PDT 2025
Thanks for the feedback!
On Fri, Jul 25, 2025 at 9:24 AM John Carlson via x3d-public <
x3d-public at web3d.org> wrote:
> 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
>>
> _______________________________________________
> 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/5b54f285/attachment-0001.html>
More information about the x3d-public
mailing list