[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 22:17:49 PDT 2024
For example, these trimmed lines in X3D have the -99999 value previously
mentioned:
$ grep -e -99999 *.x3d|cut -c1-150
gramps_animated_full_1_NEW.x3d: <TextureCoordinate
DEF='TX_gramps_low_poly' point='0.87121 0.52307 0.87146 0.52263 0.87197 0.
gramps_animated_full_1_OLD.x3d:
<TextureCoordinate
point="0.8712 0.5231 0.8715 0.5226 0.8720 0.5231 0.3777 0.3135 0.3773
0.3135 0.3773 0.3
So I would focus my search for the problem on the TextureCoordinate code.
Thank me for months of work on Winter and Spring to find this gotcha. This
is why I worked on Blender, the X3D exports actually worked.
John
On Sat, May 18, 2024 at 12:08 AM John Carlson <yottzumm at gmail.com> wrote:
> My guess is, based on experience, that there's negative values in the UV
> map.
>
> A textual form of the UV map is attached for your perusal. Here are the
> lines in question:
>
> 60658 0.6157 0.8191 0 0.6158 0.8191 0 0.1058 -99999 0
> 60659 0.6158 0.8191 0 0.1058 -99999 0 0.6158 0.8191 0
> 72862 1.5161 -0.232 0 1.516 -0.232 0 1.5165 -0.2304 0
>
> If you guys can figure this out in glTF, that would be great.
>
> Note that the X3D node definition standard allows negative values, as
> does X3D viewers. Apparently, glTF viewers get confused.
>
> It took me several months to discover these negative values, perhaps this
> will speed up your search.
>
> You may forward this email.
>
> Thanks, Katy, for the excellent test file.
>
> Thanks,
>
> John
>
> On Fri, May 17, 2024 at 11:25 PM John Carlson <yottzumm at gmail.com> wrote:
>
>> So it actually appears to be a problem with the Blender file or the
>> Blender glTF/glb export of the gramps blend file, found here: gramps/gramps_animated_full_1.blend
>> at main · coderextreme/gramps (github.com)
>> <https://github.com/coderextreme/gramps/blob/main/gramps_animated_full_1.blend>
>>
>> I did check the .glb with a very popular three.js glb viewer by Don
>> McCurdy (first link on Bing). Here's the results:
>> [ deleted ]
>>
>> So I tried the 2nd glTF viewer on Bing the PlayCanvas one, with the glb:
>>
>> [ deleted ]
>>
>> Since .x3d texture seems to export OK (except for intentionally added
>> geometry), I think it may be the glTF/glb export. But there could be a
>> virulent problem with glTF/glb viewers, too. Probably X3D folks should
>> make sure that their code does not produce results like the above.
>>
>> Another thing may be that I exported the PNG directly from Blender,
>> instead of with the .x3d file, but I don't think that's the case. I can
>> double check. Since .glb contains the texture, AFAIK, the .glb should not
>> have any issue. Well, as you can see above, it does!
>>
>> X3D encodings rock!
>>
>> For reference, here are my test files:
>>
>> coderextreme/gramps: Demo of glTF/glb textures vs X3D textures, exported
>> from Blender (github.com) <https://github.com/coderextreme/gramps>
>>
>> You may forward this message. Obviously, we want all web 3D graphics
>> formats and Blender exports to improve.
>>
>> Thanks!
>>
>> John Carlson
>>
>> On Fri, May 17, 2024 at 10:25 PM John Carlson <yottzumm at gmail.com> wrote:
>>
>>> 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/20240518/80886ea2/attachment-0001.html>
More information about the x3d-public
mailing list