[x3d-public] X3D Working Group meeting 23 SEP 2022: Mantis issues review, SvgTexture
Brutzman, Donald (Don) (CIV)
brutzman at nps.edu
Thu Sep 29 10:41:01 PDT 2022
Thanks for considering this. I certainly share your desire for accuracy.
Please note the phrasing does not claim the two specifications are
identical, rather that X3D rendering supports expressive power that matches
(or exceeds). Sure some parts might be harder than others, but there is a
path to render a glTF model and a rewritten version in X3D4.
Suggested rationales:
1. If compressed meshes found in glTF are desired, load the glTF/glb model.
If something similar is desired natively, perform preprocessing or use an
X3D extension (as you indicated).
2.1. Tangent vectors are normal to a surface. X3D has a Normal node, so an
advanced authoring can likely match such functionality.
2.2. X3D has ColorInterpolator and ScalarInterpolator (for transparency)
provide a similar (often identically renderable) approach.
2.3. Agreed not identically described (or mathematically pure/perfect) but
linear interpolation can be applied at arbitarily detailed refinement, so
equivalent fidelit again possible.
2.4. Mesh interpolation has been around a long time in VRML/X3D (remember
the duck?!) and again the mechanisms available provide a path for similar
(or identical) rendering.
Putting identical data structures into a GPU or a scene graph is not a desig
Worth noting that the differences which remain are highly specialized and
quite miniscule compared to everything else that has been achieved (again
thanks Michalis).
So we still agree that they are different. I still think that equivalent
expressive power is available when loading, and highly similar (perhaps
imperceptibly different) expressive power is possible when re-expressing a
model natively in X3D.
Does this improvement help:
* "X3D 4.0 provides full support for inline loading or properly rendering
glTF 2.0 models."
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
-----Original Message-----
From: Michalis Kamburelis <michalis.kambi at gmail.com>
Sent: Thursday, September 29, 2022 6:04 AM
To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
Cc: X3D Public Mailing List (x3d-public at web3d.org) <x3d-public at web3d.org>
Subject: Re: [x3d-public] X3D Working Group meeting 23 SEP 2022: Mantis
issues review, SvgTexture
We cannot represent 100% of glTF 2.0 features as X3D nodes. We're not there
(yet).
So the statement "X3D 4.0 provides full support for inline loading or
directly representing glTF 2.0 models." sounds too strong IMHO. At least for
me, the words "full" and "directly representing" above would suggest that we
can express 100% glTF features in X3D, which we can't.
We achieved progress in X3D 4.0 (we have PBR which is compatible with glTF).
But we still have various missing things:
1. Compressed geometry from glTF -- it can loaded, but it has to become
decompressed in the process. (like CGE) Or the browser has to load glTF
meshes without converting them to X3D meshes. (like FreeWRL) Or browser has
to use browser-specific extensions (like X3DOM).
We don't yet have the "ideal solution" - X3D nodes for mesh data that
can be uploaded to GPU directly. Document
https://www.web3d.org/specifications/FeaturesComparisonX3D4glTF2.pdf
also states it --- we added together on one call valid statement "X3D native
nodes directly corresponding to glTF compressed geometry not supported, but
Inline loading of glb models is supported."
2. Various other things I mentioned in
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com
%2Fmichaliskambi%2Fx3d-tests%2Fwiki%2FConverting-glTF-to-X3D&data=05%7C0
1%7Cbrutzman%40nps.edu%7C214bce7f57c744cea20108daa21b3918%7C6d936231a51740ea
9199f7578963378e%7C0%7C0%7C638000535056951920%7CUnknown%7CTWFpbGZsb3d8eyJWIj
oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
&sdata=YGi8pgvXs835blVrvXf7C4j0VkjCRzGaKdxx1Tg%2BWr8%3D&reserved=0
. Some have extensions in CGE, for some -- we don't yet have a ready
solution:
2.1. Tangent node (extension in CGE ,
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcastle-eng
ine.io%2Fx3d_implementation_rendering_extensions.php%23section_Explicit_tang
ent_vectors&data=05%7C01%7Cbrutzman%40nps.edu%7C214bce7f57c744cea20108da
a21b3918%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638000535056951920%7CU
nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
XVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jzUPnJYg85BHRuxZI%2B7qUyzdXZfLyQLnZkA4
a559AJU%3D&reserved=0
)
2.2. Modulate mode for Color/ColorRGBA (
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com
%2Fmichaliskambi%2Fx3d-tests%2Fwiki%2FConverting-glTF-to-X3D%23per-vertex-co
lors&data=05%7C01%7Cbrutzman%40nps.edu%7C214bce7f57c744cea20108daa21b391
8%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638000535056951920%7CUnknown%
7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
0%3D%7C3000%7C%7C%7C&sdata=HUBrENpNVKnGKIze58mMZI0QDKLKiSXTsqjh9OCZvf4%3
D&reserved=0
,
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcastle-eng
ine.io%2Fx3d_implementation_rendering_extensions.php%23section_ext_color_mod
e&data=05%7C01%7Cbrutzman%40nps.edu%7C214bce7f57c744cea20108daa21b3918%7
C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638000535056951920%7CUnknown%7CT
WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
D%7C3000%7C%7C%7C&sdata=IPzQUTxh6s2sRD%2BbQX%2BGgQ7g0TjrxBzMrgp9loahNHg%
3D&reserved=0
)
2.3. glTF CubicSpline and Step interpolation. CubicSpline can be
approximated in X3D by converting to Linear with more points (e.g.
10x), Step can be performed by converting to Linear with 2x points (CGE has
extension to do "Step" explicitly). But that's not perfect.
2.4. Skinned mesh animation. We all agreed that glTF skinned mesh animation
can be probably expressed as X3D H-Anim nodes, but so far nobody (from what
I know) actually figured out how to do this conversion (not to mention --
conversion that preserves the efficiency, and allows to play glTF skinned
animation on GPU without calculating anything extra on browser). CGE is just
playing glTF skinned mesh animation without the help of H-Anim nodes. Last I
heard, Andreas was working on it in X3DOM, but wrote it is unfinished.
Regards,
Michalis
czw., 29 wrz 2022 o 13:00 Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
napisał(a):
>
> I added a summary statement (quoted below) and made a few formatting
improvements.
>
>
>
> Features Comparison X3D4 glTF2 (.pdf) spreadsheet shows complete
interoperability with glTF rendering.
> https://www.web3d.org/specifications/FeaturesComparisonX3D4glTF2.pdf
> https://www.web3d.org/specifications/FeaturesComparisonX3D4glTF2.xlsx
> "X3D 4.0 provides full support for inline loading or directly representing
glTF 2.0 models."
>
>
>
> As ever, all review comments and questions welcome. 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) <brutzman at nps.edu>
> Sent: Saturday, September 24, 2022 7:55 AM
> To: John Carlson <yottzumm at gmail.com>
> Cc: X3D Public Mailing List (x3d-public at web3d.org)
> <x3d-public at web3d.org>; Brutzman, Donald (Don) (CIV)
> <brutzman at nps.edu>
> Subject: RE: [x3d-public] X3D Working Group meeting 23 SEP 2022:
> Mantis issues review, SvgTexture
>
>
>
> John, there is a bit more in the issue and the references.
>
>
>
> SVG produces animatable interactive 2D images through vector graphics. So
it has characteristics of both ImageTexture and MovieTexture (and
interpolators and scriptable event models).
>
>
>
> Dick's point yesterday was that implementing such a combination is
different and bigger than ImageTexture or MovieTexture. The ways that an
author might use an SVG model are similar, but when you think of how a
browser might do it and then add computation, user interaction, security,
etc. etc. then the design perspective is quite different. This leads us to
the tried-and-true approach of implementing and testing further, most likely
as a new node.
>
>
>
> So I think that is an interesting and important justification that he
made. We offer it back to the group for review and discussion - thanks for
your points.
>
>
>
> 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: John Carlson <yottzumm at gmail.com>
> Sent: Friday, September 23, 2022 5:33 PM
> To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> Cc: X3D Public Mailing List (x3d-public at web3d.org)
> <x3d-public at web3d.org>
> Subject: Re: [x3d-public] X3D Working Group meeting 23 SEP 2022:
> Mantis issues review, ballot deadlines, X3D Application Stack Layer
> Examples diagram
>
>
>
> Recommendation: SvgTexture should be a single frame MovieTexture for now,
with possible extensions to animation with ROUTEs and ECMAscript, if
animation is enabled on SvgTexture node. I don't know if MovieTexture
enables/disables animation, but my guess is, yes.
>
>
>
> Disabling/enabling animation of SVGs should be in more inclusive profiles.
>
>
>
> Is that simple enough?
>
>
>
> On Fri, Sep 23, 2022 at 7:23 PM John Carlson <yottzumm at gmail.com> wrote:
>
> Consider: SVG is a manipulation language for inserting 2D graphics into
a scene. Definition languages are more closely related to schemas, or
possibly for manipulating schema. After insertion into a scene, ECMAscript
is typically used for manipulation. ROUTEs should be allowed to as well.
>
> SVGs should be considered animations with popular packages being D3.js.
>
>
>
> Otherwise, SVG is a declarative language, similar to X3D and HTML. Last
I heard, there was no official schema for SVG.
>
>
>
> If the SVG is animated by ECMAscript, wouldn't it more properly be used to
texture surfaces and volumes with a MovieTexture? Are MovieTextures 2D or
3D? What textures are used for VolumeRendering?
>
>
>
> On Fri, Sep 23, 2022 at 1:44 PM Brutzman, Donald (Don) (CIV)
<brutzman at nps.edu> wrote:
>
> Attendees: Dick Puk, Don Brutzman
>
>
>
>
>
> 1. We first reviewed the two recently posted Mantis issues regarding SVG
and QIF. We also looked at a Mantis issue posted earlier this year relating
to scalable composition of really large X3D worlds. Selected details
follow.
>
>
>
> Mantis 1400: add Scalable Vector Graphics (SVG) to recommended image
> formats for ImageTexture
>
> https://www.web3d.org/member-only/mantis/view.php?id=1400
>
>
>
> SVG references:
>
> *
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> w3.org%2FGraphics%2FSVG&data=05%7C01%7Cbrutzman%40nps.edu%7C214bce
> 7f57c744cea20108daa21b3918%7C6d936231a51740ea9199f7578963378e%7C0%7C0%
> 7C638000535056951920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pD
> FFq%2FDML5AyXQdsQhE0i1dbFz8SRt2FNvhcYv58Fo8%3D&reserved=0
> * "SVG is a markup language for describing two-dimensional graphics
applications and images, and a set of related graphics script interfaces."
>
> Dick estimation: thinks SVG is a 2D scene-graph definition language. It
can result as an image, though so can X3D.
>
> This issue suggests that SVG be listed as a recommended (optional) format
that can be rendered as an ImageTexture, using the default presentation
settings of the SVG model.
>
> Of note is that browsers are not forbidden from implementing SVG as an
ImageTexture format, and also that SVG-to-PNG converters are commonplace.
>
> Of further note is that the DPS minutes already showed a use case for SVG
as ImageTexture, namely conversion of metadata information as a carefully
laid-out annotation image that is billboarded in context. Having direct SVG
rendering would eliminate the offscreen conversion step, permitting direct
integration of X3D models with other HTML/SVG web graphics.
>
> Concern: don't want to overcomplicate the existing ImageTexture
functionality as a 2D array of pixels. Once generation of pixels becomes a
computational process, this is different functionality for the ImageTexture
node. This might raise further concerns about impact of ImageTexture
computational complexity in various profiles (such as Interchange Profile).
>
> Possible alternate: define SvgTexture node? What fields would it have?
>
> Suggested possible resolution:
>
> a. Browsers are welcome to implement ImageTexture as an allowed url
> format if they see fit, b. SvgTexture ought to be designed and
> considered as a possible new node, c. ComposedImageTexture (or
> somesuch) might be designed and considered as an even-more general
possibility for comuputational 2D imagery, d. Following further practical
experience, defer any specification-change recommendations to future X3D4.1.
>
>
>
>
>
> Mantis 1401: aligning X3D4 LineProperties with Quality Information
> Framework (QIF) specification
>
> https://www.web3d.org/member-only/mantis/view.php?id=1401
>
>
>
> Suggested resolution:
>
> a. The concepts are directly aligned and overlapping, with some additions
by QIF.
> b. This ISO standard does not appear to have been considered by SC24 or
JTC1.
> c. Close scrutiny of both terms and definitions needs to be performed
before any changes might be recommended.
> d. If changes are indeed warranted and acceptable, then they likely need
to first considered as part of the Registry of Items, specifically entries
for linestyle and hatchstyle.
> e. At that point, amendment of X3D to stay aligned with Registry of Items
(or possibly add further styles independently) can be considered.
> f. Defer to X3D 4.1.
>
> Meanwhile note in Web3D current ballot comments the need to fix the table
erratum previously noted.
>
>
>
>
>
> Mantis 1192: 07.2.2 Bindable children nodes - Undefined results if
> bindable node is under Switch or LOD is problematic
>
> https://www.web3d.org/member-only/mantis/view.php?id=1192#bugnotes
>
>
>
> Comment on 19775-1: Abstract X3D Definitions - V3.3
> 7.2.2 Bindable children nodes
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/comp
> onents/core.html#BindableChildrenNodes
>
> -----------------
> Subject: Undefined results if bindable node is under Switch or LOD is
> problematic
>
> Spec sayeth:
> "The results are undefined if a bindable node is bound and is the child of
an LOD, Switch, or any node or prototype that disables its children."
>
> This leads to all manner of inconsistent problems among scenes. It also
means that Inline node (which may or may not include bindable nodes) has
undefined behavior under LOD/Switch/etc.
>
> As a result, in addition to indeterminate X3D browser behavior, it means
that X3D scenes are not fully composable. That is contrary to X3D design
objectives.
>
> Different prose and deterministic guidelines is needed in this section
that provides clear rules for binding/unbinding nodes when they become
active within LOD/Switch/etc. Small adaptations to current binding rules can
likely address this problem satisfactorily.
>
> Related: Mantis issue 749
>
>
>
> April 29:
>
> Analysis during X3D Working Group call:
>
> a. Switch would keep each binding stack aligned with whichever child was
active, thereby binding and unbinding nodes whenever the Switch level is
modified.
>
> b. LOD would have all of its child bindable nodes on the binding stack
throughout, so that user experience was consistent. For example, it would
make no sense for Viewpoints to get arbitrarily unbound and bound, based on
range to viewer, as a user independently navigated through a scene.
>
> c. LOD attempting to maintain author intent has access to all Viewpoint
nodes on binding stack, and range-to-viewer LOD transitions are either
flexible suggestions (browser-optimization control) or rigidly enforced
(forceTransitions field is TRUE). Thus if a node is subsequently bound by
user in a different inactive LOD child branch, then that binding event is
honored and that LOD child branch becomes the active child branch. This
binding event (and changed LOD child branch selection) takes precedence over
browser range/performance considerations, and also takes precedence over
whatever value is provided in forceTransitions field. (Example: selecting a
room Viewpoint while in a large building model).
>
> d. NavigationInfo, Background and Fog binding stacks and responses to
binding events should behave identically to Viewpoint. Variations would be
exceedingly complex and not understandable. Consistency means that author
intent and user action always take precedence, for Switch and LOD response.
>
> Spec editors work on integrating these principles as specification prose
(we are close already) and report back recommended changes to X3D working
group.
>
> Don's opinion: this will significantly help user-sensible scalability of
huge (perhaps Metaverse-scale) models using many Inline and prototype nodes,
enabling predictable and performant navigation and traversal throughout.
>
>
>
> Today's session.
>
>
>
> Alternatives deserving working-review consensus:
>
> a. Recommending this clarification of undefined prior specification prose
might add important value, or might be construed as a technical change to
X3D4.0 that possibly requires future re-balloting as another X3D 4.0 DIS
(which is not an acceptable outcome).
>
> b. If not balloted then this becomes an X3D4.1 issue.
>
> c. Web3D might consider some alternative approach to strongly encourage
adoption of this clarified approach in order to further encourage greater
scalability of multi-world environments, and better alignment with shared
Metaverse design imperatives. For example, are we creating a Best Practices
Pending X3D 4.1 Approval document of some sort?
>
>
>
>
>
>
>
> 2. We only have 4 total issues to review as planned Web3D comments. This
will occur during a single working-group meeting, 7 OCT.
>
>
>
> Deadline for X3D Ballot comments:
>
> OCT, Web3D comments to INCITS (U.S. National Standards Body TBD OCT,
> INCITS comments to SC24
> 4 NOV, SC24 comments to ISO
>
>
>
> No meeting currently planned for 30 SEP.
>
>
>
> 3. Bonus round: we worked on the "layer" diagram from recent meetings a
bit more. Latest X3dApplicationStackLayerExamples is attached, all comments
welcome.
>
>
>
> Have fun with 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
>
>
>
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5353 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220929/dac31ba3/attachment-0001.p7s>
More information about the x3d-public
mailing list