[x3d-public] X3D working group agenda 21 JAN 2022: progress, Mantis issue resolution, Projects Wish List, IMPORT/EXPORT
John Carlson
yottzumm at gmail.com
Thu Jan 20 17:18:41 PST 2022
Don, I can offer my C/C++ SAI binding programs and serializers. Now that
I’m on windows, I might also offer c#, but I’m a C# newbie. I don’t know
what the state most of this is in, I think I started working on compiling
apps and maybe ran into a blocker. I believe Roy can offer an
implementation of SAI bindings for c++? Not sure.
If you could point me at current interface headers, that would be great.
No, not an HTML file.
As you know, I probably already have enough trouble communicating. I would
probably not make the best editor. I suggest someone who’s actually
implemented SAI.
I will be glad to generate testing programs for C/C#C++. Is there some
measure of completeness or code coverage? Would a version of the Java
HelloWorldProgram.java program translated to the C languages be
sufficient? That is, I would take Java, export JSON then load JSON in
JavaScript and export HelloWorldProgramOutput.c,.cpp
Here are my current links:
https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/CSerializer.js
https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/CppSerializer.js
These work with my load JSON, convert to a DOM tree, then call export
serializers.
See:
https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/json2all.js
I already have lots of programs currently generated, but probably not any
compiled or linked. These are under src/main/c/net/coderextreme/data/
and src/main/cplusplus/net/coderextreme/data/
(yes, I know they aren’t data—just something historical based on where the
JSON is in src/main/data)
So a good step would be to get compilable header files to work with.
My wife says a week’s volunteering would be ok.
I do not know if SAI validation or encoding exporting is specified yet for
the C languages?
I could use a standby expert in compiling the C languages on Windows ???
John
On Thu, Jan 20, 2022 at 6:19 PM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:
> The X3D Working Group meets each Friday at 0800-0900 pacific time.
> Videoconference Connectivity:
>
>
>
> -
> https://us02web.zoom.us/j/81634670698?pwd=a1VPeU5tN01rc21Oa3hScUlHK0Rxdz09
> - https://zoom.us/j/148206572 Password 483805
> - https://www.web3d.org/member/teleconference-information
>
>
>
> All inputs welcome. Agenda follows.
>
>
>
> 1. Anyone have new project progress to report (with image to share)
> this week? Outreach is welcome.
>
>
>
> 1. Excellent visibility of meeting minutes and other progress on
> Twitter, we will continue.
> - https://twitter.com/Web3Dconsortium
>
>
>
> 1. Dick and I are spec editors steadily fixing issues but making
> progress too slowly. We request review.
> - We started with 250 issues a year ago, we are down to 175. Four
> months to go…
> - The hardest issues are addressed. Only 2 “major” issues remain.
> - Issue list attached. Please identify any topic priorities you
> have.
> - Help requested. Special opportunity: editing first-draft spec
> and implementation testing of X3D C++ C# bindings.
> - We will keep going but finishing is not yet in reach… Will we be
> punting open issues to future X3D4.1 ?
>
>
>
> Request review of major issue by Nicholas:
>
> - Mantis 1265: Text size clarification, relative to baseline
> - https://www.web3d.org/member-only/mantis/view.php?id=1265
>
>
>
> Request review of major omnibus issue by Michalis:
>
> - Mantis 1269 glTF physically based rendering PBR, advanced material
> textures and lighting
> - https://www.web3d.org/member-only/mantis/view.php?id=1269
>
>
>
> 1. Projects Wish List update discussion: we will look closely again
> next week.
> - Work with MeshLab and Blender seems especially important.
> - Can we add “how to get involved?” to each major item.
> - https://www.web3d.org/projects/wish-list
>
>
>
> 1. Dick and I worked on IMPORT/EXPORT issue today, to good effect
> - Mantis 1109: 04.4.6 Import/Export semantics - Need to specify
> uniqueness of names
> - https://www.web3d.org/member-only/mantis/view.php?id=1109
>
>
>
> - X3D4 Architecture, Networking component, 9.2.5 IMPORT statement
> -
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/networking.html#IMPORTStatement
> - X3D4 Architecture, Networking component, 9.2.6 IMPORT statement
> -
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/networking.html#EXPORTStatement
>
>
>
> 1. What else?
>
>
>
>
>
> Membership definitely has value, including visibility into Mantis issue
> list. Hope you consider the possibilities.
>
> - Join Web3D Consortium
> - https://www.web3D.org/join
>
>
>
> Have fun with X3D! 8)
>
>
> 9.2.5 IMPORT statement
>
> The IMPORT statement is used within an X3D file to specify nodes, which
> are defined within Inline files or programmatically created content, that
> are to be brought into the namespace of the containing file for the
> purposes of event routing. Once a node is imported, events may be sent to
> its fields via ROUTEs, or routed from any fields of the node which have
> output events.
>
> IMPORT statements may appear anywhere in the file and have the following
> form:
>
> IMPORT <InlineNodeName>*.*<ExportedNameFromInlinedFile> [ AS
> <NewLocalNodeName> ]
>
> The IMPORT statement has the following components:
>
> 1. The name of the Inline node that contains the node to be imported
> 2. The name of the node to import
> 3. An optional name to be that is used as an alias for the imported
> node within the run-time name scope, to help prevent name clashes within
> the parent scene containing the IMPORT statement.
>
> The IMPORT statement has the following semantics:
>
> 1. Once imported, events may be routed to or from the imported node in
> exactly the same manner as any node defined with DEF.
> 2. Nodes imported into an X3D scene using the IMPORT statement may not
> be instanced via the USE statement.
> 3. Only nodes that are exported from within the Inline via an EXPORT
> statement may be imported using a corresponding IMPORT statement.
> 4. The IMPORT statement can appear wherever a ROUTE statement is
> allowed, and shall follow the Inline node to which it refers.
>
> The following example illustrates the use of the IMPORT statement (Classic
> VRML encoding syntax):
>
> *DEF I1 Inline {*
>
> * url "someurl.x3d"*
>
> *}*
>
> * . . .*
>
>
>
> *IMPORT I1.rootTransform AS I1Root*
>
> *DEF PI PositionInterpolator { ... }*
>
> *ROUTE PI.value_changed TO I1Root.set_translation*
>
> In the above example, rootTransform is defined as a Transform node in the
> file someurl.x3d and exported via an EXPORT statement (see 4.4.6.3 EXPORT
> semantics
> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/concepts.html#EXPORTSemantics>).
> The optional AS keyword defines an alias for rootTransform so that within
> the containing scene the node is referenced using the DEF name I1Root. All
> defined alias AS names shall also meet appropriate uniqueness requirements
> in the local DEF namespace of the parent scene.
> 9.2.6 EXPORT statement
>
> The EXPORT statement is used within an X3D file to specify nodes that may
> be imported into other scenes when Inlining that file. Only named nodes
> exported with an EXPORT statement are eligible to be imported into another
> file.
>
> EXPORT statements may appear anywhere in the file and have the following
> form:
>
> EXPORT <NodeName> [ AS <ExportedNodeName> ]
>
> The EXPORT statement has the following components:
>
> 1. The DEF name of the node to be exported
> 2. An optional name to be that is used as an alias for the exported
> node when importing it into other files
>
> The EXPORT statement has the following semantics:
>
> 1. Once imported into a containing scene, events may be routed to or
> from an exported node in exactly the same manner as any node defined with
> DEF.
> 2. Exported nodes imported into a containing scene may not be
> instanced via the USE statement.
> 3. Exportation may not be propagated across multiple files; that is, a
> node imported into one scene using the IMPORT statement may not then be
> further exported into another scene using the EXPORT statement.
> 4. Nodes shall not be exported from the body of a PROTO declaration.
> 5. The EXPORT statement can appear wherever a ROUTE statement is
> allowed, and shall be contained within the Inline node to which it refers.
>
> The following example illustrates the use of the EXPORT statement (Classic
> VRML encoding):
>
> *DEF T1 Transform {*
>
> * ...*
>
> *}*
>
> * . . .*
>
>
>
> *EXPORT T1 AS rootTransform *
>
> In the above example, node T1 is exported for use by other X3D scenes.
> The optional AS keyword defines the exported name of *T1* as
> *rootTransform* ( *i.e.*, other scenes may import the node only using the
> name rootTransform). All defined alias AS names shall also meet
> appropriate uniqueness requirements in the local DEF namespace of the
> parent scene.
>
>
>
> 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
>
>
> _______________________________________________
> 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/20220120/ed3aee25/attachment-0001.html>
More information about the x3d-public
mailing list