[x3d-public] X3D meeting minutes 20 AUG 2021, C C++ C# and Mantis

John Carlson yottzumm at gmail.com
Wed Sep 1 19:39:43 PDT 2021 

Oh, so the .he’s in

https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/languages/c/X3DLib/

Are up-to-date?

Thanks for checking!

John

On Wed, Sep 1, 2021 at 9:30 PM Myeong Won Lee <myeongwonlee at gmail.com>
wrote:

> Dear John,
>
> Concerning getters and setters, the Annex C example sources for C and C++
> include all of them in the header files (abstracts.h and concretes.h are
> also included in the source).
> Because I submitted all of them to Don *in 2019-07-16*, he may have all
> the files.
> Otherwise, please see the link below:
>
> https://drive.google.com/drive/folders/1ccuydK5BTmYJLiI-H9CDxqCSKTj5i_R6?usp=sharing
>
> One thing that I missed is that I should convert the Korean readme to
> English one.
> This will be updated soon, and so please find the readme files in a few
> days.
>
> Concerning C#, we didn't include the header files because C# does not have
> such header files as in C and C++.
> The C# files include classes and functions directly.
>
> Sincerely,
>
> Myeong
>
> On Tue, Aug 31, 2021 at 1:46 PM John Carlson <yottzumm at gmail.com> wrote:
>
>> Agreed on developing setters and getters for patterns previously
>> discussed on the subject.   That is, we have setters provided for
>> construction (import) of an object passed to the constructor.   At that
>> point, the object constructed by should be encapsulated.   Only methods
>> passed an exporter may extract data from the constructed object.
>>
>> But OO may be a bit passé these days?  I don’t know how to achieve such a
>> thing in the C SAI, but I need to look.   I was told by a patterns guy that
>> setters and getters were used for legacy systems???
>>
>> The idea of the importer/exporter pattern is to provide a class hierarchy
>> of importers:  VRMLImporter, XMLImporter, JSONImporter, GenericImporter and
>> similarly, a class hierarchy for Exporters.   While building such classes
>> by hand is numbingly difficult,  I feel with code generation from X3DUOM,
>> the task could be relatively easy.  Again, I have not done something like
>> this in C.
>>
>> Discussion and better solutions appreciated!
>>
>> Examples especially helpful!
>>
>> Yes, I know about JavaBeans and POJOs.
>>
>> I’m all for being overruled.  Show me something the achieves
>> encapsulation better.   I know about accessType on fields.   Is this how we
>> design the encapsulation?
>>
>> The reference I would use for Importer/exporter is “Holub on Patterns.”
>>
>> John
>>
>> On Mon, Aug 30, 2021 at 10:54 PM Brutzman, Donald (Don) (CIV) <
>> brutzman at nps.edu> wrote:
>>
>>> John, thanks for excellent progress.  Apologies that I was unable to
>>> meet today.
>>>
>>>
>>>
>>> I think it is prudent for us to check in the current master copy
>>> provided by Dr. Lee so that we have a baseline.  Any subsequent changes
>>> will be discernible via diff comparisons.
>>>
>>>
>>>
>>> Recommend that we intentionally _*not*_ look at Script nodes for a
>>> while.
>>>
>>>    1. First we have to make sure that basic nodes (parent-children
>>>    relationships) and simple fields are represented satisfactorily, with
>>>    intuitive accessors (get and set methods.
>>>    2. Then look at statements.
>>>    3. Then look at <field> definitions, usable by both prototypes and
>>>    scripts.
>>>    4. Then contained script code within a script node (similarly for
>>>    shader nodes).
>>>    5. Then simple prototype declarations.
>>>    6. Then more-complex prototype declarations with IS/connect and
>>>    embedded Script nodes.
>>>
>>>
>>>
>>> We have plenty of examples to work with.  Going from simplest towards
>>> more complex (a..f above) will help us maintain clarity throughout.
>>>
>>>
>>>
>>> Looking forward to meeting sometime and pursuing next steps.
>>>
>>>
>>>
>>> v/r Don
>>>
>>>
>>>
>>> *From: *John Carlson <yottzumm at gmail.com>
>>> *Sent: *Monday, August 30, 2021 6:31 PM
>>> *To: *Myeong Won Lee <myeongwonlee at gmail.com>; Richard F. Puk
>>> <puk at igraphics.com>
>>> *Cc: *Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; Nicholas Polys
>>> <npolys at vt.edu>; x3d-public at web3d.org
>>> *Subject: *Re: [x3d-public] X3D meeting minutes 20 AUG 2021, C C++ C#
>>> and Mantis MetadataDate
>>>
>>>
>>>
>>> Don suggested a meeting for checking in the new 19777-{3,4,5} working
>>> drafts.   If people are interested, send me times when you are available.
>>> Dick, Don, since you are the maintainers, one of you should be there—I
>>> think the Mantis currently says Don.   Myeong or I can make zips available.
>>>   I think they may be checked into my repository.
>>>
>>>
>>>
>>> I do not know if more review time is necessary before checking in?   I
>>> for one have not done much reviewing beyond structure.   One may want to
>>> search through the folders to see if the string “Java” is found within the
>>> c/c++/c# working draft files.   That is, do an explorer and/or grep search.
>>>
>>>
>>>
>>> From what I saw of the .h files, it looks quite excellent.   We can
>>> start with any code generation.   If Myeong doesn’t give us the .h files
>>> and we can’t otherwise scrape the HTML or WD, perhaps code generation of
>>> SAI from X3DUOM is indicated?   We have done this for Python and Java.   I
>>> don’t know if Myeong is code generating the .h code or not.  I’ve laid out
>>> a couple of scenarios for stylesheets, but I have not worked on making
>>> these a reality yet. It would probably be good for me to lay out the
>>> alternatives in a presentation so we can choose a path forward which is
>>> most maintainable for second and third parties.
>>>
>>>
>>>
>>> Nicholas, does your team intend to provide a full library beyond the
>>> interface?   If so, will they be working on an implementation stylesheet?
>>> I guess in C/C++ the interface is separate from the implementation, so it
>>> would be possible to have coordinated implementation?
>>>
>>>
>>>
>>> Could someone who has used Script nodes with c,c++,c# fill me in on how
>>> to do it?
>>>
>>>
>>>
>>> John
>>>
>>>
>>>
>>> On Fri, Aug 27, 2021 at 8:50 AM Myeong Won Lee <myeongwonlee at gmail.com>
>>> wrote:
>>>
>>> Dear John,
>>>
>>> Thank you for your efforts in setting up the GitHub repository.
>>>
>>> In the folders, I think that the "CD" folders may not be necessary
>>> because we have restarted with WDs and the CDs are old versions of the WDs.
>>> I submitted the CDs last year, but they were not approved as CD texts,
>>> and so I resubmitted them as WDs.
>>> We should work on the WD texts.
>>> How about deleting the CD folders?
>>> In addition, if WD-originals are old versions, it would be OK to delete
>>> them.
>>>
>>> In summary, I think that the folders should be as follows:
>>>
>>> ./ISO-IEC19777/ISO-IEC19777-3/ISO-IEC19777-3v3.3-WD
>>> ./ISO-IEC19777/ISO-IEC19777-4/ISO-IEC19777-4v3.3-WD
>>> ./ISO-IEC19777/ISO-IEC19777-5/ISO-IEC19777-5v3.3-WD
>>>
>>>
>>>
>>> Sincerely,
>>>
>>>
>>>
>>> Myeong
>>>
>>>
>>>
>>> On Fri, Aug 27, 2021 at 6:30 AM John Carlson <yottzumm at gmail.com> wrote:
>>>
>>> Myeong,
>>>
>>> Thanks for your efforts on the C/C#/C++ standards!
>>>
>>> My understanding from Don is that we want the current WD versions of the
>>> 19777-3, 19777-4 and 19777-5 standards checked into GitHub, somewhere below
>>> this folder: https://github.com/Web3DConsortium/X3D
>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWeb3DConsortium%2FX3D&data=04%7C01%7Cbrutzman%40nps.edu%7C5c8fa760fe724ed4a28708d96c1ed524%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659702854783384%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FdxJ0uvHzdL0trwWw7PmZjS8gh5hhYQ5hmX0N3ZVGss%3D&reserved=0>
>>> (If you need assistance, let me know, it's quite confusing.  We'll probably
>>> have to do things like rename the folders once unpacked from the zips and
>>> move them from).  Issues with the standards should go into Mantis. Google
>>> Drive/Docs, while important for private sharing, are not suitable for group
>>> editing of standards.   GitHub has adequate protections in the X3D
>>> repository.  With your permission, I will check your Google shared zips
>>> into GitHub unpacked.  Probably in the folders here that you identify:
>>>
>>> ./ISO-IEC19777/ISO-IEC19777-4/ISO-IEC19777-4v3.3/ISO-IEC19777-4v3.3-WD
>>> ./ISO-IEC19777/ISO-IEC19777-4/ISO-IEC19777-4v3.3/ISO-IEC19777-4v3.3-CD
>>> ./ISO-IEC19777/ISO-IEC19777-3/ISO-IEC19777-3v3.3/ISO-IEC19777-3v3.3-CD
>>> ./ISO-IEC19777/ISO-IEC19777-3/ISO-IEC19777-3v3.3/ISO-IEC19777-3v3.3-WD
>>> ./ISO-IEC19777/ISO-IEC19777-5/ISO-IEC19777-5v3.3/ISO-IEC19777-5v3.3-CD
>>> ./ISO-IEC19777/ISO-IEC19777-5/ISO-IEC19777-5v3.3/ISO-IEC19777-5v3.3-WD
>>>
>>> ( Please confirm that the WD folders are correct).
>>>
>>> These are the original folders that where already there that are moved
>>> out of the way.
>>>
>>> ./ISO-IEC19777-4/ISO-IEC19777-4v3.3/ISO-IEC19777-4v3.3-WD-original
>>> ./ISO-IEC19777-3/ISO-IEC19777-3v3.3/ISO-IEC19777-3v3.3-WD-original
>>> ./ISO-IEC19777-5/ISO-IEC19777-5v3.3/ISO-IEC19777-5v3.3-WD-original
>>>
>>> I currently all these changes ready for a git add, commit, push.  I have
>>> done 1) ready and a little bit of aiming.  I need approval to fire.
>>>
>>> I will enter a Mantis ticket for these changes.
>>>
>>> ===========================================================
>>>
>>> Secondly, according to Don, we need to move discussions to the
>>> x3d-public mailing list.  If issues are sensitive, then there's the x3d
>>> mailing list.  Here's how to subscribe to x3d-public:
>>> http://www.web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>>> Issues with source code artifacts should be can be recorded here:
>>> https://sourceforge.net/p/x3d/discussion/
>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fx3d%2Fdiscussion%2F&data=04%7C01%7Cbrutzman%40nps.edu%7C5c8fa760fe724ed4a28708d96c1ed524%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659702854783384%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=a2kbNlGgRnfyzq2vIRTCskJZJ86AIkW4FjlWvGDuh7s%3D&reserved=0>
>>>
>>> Source code artifacts should go here in addition:
>>> https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/languages/
>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fx3d%2Fcode%2FHEAD%2Ftree%2Fwww.web3d.org%2Fx3d%2Flanguages%2F&data=04%7C01%7Cbrutzman%40nps.edu%7C5c8fa760fe724ed4a28708d96c1ed524%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659702854793322%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ia6pbyNz4IS4sNkF5Z0nBhmjoaMTARX6RRfivxzGKdY%3D&reserved=0>
>>> I can facilitate uploads to there.  Myeong, with your permission, I will
>>> archive the old code (many months old) to "legacy" under the main x3d-code
>>> folder.
>>>
>>> If you have any open questions, please post to the x3d-public list
>>> (respond to this email).
>>>
>>> I don't believe source code changes require Mantis.
>>>
>>> John
>>>
>>> On 8/26/21 9:34 AM, Brutzman, Donald (Don) (CIV) wrote:
>>>
>>> Again: it would be useful to have to have a design page that discussed
>>> programming patterns and open issues.
>>>
>>>
>>>
>>> Again: GitHub is master version, being aware that differences exist but
>>> are not identified isn’t very useful.
>>>
>>>
>>>
>>> Again: Hoping we can “get on the good foot” in how this effort is
>>> pursued.  This is how the Java, JSON, Python and Turtle language bindings
>>> built towards consensus and were all successfully accomplished.
>>>
>>>
>>>
>>> Thanks for all efforts, hopefully they can become productive and
>>> fruitful by working deliberately together.
>>>
>>>
>>>
>>> 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
>>> http://faculty.nps.edu/brutzman
>>>
>>>
>>>
>>> *From: *John Carlson <yottzumm at gmail.com>
>>> *Sent: *Friday, August 20, 2021 12:36 PM
>>> *To: *Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>;
>>> x3d-public at web3d.org; Myeong Won Lee <myeongwonlee at gmail.com>; GPU Group
>>> <gpugroup at gmail.com>
>>> *Subject: *Re: [x3d-public] X3D meeting minutes 20 AUG 2021, C C++ C#
>>> and Mantis MetadataDate
>>>
>>>
>>>
>>> NPS WARNING: *external sender* verify before acting.
>>>
>>>
>>>
>>> Don, Myeong, Doug,
>>>
>>> I noticed that there are no virtual methods in the C++ spec SAI I got
>>> (examples, yes, except for ~SAIExample5()) on drive.google.com
>>> <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdrive.google.com%2F&data=04%7C01%7Cbrutzman%40nps.edu%7C5c8fa760fe724ed4a28708d96c1ed524%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659702854793322%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8tYOmA5FuhO9WJVbL6hWoq4FYDLei3F7ow9hWLLMdf0%3D&reserved=0>.
>>> I do not think they are necessary, but may be useful when defining
>>> subclasses for people who want to subclass from the SAI abstract and
>>> concrete nodes.  https://www.geeksforgeeks.org/virtual-function-cpp/
>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.geeksforgeeks.org%2Fvirtual-function-cpp%2F&data=04%7C01%7Cbrutzman%40nps.edu%7C5c8fa760fe724ed4a28708d96c1ed524%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659702854803280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=cMJMC%2FwdzHqgHMa%2BChxhHJFHfqeoG0AXx3mgJdvov6E%3D&reserved=0>
>>> Note that most methods are virtual in Java, without the keyword.  I think
>>> virtual methods are slower than regular methods, last I heard.  But I'm
>>> pretty sure all destructors should be virtual?  I've forgotten. Some
>>> discussion whether destructors should be present in the spec is welcome.
>>> The virtual destructor ensures that the superclass destructor is not called.
>>>
>>> I think it would be useful to have Doug Sanden review the abstract and
>>> concrete class and structs before making big decisions.
>>>
>>> I am also unsure why the first parameter to many C function pointer
>>> declarations is void* instead of passing a pointer to a struct type?
>>>
>>> In all cases, C/C++/C# it might be useful for setter functions and
>>> members to return this or *this, instead of void.   We need set functions
>>> to return this for creating builders I'm fairly sure. (In C SAI, the first
>>> parameter is called this, it's not a keyword that I know of).
>>>
>>> I'm glad I am reviewing this!  We'll see if anything else pops into my
>>> head after I send the message!
>>>
>>> Thanks,
>>>
>>> John
>>>
>>> On 8/20/21 1:46 PM, Brutzman, Donald (Don) (CIV) wrote:
>>>
>>> Attendees John Carlson, Vince Marchetti, Dick Puk, Don Brutzman
>>>
>>>
>>>
>>> 1.       Very useful discussion today, we reviewed proposed language
>>> bindings
>>>
>>>    1. 19755- 3, C
>>>    2. 19755- 4, C++
>>>    3. 19755- 5, C#
>>>
>>>
>>>
>>> We discussed whether special treatment is deserved for exposing these
>>> draft specifications.  22 Web3D members have access to them now.
>>>
>>>
>>>
>>> Language bindings need compilable interfaces for ISO, and at least two
>>> implementations for Web3D.
>>>
>>>
>>>
>>> Close inspection of each shows that a handful of example programs are
>>> available for test development, and could be used as basis for
>>> X3dToCCppCsharp.xslt conversion stylesheet.
>>>
>>>
>>>
>>> Close inspection of detailed abstract interfaces, and detailed
>>> node/statement implementations for libraries are available (with some
>>> omissions).  Each appears quite similar to the others.  Regeneration via
>>> X3DUOM of compilable “header” or interface files matching the source code
>>> in the HTML is possible.
>>>
>>>
>>>
>>> C and C++ language compilation is easily possible using gcc compiler.
>>> Compilation of C# is not so clear, some open-source implementations are
>>> available.  Once initial compilation of headers is accomplished, further
>>> scrutiny and possible evolution of design patterns would be
>>> straightforward.  We’ll use gcc on the next round since it is part of our
>>> build infrastructure already.
>>>
>>>    1. GCC, the GNU Compiler Collection https://gcc.gnu.org
>>>    <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2F&data=04%7C01%7Cbrutzman%40nps.edu%7C5c8fa760fe724ed4a28708d96c1ed524%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659702854803280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=aX4r%2FxVhW3U%2BqomrVVvztrz8zCv9bLLa7cA3ny3Cry0%3D&reserved=0>
>>>    2.
>>>    https://stackoverflow.com/questions/26078437/why-does-gcc-support-java-and-not-c-sharp
>>>    <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F26078437%2Fwhy-does-gcc-support-java-and-not-c-sharp&data=04%7C01%7Cbrutzman%40nps.edu%7C5c8fa760fe724ed4a28708d96c1ed524%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659702854813255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UadYVe93UvlWPFaN9Z4Ez19GcEIZeDcVtCLNpVrtwyk%3D&reserved=0>
>>>
>>>
>>>
>>> We have enough that immediate sharing of shared specifications can be
>>> deferred until broader discussion is warranted.  Sharing of generated code
>>> will help, and that does not have to be restricted.
>>>
>>>
>>>
>>> We are concerned about personnel availability, but will keep working on
>>> it step by step.
>>>
>>>
>>> We will welcome all help and participation as the work proceeds.
>>>
>>>
>>>
>>> 2.       Mantis issue progress is persevering steadily each week.
>>>
>>>
>>>
>>> 1.       Mantis 1218 for creating a MetadataDate or MetadataTime node
>>> needs to be deferred to X3D4.1.  Meanwhile we might an example scene
>>> demonstrating how to do such representations with existing nodes, workably
>>> across all forms of X3D.  E.g. pseudocode examples:
>>>
>>> <MetadataDouble name=”time”                  value=“0.0” reference=”Unix
>>> reference of time with start at 1 JAN 1970”/>
>>>
>>> <MetadataString   name=”TuesdayLunch” value=“24-AUG-2021-1200-pacific”
>>> reference=”XSD, XML Schema Definition”/> <MetadataString
>>>   name=”ThankGoodnessItsMonday” value=“23-AUG-2021-1200-pacific”
>>> reference=”ISO 8601 Time standard”/>
>>>
>>> Any scene of examples would be fully detailed and cross-referenced for
>>> clarity.
>>>
>>> Mantis 1218: 07.2.4 MetadataDate - New node type, or new data type
>>>
>>> https://www.web3d.org/member-only/mantis/view.php?id=1218
>>>
>>>
>>>
>>> 2.       Other mantis issues are being fixed and addresses each week.
>>> Membership has value.
>>>
>>> https://www.web3d.org/member-only/mantis/view_all_bug_page.php
>>>
>>>
>>>
>>> Thanks everyone for a worthy effort today.  Have fun with X3D!  8)
>>>
>>>
>>>
>>> *From:* Brutzman, Donald (Don) (CIV)
>>> *Sent:* Friday, August 20, 2021 12:27 AM
>>> *To:* x3d-public at web3d.org
>>> *Cc:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu> <brutzman at nps.edu>
>>> *Subject:* X3D meeting agenda 20 AUG 2021, C C++ C# and Mantis
>>>
>>>
>>>
>>> Regular weekly call once again this week, Friday 10-1100 Pacific on
>>> Web3D conference line.
>>>
>>>
>>>
>>> We will review our approach to C C++ C# encodings and also ongoing
>>> Mantis progress.  Additional topics welcome.
>>>
>>>
>>>
>>> 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
>>> http://faculty.nps.edu/brutzman
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> x3d-public mailing list
>>>
>>> x3d-public at web3d.org
>>>
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Myeong Won Lee, PhD, Professor
>>> Faculty of Computer Science, U. of Suwon
>>> Hwaseong, Gyeonggi-do, 18323 Korea
>>> E-mail) myeongwonlee at gmail.com, mwlee at suwon.ac.kr
>>>
>>>
>>>
>>
>
> --
>
> Myeong Won Lee, PhD, Professor
> Faculty of Computer Science, U. of Suwon
> Hwaseong, Gyeonggi-do, 18323 Korea
> E-mail) myeongwonlee at gmail.com, mwlee at suwon.ac.kr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210901/8cd71aa5/attachment-0001.html>

More information about the x3d-public mailing list