<div dir="auto">@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.</div><div dir="auto"><br></div><div dir="auto">I will switch to a non-text editor when i find something reasonably compelling. Meanwhile vim and neovim are slowly catching up…</div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 29, 2022 at 9:07 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div>@Joseph </div><br><div>"""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.""" </div><br><div>-- 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.</div><br><div>Please consult the glTF spec <a href="https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html" title="https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html" target="_blank">https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html</a> or cheat sheet <a href="https://www.khronos.org/files/gltf20-reference-guide.pdf" title="https://www.khronos.org/files/gltf20-reference-guide.pdf" target="_blank">https://www.khronos.org/files/gltf20-reference-guide.pdf</a> , they give all the information.</div><br><div>@John<span>:</span> 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.</div><br><div>But I cannot guarantee and I didn't test whether this goal is achieved 100% <span>:)</span> 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. </div><br><div>But what you describe should be possible and I would encourage you to test it. If there are differences, you can report them to <a href="https://github.com/KhronosGroup/glTF-Blender-IO" title="https://github.com/KhronosGroup/glTF-Blender-IO" target="_blank">https://github.com/KhronosGroup/glTF-Blender-IO</a> .</div><br><div>Regards,</div><div>Michalis</div><div>On wrz 30 2022, at 3:22 am, Joseph D Williams <<a href="mailto:joedwil@earthlink.net" target="_blank">joedwil@earthlink.net</a>> wrote:</div><blockquote><div><div class="MsoNormal"> </div><br><div class="MsoNormal"> </div><br><div class="MsoNormal">Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986" title="https://go.microsoft.com/fwlink/?LinkId=550986" target="_blank">Mail</a> for Windows</div><br><div class="MsoNormal"> </div><br><div><div class="MsoNormal"><div><strong>From: </strong><a href="mailto:michalis.kambi@gmail.com" title="mailto:michalis.kambi@gmail.com" target="_blank">Michalis Kamburelis</a></div><div><strong>Sent: </strong>Thursday, September 29, 2022 5:39 PM</div><div><strong>To: </strong><a href="mailto:joedwil@earthlink.net" title="mailto:joedwil@earthlink.net" target="_blank">Joseph D Williams</a></div><div><strong>Cc: </strong><a href="mailto:brutzman@nps.edu" title="mailto:brutzman@nps.edu" target="_blank">Brutzman, Donald (Don) (CIV)</a>; <a href="mailto:x3d-public@web3d.org" title="mailto:x3d-public@web3d.org" target="_blank">X3D Public Mailing List (x3d-public@web3d.org)</a></div><div><strong>Subject: </strong>Re: [x3d-public] X3D Working Group meeting 23 SEP 2022:Mantisissuesreview, SvgTexture</div></div></div><div class="MsoNormal"> </div><br><ul><li><div><font style="font-size:11pt;color:rgb(0,0,0)"><font style="font-family:Calibri,sans-serif;color:rgb(0,0,0)">@Joseph: The joints/transforms in glTF are animated in the same way as</font></font></div></li></ul><div class="MsoNormal">the joints/transforms in X3D. Surely you can (and should) interpolate</div><br><div class="MsoNormal">them between keyframes.</div><br><div class="MsoNormal"> </div><br><div class="MsoNormal">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.</div><br><div class="MsoNormal">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</div><br><div class="MsoNormal"> </div><br><ul><li><div><font style="font-size:11pt;color:rgb(0,0,0)"><font style="font-family:Calibri,sans-serif;color:rgb(0,0,0)">I do not get why you say "No interpolation, because no frames between</font></font></div></li></ul><div class="MsoNormal">keys? This limits author when creating animations that use authored</div><br><div class="MsoNormal">key times with linear interpolation. "</div><br><div class="MsoNormal"> </div><br><div class="MsoNormal">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.</div><br><div class="MsoNormal">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.</div><br><div class="MsoNormal"> </div><br><ul><li><div><font style="font-size:11pt;color:rgb(0,0,0)"><font style="font-family:Calibri,sans-serif;color:rgb(0,0,0)">Regards,</font></font></div></li><li><div><font style="font-size:11pt;color:rgb(0,0,0)"><font style="font-family:Calibri,sans-serif;color:rgb(0,0,0)">Michalis</font></font></div></li></ul><div class="MsoNormal"> </div><br><div class="MsoNormal">All Best,</div><br><div class="MsoNormal">Joe</div><br><div class="MsoNormal"> </div><br><div class="MsoNormal">pt., 30 wrz 2022 o 02:33 Joseph D Williams <<a href="mailto:joedwil@earthlink.net" target="_blank">joedwil@earthlink.net</a>> napisał(a):</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> (me) A big point is, that the gltf skinned animation structure …</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 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?</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> This limits author when creating animations that use authored key times with linear interpolation.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> Always remember that your final deliverable must be delivered by somebody else’s web and interacted with by somebody else’s runtime.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> Thanks,</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> Joe</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> From: Joseph D Williams</div><br><div class="MsoNormal">> Sent: Thursday, September 29, 2022 10:12 AM</div><br><div class="MsoNormal">> To: Michalis Kamburelis; Brutzman, Donald (Don) (CIV)</div><br><div class="MsoNormal">> Cc: X3D Public Mailing List (<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>)</div><br><div class="MsoNormal">> Subject: Re: [x3d-public] X3D Working Group meeting 23 SEP 2022:Mantisissues review, SvgTexture</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 2.4. Skinned mesh animation.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> This provides examples of both 1 and 2 above, and probably 3.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> We all agreed that glTF skinned mesh</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> animation can be probably expressed as X3D H-Anim nodes, but so far</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> nobody (from what I know) actually figured out how to do this</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> conversion (not to mention -- conversion that preserves the</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> efficiency, and allows to play glTF skinned animation on GPU without</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> calculating anything extra on browser).</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> CGE is just playing glTF skinned mesh animation without the help of H-Anim nodes.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 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 … .</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> Last I heard, Andreas was working on it in X3DOM, but wrote it is unfinished.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> Thanks for fun with web3d x3d Hanim</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> Joe</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> From: Michalis Kamburelis</div><br><div class="MsoNormal">> Sent: Thursday, September 29, 2022 6:05 AM</div><br><div class="MsoNormal">> To: Brutzman, Donald (Don) (CIV)</div><br><div class="MsoNormal">> Cc: X3D Public Mailing List (<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>)</div><br><div class="MsoNormal">> Subject: Re: [x3d-public] X3D Working Group meeting 23 SEP 2022: Mantisissues review, SvgTexture</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> We cannot represent 100% of glTF 2.0 features as X3D nodes. We're not</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> there (yet).</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> So the statement “X3D 4.0 provides full support for inline loading or</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> directly representing glTF 2.0 models.” sounds too strong IMHO. At</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> least for me, the words "full" and "directly representing" above would</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> suggest that we can express 100% glTF features in X3D, which we can't.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> We achieved progress in X3D 4.0 (we have PBR which is compatible with</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> glTF). But we still have various missing things:</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 1. Compressed geometry from glTF -- it can loaded, but it has to</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> become decompressed in the process. (like CGE) Or the browser has to</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> load glTF meshes without converting them to X3D meshes. (like FreeWRL)</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> Or browser has to use browser-specific extensions (like X3DOM).</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> We don't yet have the "ideal solution" - X3D nodes for mesh data</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> that can be uploaded to GPU directly. Document</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> <a href="https://www.web3d.org/specifications/FeaturesComparisonX3D4glTF2.pdf" target="_blank">https://www.web3d.org/specifications/FeaturesComparisonX3D4glTF2.pdf</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> also states it --- we added together on one call valid statement "X3D</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> native nodes directly corresponding to glTF compressed geometry not</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> supported, but Inline loading of glb models is supported."</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 2. Various other things I mentioned in</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> <a href="https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D" target="_blank">https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> . Some have extensions in CGE, for some -- we don't yet have a ready</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> solution:</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 2.1. Tangent node (extension in CGE ,</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> <a href="https://castle-engine.io/x3d_implementation_rendering_extensions.php#section_Explicit_tangent_vectors" target="_blank">https://castle-engine.io/x3d_implementation_rendering_extensions.php#section_Explicit_tangent_vectors</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> )</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 2.2. Modulate mode for Color/ColorRGBA (</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> <a href="https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D#per-vertex-colors" target="_blank">https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D#per-vertex-colors</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> , <a href="https://castle-engine.io/x3d_implementation_rendering_extensions.php#section_ext_color_mode" target="_blank">https://castle-engine.io/x3d_implementation_rendering_extensions.php#section_ext_color_mode</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> )</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 2.3. glTF CubicSpline and Step interpolation. CubicSpline can be</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> approximated in X3D by converting to Linear with more points (e.g.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 10x), Step can be performed by converting to Linear with 2x points</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> (CGE has extension to do "Step" explicitly). But that's not perfect.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> 2.4. Skinned mesh animation. We all agreed that glTF skinned mesh</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> animation can be probably expressed as X3D H-Anim nodes, but so far</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> nobody (from what I know) actually figured out how to do this</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> conversion (not to mention -- conversion that preserves the</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> efficiency, and allows to play glTF skinned animation on GPU without</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> calculating anything extra on browser). CGE is just playing glTF</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> skinned mesh animation without the help of H-Anim nodes. Last I heard,</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> Andreas was working on it in X3DOM, but wrote it is unfinished.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> Regards,</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> Michalis</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> czw., 29 wrz 2022 o 13:00 Brutzman, Donald (Don) (CIV)</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> napisał(a):</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > I added a summary statement (quoted below) and made a few formatting improvements.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Features Comparison X3D4 glTF2 (.pdf) spreadsheet shows complete interoperability with glTF rendering.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > <a href="https://www.web3d.org/specifications/FeaturesComparisonX3D4glTF2.pdf" target="_blank">https://www.web3d.org/specifications/FeaturesComparisonX3D4glTF2.pdf</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > <a href="https://www.web3d.org/specifications/FeaturesComparisonX3D4glTF2.xlsx" target="_blank">https://www.web3d.org/specifications/FeaturesComparisonX3D4glTF2.xlsx</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > “X3D 4.0 provides full support for inline loading or directly representing glTF 2.0 models.”</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > As ever, all review comments and questions welcome. Have fun with X3D! 8)</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > all the best, Don</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > --</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > X3D graphics, virtual worlds, Navy robotics https:// <a href="http://faculty.nps.edu/brutzman" target="_blank">faculty.nps.edu/brutzman</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > From: Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Sent: Saturday, September 24, 2022 7:55 AM</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > To: John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Cc: X3D Public Mailing List (<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>) <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>>; Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Subject: RE: [x3d-public] X3D Working Group meeting 23 SEP 2022: Mantis issues review, SvgTexture</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > John, there is a bit more in the issue and the references.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > SVG produces animatable interactive 2D images through vector graphics. So it has characteristics of both ImageTexture and MovieTexture (and interpolators and scriptable event models).</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > all the best, Don</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > --</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > X3D graphics, virtual worlds, Navy robotics https:// <a href="http://faculty.nps.edu/brutzman" target="_blank">faculty.nps.edu/brutzman</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > From: John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Sent: Friday, September 23, 2022 5:33 PM</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > To: Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Cc: X3D Public Mailing List (<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>) <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Subject: Re: [x3d-public] X3D Working Group meeting 23 SEP 2022: Mantis issues review, ballot deadlines, X3D Application Stack Layer Examples diagram</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Disabling/enabling animation of SVGs should be in more inclusive profiles.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Is that simple enough?</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > On Fri, Sep 23, 2022 at 7:23 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > SVGs should be considered animations with popular packages being D3.js.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Otherwise, SVG is a declarative language, similar to X3D and HTML. Last I heard, there was no official schema for SVG.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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?</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > On Fri, Sep 23, 2022 at 1:44 PM Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Attendees: Dick Puk, Don Brutzman</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Mantis 1400: add Scalable Vector Graphics (SVG) to recommended image formats for ImageTexture</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > <a href="https://www.web3d.org/member-only/mantis/view.php?id=1400" target="_blank">https://www.web3d.org/member-only/mantis/view.php?id=1400</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > SVG references:</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > * <a href="https://www.w3.org/Graphics/SVG" target="_blank">https://www.w3.org/Graphics/SVG</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > * "SVG is a markup language for describing two-dimensional graphics applications and images, and a set of related graphics script interfaces."</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Dick estimation: thinks SVG is a 2D scene-graph definition language. It can result as an image, though so can X3D.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Of note is that browsers are not forbidden from implementing SVG as an ImageTexture format, and also that SVG-to-PNG converters are commonplace.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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).</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Possible alternate: define SvgTexture node? What fields would it have?</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Suggested possible resolution:</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > a. Browsers are welcome to implement ImageTexture as an allowed url format if they see fit,</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > b. SvgTexture ought to be designed and considered as a possible new node,</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > c. ComposedImageTexture (or somesuch) might be designed and considered as an even-more general possibility for comuputational 2D imagery,</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > d. Following further practical experience, defer any specification-change recommendations to future X3D4.1.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Mantis 1401: aligning X3D4 LineProperties with Quality Information Framework (QIF) specification</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > <a href="https://www.web3d.org/member-only/mantis/view.php?id=1401" target="_blank">https://www.web3d.org/member-only/mantis/view.php?id=1401</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Suggested resolution:</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > a. The concepts are directly aligned and overlapping, with some additions by QIF.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > b. This ISO standard does not appear to have been considered by SC24 or JTC1.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > c. Close scrutiny of both terms and definitions needs to be performed before any changes might be recommended.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > e. At that point, amendment of X3D to stay aligned with Registry of Items (or possibly add further styles independently) can be considered.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > f. Defer to X3D 4.1.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Meanwhile note in Web3D current ballot comments the need to fix the table erratum previously noted.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Mantis 1192: 07.2.2 Bindable children nodes - Undefined results if bindable node is under Switch or LOD is problematic</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > <a href="https://www.web3d.org/member-only/mantis/view.php?id=1192#bugnotes" target="_blank">https://www.web3d.org/member-only/mantis/view.php?id=1192#bugnotes</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Comment on 19775-1: Abstract X3D Definitions - V3.3</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 7.2.2 Bindable children nodes</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#BindableChildrenNodes" target="_blank">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#BindableChildrenNodes</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > -----------------</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Subject: Undefined results if bindable node is under Switch or LOD is problematic</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Spec sayeth:</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > "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."</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Related: Mantis issue 749</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > April 29:</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Analysis during X3D Working Group call:</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > a. Switch would keep each binding stack aligned with whichever child was active, thereby binding and unbinding nodes whenever the Switch level is modified.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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).</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Spec editors work on integrating these principles as specification prose (we are close already) and report back recommended changes to X3D working group.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Today’s session.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Alternatives deserving working-review consensus:</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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).</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > b. If not balloted then this becomes an X3D4.1 issue.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 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?</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 2. We only have 4 total issues to review as planned Web3D comments. This will occur during a single working-group meeting, 7 OCT.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Deadline for X3D Ballot comments:</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > OCT, Web3D comments to INCITS (U.S. National Standards Body</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > TBD OCT, INCITS comments to SC24</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 4 NOV, SC24 comments to ISO</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > No meeting currently planned for 30 SEP.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > 3. Bonus round: we worked on the “layer” diagram from recent meetings a bit more. Latest X3dApplicationStackLayerExamples is attached, all comments welcome.</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Have fun with X3D!</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > all the best, Don</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > --</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > X3D graphics, virtual worlds, Navy robotics https:// <a href="http://faculty.nps.edu/brutzman" target="_blank">faculty.nps.edu/brutzman</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > _______________________________________________</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > x3d-public mailing list</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> ></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > _______________________________________________</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > x3d-public mailing list</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> _______________________________________________</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> x3d-public mailing list</div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a></div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal">> </div><br><div class="MsoNormal"> </div></div></blockquote>_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div></div>