[x3d-public] X3D working group minutes 21 JAN 2022: Mantis issue resolutions for Text layout and glTF, IMPORT/EXPORT, Projects Wish List, Blender
GPU Group
gpugroup at gmail.com
Fri Jan 21 15:41:19 PST 2022
"Question: does FreeWRL or Coin3D (both open source codebases) have any
C/C++ that can be compared to SAI?"
FreeWRL VRML/X3D browser / Git / [61235b] /freex3d/src/SAI_Cpp
(sourceforge.net)
<https://sourceforge.net/p/freewrl/git/ci/develop/tree/freex3d/src/SAI_Cpp/>
- No, appears to be just the .h headers, but without any .cpp and nothing
executable - perhaps never used.
- we did use a C interface for EAI FreeWRL VRML/X3D browser / Git /
[61235b] /freex3d/src/libeai (sourceforge.net)
<https://sourceforge.net/p/freewrl/git/ci/develop/tree/freex3d/src/libeai/>
which
included a swiggable interface for python, and a Java EAI;
FreeWRL VRML/X3D browser / Git / [61235b] /freex3d/src/java
(sourceforge.net)
<https://sourceforge.net/p/freewrl/git/ci/develop/tree/freex3d/src/java/>
- all that's for EAI and the one accessed from Script nodes in javascript
is different / unrelated code.
"Are they similar or different to Korea codebase?
I haven't seen the Korea codebase. Is it opensource, is there a link?
Is there somebody out in those arenas interested in participating?"
Freewrl has been quiet for over a year. I think it's EOL end of life. I
have a wish list but other projects ahead, and other pathways.
One idea for fun is to convert freewrl to C++. I started to do that 12
years ago, got it to build ugly -just C compiled as cpp-, but no consensus
to adopt. It would need to be a fork so C version preserved.
-Doug Sanden
On Fri, Jan 21, 2022 at 10:31 AM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:
> Attendees: John Carlson, Vince Marchetti, Nicholas Polys, Dick Puk, Don
> Brutzman. Regrets Anita Havele.
>
>
>
> Noted spiffy update to Web3D Consortium home page layout – thanks Anita.
>
>
>
> - https://www.web3D.org
>
>
>
>
>
> 1. *X3D Programming Language bindings for C++/C*#. Regarding C++/C#,
> we discussed how:
>
>
> 1. No C for now.
> 2. Draft documents are on github but really need review as sensible,
> do-able in code (repeatable), ready for direct editing updates.
> 3. Initial testing of Korea codebase on representative X3D example
> scenes. Resolution of license status would be helpful too.
> 4. Confirm compatibility with .net approaches, include minimal
> informative annex on .net (but only if necessary).
> 5. Once at that threshold of interface maturity, we might autogenerate
> a second implementation via X3DUOM.
> 6. Any later additions to X3D4 Architecture 19775-1 or abstract Scene
> Access Interface (SAI) 19775-2 are easily reconciled later.
> 7. We need an editor still.
>
>
>
> Question: does FreeWRL or Coin3D (both open source codebases) have any
> C/C++ that can be compared to SAI? Are they similar or different to Korea
> codebase? Is there somebody out in those arenas interested in
> participating?
>
>
>
>
>
> 1. *Mantis issues for X3D Architecture Specification review*. With
> today’s meeting, 255 issues are now down to 175 open issues with no MAJOR
> issues remaining.
>
>
>
> 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
>
> Our assessment is this is nearly complete, *EnvironmentLight* needs to be
> confirmed stable*, we can reduce this from major *(no blockers) and
> confirm we are on endgame. Since Khronos has formally submitted glTF as
> Publicly Available Specification (PAS) to ISO, we should be able to confirm
> that we are fully aligned. Michalis please meet with Dick and Don to sort
> out Mantis status.
>
>
>
> 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
>
>
>
> Vince posted a test scene and example screenshots. Summary of status can
> be found on email thread. Apparently 4 players have solved the identified
> problem satisfactorily.
>
> http://web3d.org/pipermail/x3d-public_web3d.org/2022-January/016561.html
>
> Dick reported how extremely thorough design was the basis of our
> internationalized text model in the X3D Architecture. We should remain
> reluctant to change it. The goal is not "pixel perfect" presentation but
> rather satisfactory presentation.
>
> Nicholas (who has world-class expertise on this topic, see his
> dissertation) also thinks our basic model is satisfactory. We have many
> examples but maybe have not identified or consolidated on a smaller set of
> examples that illustrate what we need.
>
> We are *reducing severity from MAJOR to MINOR*. Issue 1265 ownership
> remains assigned to Nicholas.
>
>
>
>
>
> 3. *Projects Wish List*. https://www.web3d.org/projects/wish-list
>
>
>
> 1. Add View3Dscene to section 1 to note available as open source,
> fully implementing glTF.
> 2. Does X3DOM support ROUTE? Yes. Prototypes? Maybe – interesting
> recent examples posted. X3D Scripts? No. Hoping Andreas might provide
> succinct status and where help is useful, we will then discuss further on
> x3dom-developers list.
> 3. Crucial issue common to X3DOM, X_ITE, view3DScene: plans for
> supporting WebXR? This should be elevated as #1 wish list on client side.
> 4. Tool side: Blender is our top issue. Is a concerted team effort
> appropriate (or possible)? Perhaps on an issue-by-issue basis? The latest
> Blender 3.0 import/export has shown good progress is now stable from an X3D
> perspective (thanks to a fix by Andreas) so working on individual
> improvements is feasible. One is underway on ImageTexture that is revealing
> additional bugs… so maybe just encouragement of individuals to solve
> problems is what we need. We can also elevate how we report progress
> publicly in order to build confidence. Web3D Consortium members who have
> stakeholder interest in ought to discuss this closely. Can Blender
> Foundation, or some set of coders associated with that group working for
> money, help? How can we get money flowing to professional Blender
> programmers here?
> 5. Our Blender project:
> https://github.com/Web3DConsortium/BlenderX3DSupport
> 6. Tool side: MeshLab. Next week please, if CRNI can attend that will
> be great.
> 7. Don will continue to edit and update the page. This wish list will
> continue to get reviewed every week.
>
>
>
> John asked a question about protos continue on mailing list please.
> Please look around, a great many prototype examples are online, some with
> an explanatory book chapter. Also available is a very thorough X3D
> Validator.
>
>
>
>
>
> Next week. We will continue our tools focus with MeshLab. All ideas and
> inputs welcome.
>
>
>
> - https://www.meshlab.net
>
>
>
> Step by step... Quote from Thanos in movie *Avengers Endgame*:
> “Inevitable.”
>
>
>
> Have fun with X3D! 8)
>
>
>
> 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)
> *Sent:* Thursday, January 20, 2022 4:18 PM
> *To:* X3D Public Mailing List (x3d-public at web3d.org) <x3d-public at web3d.org
> >
> *Cc:* brutzman at nps.edu
> *Subject:* X3D working group agenda 21 JAN 2022: progress, Mantis issue
> resolution, Projects Wish List, IMPORT/EXPORT
>
>
>
> 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/20220121/d065c8e8/attachment-0001.html>
More information about the x3d-public
mailing list