[x3d-public] X3D Standards review: clearer support for glTF, Inline glTF demonstrated, Web3D Recommended Practices discussion
John Carlson
yottzumm at gmail.com
Fri May 17 20:25:39 PDT 2024
While I appreciate that glTF works for this *one* model, perhaps with PBR
materials, that doesn't help my use of PNG textures with glTF or glb. For
me, normal X3D texture export from Blender works much better, especially
with viewers like octaga, view3dscene/castle-model-view and sunrize (I
tried X_ITE and X3DOM inside X3D-Edit as well).
I've already posted images, at least a couple of times. Here is a full
repository for your own testing.
coderextreme/gramps: Demo of glTF/glb textures vs X3D textures, exported
from Blender (github.com) <https://github.com/coderextreme/gramps>
I did try replacing the png in glb with another image, and I got an error
(???). Replacing the png in the glTF did not change the result.
So the problem is with the glTF use of ordinary textures, or the glTF
viewers. Or perhaps Blender is exporting glTF/glb poorly.
Please address this. I will continue testing with non-X3D viewers.
John
John
On Fri, May 17, 2024 at 8:41 AM Brutzman, Donald (Don) (CIV) via x3d-public
<x3d-public at web3d.org> wrote:
> X3D Standards Review meeting
>
>
>
> Participants: Nicholas Polys, Dick Puk, Vince Marchetti, Anita Havele,
> Don Brutzman
>
>
>
> [apologies for late posting of minutes, some time was needed for executing
> followups.]
>
>
>
> 1. We discussed future change considerations for X3D and how to better
> support glTF
>
>
>
> 1. Fix glTF examples by adding component statements, 3 are actually
> needed if not using X3D version=’4.0’ profile=’Full’
>
>
>
> Corrections applied and deployed. Also added new model to test glTF
> capability using Inline node.
>
>
>
> - X3D Example Archives: X3D4AM, X3D for Advanced Modeling, Gltf Sample
> Models
> -
> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels
>
>
>
> - X3D Example Archives: X3D4AM, X3D for Advanced Modeling, Gltf Sample
> Models, Alpha Blend Mode Test Inline
> -
> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/AlphaBlendModeTestInlineIndex.html
>
>
>
> Of happy note is that X_ITE and X3DOM both appear to render well (and
> full ZOOM rocks!)
>
>
>
> -
> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/AlphaBlendModeTestInlineX_ITE.html
> -
> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/AlphaBlendModeTestInlineX3dom.xhtml
>
>
>
> Castle view3dscene worked well for me too, so forthcoming
> castle-model-viewer should be fine also. All three renderings were super
> high quality and apparently identical. Evidence:
>
>
>
> -
> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GltfSampleModels/AlphaBlendModeTestInlineX3dom.png
>
>
>
> Ladies and gentlemen, we have a demonstrated capability of X3D Inline of
> glTF models! 😊
>
>
>
> 2. Do we need to consider a new profile? This adds much attendant
> overhead for implementers, and baggage for tools to keep track of, but
> might result in simplicity if use cases for a given community are well
> defined enough to show that the profile indeed adds value.
>
>
>
> Always a perennial topic of interest, always a high hurdle to show that
> sufficient benefit results from a major change. Good discussion occurred,
> leading to the following.
>
>
>
> 3. Add glTF to Interactive and Interchange profile? Interesting that
> our prior motivations of not breaking browser support (e.g. “no changes to
> Interchange”) might be balanced with making X3D inclusion of glTF more
> appealing to new adopters.
>
>
>
> This seems like a promising avenue to pursue further. Integrating glTF
> more fully into X3D infrastructure holds much promise. Minor changes to
> X3D Architecture would be needed but likely provide big payoff. This would
> first be an X3D Recommended Practice, eventually leading to X3D amendment
> at ISO.
>
>
>
> Next discussion: what exactly is Web3D strategy regarding deployment,
> testing and adoption of new capabilities?
>
>
>
> 4. Encouraging browser permissiveness, i.e. rendering what they can
> while not blocking for what they can’t
>
>
> - if profile=Full then do not report “capability not supported” unless
> there x3d nodes in the file are indeed not supported
> - if profile is less that actual content, but browser supports it,
> then render with no more than a warning (i.e. don’t be overly strict)
> - Note that unsupported capabilities won’t render correctly,
> causing frustration… decision on when to issue warnings and when to fail is
> left up to browsers, since X3D does not impose requirements (potential
> performance burdens) on error handling.
>
>
>
> 5. Full profile always includes everything… meaning an author
> producing a model only has to be correct and valid X3D without having to
> worry about getting profile and component statements sliced and diced
> correctly. A permissive approach by browsers to permit content (even if
> only partially supported at the moment) encourages authors to use
> profile=Full regardless of other concerns, supporting long-term workability
> of models independent of evolution of browser capabilities over time.
> 6. Do we need someone to look at MPEG4 again, is anything happening
> over there that we should consider?
>
>
>
> Group assessment: current X3D profile and component architecture design is
> flexible, descriptive, concise, and sound overall. No fundamental changes
> needed at all.
>
>
>
> Near-term options:
>
> - Encourage correct profile/component combinations are provided in X3D
> model content
> - Our recommended practices and examples should be much clearer about
> how authors can use glTF in X3D
> - Consider additional profiles? None yet specifically proposed… so
> not now.
> - Push glTF into other profiles, e.g. Interchange, Interactive,
> Immersive, Medical, CADInterchange? Hmmm…
> - Similarly consider upgrading some of the components (e.g.
> Geospatial) by revising component prerequisites corresponding to glTF.
> - Must be careful about modifying past components since that might
> cause backwards incompatibility.
> - What do implementers think?
>
>
>
> 2. TODO for future meeting: lay down X3D Recommended Practices page.
>
>
>
> 3. Other activity:
>
>
>
> 1. Good progress resuming unit testing of X3D Examples conversion from
> XML (.x3d) to produce Classic VRML (.x3dv) and VRML97 (.wrl) using the
> newly-renamed Castle Model Viewer. Ongoing progress results maintained in
> sourceforge version control and visible at
>
>
>
> - https://www.web3d.org/x3d/content/examples/build.x3dv.all.log.txt
> - https://www.web3d.org/x3d/content/examples/build.vrml97.all.log.txt
>
>
>
> 2. We are preparing a quarterly update release of X3D-Edit.
>
>
>
> 3. Dick and I continue updating two draft ISO specifications, with all
> improvements scrupulously documented in Web3D Issue Tracker. Specification
> comments always welcome.
>
>
>
> - X3D XML Encoding
> -
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-1v4.0-WD1/Part01/X3D_XML.html
>
>
>
> - X3D Classic VRML Encoding
> -
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-2v4.0-WD1/Part02/X3D_ClassicVRML.html
>
>
>
> Have fun with X3D4! 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
>
>
> _______________________________________________
> 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/20240517/679b1377/attachment-0001.html>
More information about the x3d-public
mailing list