[x3d-public] X3D Working Group meeting 23 SEP 2022:Mantisissuesreview, SvgTexture

Thu Sep 29 19:53:32 PDT 2022

@Michalis:  i can try it.  Please point me at a comprehensive Blender
.blend file, if you know of a good one.  My primary editing tool is vim,
unfortunately.

I will switch to a non-text editor when i find something reasonably
compelling.   Meanwhile vim and neovim are slowly catching up…

John

On Thu, Sep 29, 2022 at 9:07 PM Michalis Kamburelis <
michalis.kambi at gmail.com> wrote:

> @Joseph
>
> """the already computed ‘joint’ rotation data is shipped in the form of a
> set of keyframe data for each vertex at each frame for a certain number of
> frames at a fixed increment in a form that is ready to send to the hardware
> that computes that vertex location for that frame."""
>
> -- this is really not how glTF skinned animation is stored. glTF doesn't
> store the per-vertex data for each keyframe in a skinned animation. glTF
> stores the information how to animate joints (that is, transformations)
> using keyframes. glTF renderer has to then calculate the actual mesh
> vertexes at each frame it wants to render, knowing which joints and with
> which weight affect this vertex.
>
> Please consult the glTF spec
> https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html or cheat sheet
> https://www.khronos.org/files/gltf20-reference-guide.pdf , they give all
> the information.
>
> @John: I know that Blender glTF exporter and importer are developed
> together, they even share code, to achieve exactly what you describe.
> Everything that exporter produces -> the importer should be able to consume
> back.
>
> But I cannot guarantee and I didn't test whether this goal is achieved
> 100% :) I just personally didn't need to rely on it. In my use-cases, 99%
> of time I only export data from Blender, and don't need to import anything
> to Blender because I author things in Blender.
>
> But what you describe should be possible and I would encourage you to test
> it. If there are differences, you can report them to
> https://github.com/KhronosGroup/glTF-Blender-IO .
>
> Regards,
> Michalis
> On wrz 30 2022, at 3:22 am, Joseph D Williams <joedwil at earthlink.net>
> wrote:
>
>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows
>
>
>
> *From: *Michalis Kamburelis <michalis.kambi at gmail.com>
> *Sent: *Thursday, September 29, 2022 5:39 PM
> *To: *Joseph D Williams <joedwil at earthlink.net>
> *Cc: *Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; 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:Mantisissuesreview, SvgTexture
>
>
>
>    - @Joseph: The joints/transforms in glTF are animated in the same way
>    as
>
> the joints/transforms in X3D. Surely you can (and should) interpolate
>
> them between keyframes.
>
>
>
> Yes, that is why you can use some set of gltf assets to create x3d user
> code for x3d hanim humanoid and animations. The input and output data
> stuffs can be the same, except normal x3d user code stores only the inputs
> not outputs.
>
> And use example x3d hanim user code animations to create gltf assets,
> including the hardware-ready results of the animation routine. There is
> some stuff that cannot be stored in x3d user code and that is the
> frame-by-frame result of the animation operations on each vertex. t
>
>
>
>
>    - I do not get why you say "No interpolation, because no frames between
>
> keys? This limits author when creating animations that use authored
>
> key times with linear interpolation. "
>
>
>
> well, I think if we look at the gltf assets we will see that the most
> simple form does not need runtime interpolators because the already
> computed ‘joint’ rotation data is shipped in the form of a set of keyframe
> data for each vertex at each frame for a certain number of frames at a
> fixed increment in a form that is ready to send to the hardware that
> computes that vertex location for that frame. Is that one reason this gltf
> device is so effortlessly fast? Most of the computing is already done.
>
> The most simple gltf just tells the number of frames and the fixed time
> increment. The runtime sets the key data at the appropriate time. This is
> the spinning tennis shoe in gltf 3D; it does its thing. I think if you want
> to add more, like interactivity, then you keep it realtime x3d user code
> and do the ‘live’ interpolations to present actual data at that time.
>
>
>
>
>    - Regards,
>    - Michalis
>
>
>
> All Best,
>
> Joe
>
>
>
> pt., 30 wrz 2022 o 02:33 Joseph D Williams <joedwil at earthlink.net>
> napisał(a):
>
> >
>
> > (me) A big point is, that the gltf skinned animation structure …
>
> >
>
> >
>
> >
>
> > Another is that the gltf animation defines linear constant increment
> time steps. You can include a certain number of keys and key data with
> constant key time increments. No interpolation, because no frames between
> keys?
>
> >
>
> > This limits author when creating animations that use authored key times
> with linear interpolation.
>
> >
>
> > So, if the web3d x3d browser and a text editor and some examples
> constitutes your best authoring toolset, you may want to develop the
> animations using usual tools, then where appropriate to use gltf as items
> in the presentation, you may wish to implement an animated interactive
> object using gltf transport as part of the user code.
>
> >
>
> > Always remember that your final deliverable must be delivered by
> somebody else’s web and interacted with by somebody else’s runtime.
>
> >
>
> >
>
> >
>
> > Of course the gltf is basic stuff for runtime data and data to tell the
> run time what to use and how to use it, but the gltf does nothing – it is
> just data that after some level of expertise interactive realtime scene
> with learn how to use effectively. Still, to me the magical thing is that
> some of the most secret data structures, especially for animations, at
> least partly, originating in clever ways to transport yet hide the stuffs,
> are exposed to the world, hopefully attracting creators learning about the
> straightforwardness of x3d hanim via learning about the mysteries of gltf
> assets.
>
> >
>
> >
>
> >
>
> > So, there exists a standard set of gltf file.name.data assets that
> correspond, for example, to create a skeleton-driven animated mesh.
> Likewise there is a standard set of x3d hanim Humanoid features, skeleton
> and skin and joint animations, to create the animated character. The gltf
> can include all this as ordered input used as input to x3d user code. Or,
> if your tool can generate the gltf, your browser can store your skin
> animation in gltf runtime-ready form and you ship the thing without the
> need for your interactor’s platform to do interpolation.
>
> >
>
> >
>
> >
>
> > All the more reason to implement some simple things like the hanim
> Displacer event-driven mesh animation and hanim skeleton-driven skin
> animation as nodes available in typical x3d, instead of only in hanim. The
> gltf has all the basic stuff.
>
> >
>
> >
>
> >
>
> >  Thanks,
>
> >
>
> > Joe
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > From: Joseph D Williams
>
> > Sent: Thursday, September 29, 2022 10:12 AM
>
> > To: Michalis Kamburelis; Brutzman, Donald (Don) (CIV)
>
> > Cc: X3D Public Mailing List (x3d-public at web3d.org)
>
> > Subject: Re: [x3d-public] X3D Working Group meeting 23 SEP
> 2022:Mantisissues review, SvgTexture
>
> >
>
> >
>
> >
>
> > About gltf and general files, I would like to be able to reference a
> json of gltf field for any field in any node. That is, if I want to
> substitute a json form of some field then I should be able to some json,
> then be able to ‘simplify’ my user code by using the json file name and
> field reference instead of the data. No conversion or anything, just the
> expected data in the expected standard form.
>
> >
>
> > However, the gltf spec has covered some of this, json forms that (1)
> provide data to an x3d scene in the expected standard forms and even
> structures, plus (2) some standardized machine ready forms that would be
> otherwise derived from standard x3d input, and (3) stuffs we probably have
> not discovered yet, since the json and gltf forms are or can be so
> generalized.
>
> >
>
> >
>
> >
>
> > 2.4. Skinned mesh animation.
>
> >
>
> >
>
> >
>
> > This provides examples of both 1  and 2 above, and probably 3.
>
> >
>
> > First, the animation data speced in gltf is transported by vertex. The
> gltf data for each vertex includes the data for the list of joints and
> their rotations and weights so the hardware can compute translation of that
> vertex at each frame. So we get a fragment of data for each vertex at each
> keyframe. This style of presenting animation data is intended to produce a
> predefined animation over a certain number of keyframes, not to be
> interactive. As authors, we might see how, when we were dabbling and
> swatting in the data, that we might like to have the ability to go in there
> an slightly mod the rots and weights for that vertex in that keyframe,
> but, I diverge.
>
> >
>
> > A big point is, that the gltf skinned animation structure is set up for
> transporting precomputed keyframe data. The stuff can run fast be because,
> well, because the inputs from the skeleton are already computed, no
> interpolation because the keytimes and skeleton pose is already known. This
> is essentially the gfx form of a simple video, however, if you have the
> data then you might be able to derive the skeleton and animation inputs.
>
> >
>
> >
>
> >
>
> > This is basically the same idea for the Hanim Displacer and skin
> animation features. You can use a standard gltf form to provide precomputed
> data for each of these Hanim features. The x3d form gives all the inputs
> required to produce the gltf forms for the complete animation, however, it
> might not be possible to reconstruct the x3d form from the gltf form.
>
> >
>
> >
>
> >
>
> > 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).
>
> >
>
> >
>
> >
>
> > Right, we have an x3d form that associates vertices with joints and the
> gltf form that associates joints with vertices. The gltf data form is a
> field of vertices that list joint rotations and weights while the x3d form
> is a field of joints that list vertices. The former is the convenient way
> for the machine as it just increments through the verts using precomputed
> data. The latter is the convenient way for human authors to construct the
> skeleton and design skin animations. Once the human has constructed the
> humanoid skeleton and skin, and designed the animation using x3d, then, if
> the animation is designed to run like a video, the x3d tool could save the
> computed data as gltf and ship that and a mesh and a texture instead of
> shipping the armature. timers, and interpolators along with it.
>
> >
>
> >
>
> >
>
> > CGE is just playing glTF skinned mesh animation without the help of
> H-Anim nodes.
>
> >
>
> >
>
> >
>
> > Of course it is ‘easy’ to play it, harder of impossible to create using
> it. Again, I see it as just a simple transportable form. When you have a
> skin with the same number of points and general locations, then yes we
> ought to be able to animate  ‘similar’ skins using the same gltf
> animations. This is almost the same but entirely different than saying we
> ought to be able to use similar animations for similar skeletons to drive
> similar skins. When you get to gltf vertex data you have already lost
> access to the skeleton except by tweaking binaries in some special editor,
> yeah, they really do that … .
>
> >
>
> >
>
> >
>
> > Last I heard, Andreas was working on it in X3DOM, but wrote it is
> unfinished.
>
> >
>
> >
>
> >
>
> > Thanks for everyone’s work on all this. The json will do x3d lots of
> good over time. For now the main contribution of json to Hanim is not
> necessarily the gltf forms to transport precomputed data, but hopefully
> allowing me to name a json field for any field of the Humanoid. If the
> scene gets validated, then of course the declared json is included.
>
> >
>
> >
>
> >
>
> > Thanks for fun with web3d x3d Hanim
>
> >
>
> > Joe
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > From: Michalis Kamburelis
>
> > Sent: Thursday, September 29, 2022 6:05 AM
>
> > To: Brutzman, Donald (Don) (CIV)
>
> > Cc: X3D Public Mailing List (x3d-public at web3d.org)
>
> > Subject: Re: [x3d-public] X3D Working Group meeting 23 SEP 2022:
> Mantisissues 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://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D
>
> >
>
> > . Some have extensions in CGE, for some -- we don't yet have a ready
>
> >
>
> > solution:
>
> >
>
> >
>
> >
>
> > 2.1. Tangent node (extension in CGE ,
>
> >
>
> >
> https://castle-engine.io/x3d_implementation_rendering_extensions.php#section_Explicit_tangent_vectors
>
> >
>
> > )
>
> >
>
> >
>
> >
>
> > 2.2. Modulate mode for Color/ColorRGBA (
>
> >
>
> >
> https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D#per-vertex-colors
>
> >
>
> > ,
> https://castle-engine.io/x3d_implementation_rendering_extensions.php#section_ext_color_mode
>
> >
>
> > )
>
> >
>
> >
>
> >
>
> > 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://www.w3.org/Graphics/SVG
>
> >
>
> > > * "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/components/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
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> >
>
> > 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/20220929/8d4c9989/attachment-0001.html>