[x3d-public] Translating Blend mode in Blender to standard x:d

Michalis Kamburelis michalis.kambi at gmail.com
Mon May 20 02:33:37 PDT 2024 

John,

Indeed the "Appearance.alphaMode" field in X3D is exactly what you
need to express Blender's "Blend Mode".

And it is equivalent to glTF "alphaMode",
https://github.com/KhronosGroup/glTF/blob/main/specification/2.0/Specification.adoc#alpha-coverage
.

This is all consistent by design, to make things easier :) If you're
working on new Blender->X3D exporter, then yes, you should export
Blender's "Blend Mode" to X3D "alphaMode".

Note: X3D has one additional value for "alphaMode" called "AUTO",
default for backward compatibility. But if you can, I recommend to
always specify "alphaMode" as something else ("OPAQUE", "BLEND",
"MASK"). This makes things explicit, X3D browsers then don't need to
do browser-specific detection (well, guessing) when to use alpha
blending or masking, which is sometimes non-trivial (when using
multiple textures or when texture has an alpha channel that could make
sense for both blending or testing). Using "alphaMode" like "OPAQUE",
"BLEND", "MASK" is a great help for the renderers -- it explicitly
says how to deal with alpha. And since Blender's "Blend Mode" gives
you *exactly* this information -> export it :)

Regards,
Michalis

pon., 20 maj 2024 o 03:43 John Carlson via x3d-public
<x3d-public at web3d.org> napisał(a):
>
> This appears in Section 12.4.2 Appearance:
>
> The  alphaMode field determines how the final transparency value is computed for each pixel. The final alpha value is determined by various properties of the material and textures (following the lighting model equations given in the 17 Lighting component) or by custom shaders, when these are used (see 31 Programmable shaders component). The following values of  alphaMode are allowed:
>
> AUTO — the X3D browser automatically determines the alpha treatment based on the material  transparency, optionally taking into account the alpha channel of the textures that affect the final alpha value. In effect, this mode means that X3D browser auto-detects which of the algorithms described below: OPAQUE, MASK or BLEND. This mode corresponds to rendering according to the X3D version 3 specification.
> OPAQUE — the shape is rendered as opaque, and the final alpha value is ignored.
> MASK — the shape is rendered using alpha testing. When the final alpha value is less than  alphaCutoff, the relevant pixel is discarded ( i.e., treated as fully transparent). When the final alpha value is greater than or equal to  alphaCutoff, the relevant pixel is rendered as if it was fully opaque. Note that the alphaCutoff value matters only when  alphaMode is MASK, or when when  alphaMode is AUTO and X3D browser auto-detected that the MASK mode is the most appropriate. Note that if custom shader nodes are applied (see 31 Programmable shaders component) then implementation of this technique may require appropriate code in the user-provided shader content.
> BLEND — the shape is rendered using blending techniques. Ideally, the shape is rendered in front of other shapes and the background behind it, mixing the shape color proportionally to the final alpha value. The final alpha value value 0.0 results in a fully transparent pixel, value 1.0 results in a fully opaque pixel, and in-between values results in a partially transparent pixel.
>
>
> Here’s the X3JSAIL method:
>
> https://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/Shape/Appearance.html#setAlphaMode(org.web3d.x3d.jsail.fields.SFString)
>
> This definitely appears be something we could put in Blender exports on the Appearance node or subnodes, we just need to find good examples and a mapping from Blender to X3D.
>
> Once we get Blender an export working, perhaps I can work on import as well.
>
>
> On Sun, May 19, 2024 at 8:08 PM John Carlson <yottzumm at gmail.com> wrote:
>>
>>
>>
>> ---------- Forwarded message ---------
>> From: John Carlson <yottzumm at gmail.com>
>> Date: Sun, May 19, 2024 at 7:55 PM
>> Subject: Re: [x3d-public] X3D Standards review: clearer support for glTF, Inline glTF demonstrated, Web3D Recommended Practices discussion
>> To: Michalis Kamburelis <michalis.kambi at gmail.com>
>> CC: Extensible 3D (X3D) Graphics public discussion <x3d-public at web3d.org>, x3d at web3d.org <x3d at web3d.org>, Katy Schildmeyer KS APPAREL DESIGN <katy at ksappareldesign.com>, Andreas Plesch <andreasplesch at gmail.com>, Don Brutzman <brutzman at nps.edu>, Joe D Williams <joedwil at earthlink.net>, Holger Seelig <holger.seelig at gmail.com>
>>
>>
>> Thanks for your efforts Michalis.  Now the question is, do we want to export "Blend Mode" in the Blender X3DV exporter, so X3D looks like glTF, if someone chooses that?
>>
>> Here's what appears to be X3DOM documentation:
>>
>> X3DOM Developer API Documentation: Class: BlendMode
>>
>> BlendMode | X_ITE X3D Browser (create3000.github.io)
>>
>> Blending (Rendering Partially-Transparent Objects) | Manual | Castle Game Engine (castle-engine.io)
>>
>> I'm not seeing BlendMode here:
>>
>> X3D Tooltips in English version 4.0 (web3d.org)
>>
>> Or here:
>>
>> x3d-code/www.web3d.org/specifications
>> $ find . -type f | xargs grep -i blendmode
>> [ no output ]
>>
>> I'm searching the standard for X3DAppearanceNode.
>>
>> Found this:
>>
>> X3DOM Developer API Documentation: Class: X3DAppearanceChildNode
>>
>> Anyone know where BlendMode is in the standard?
>>
>>
>>
>> On Sun, May 19, 2024 at 4:20 PM Michalis Kamburelis <michalis.kambi at gmail.com> wrote:
>>>
>>> ( I'm reposting here part of my answer from the "Possible negative
>>> values in UV texture" thread, so that people in this thread, and in
>>> mailing list, know the answer too. )
>>>
>>> To be clear, I'm testing exporting
>>> https://github.com/coderextreme/gramps/blob/main/gramps_animated_full_1.blend
>>> from Blender to glTF and opening in latest castle-model-viewer.
>>> Conclusions:
>>>
>>> 1. First of all, the problem is completely not related to negative
>>> texture coordinates (which you don't seem to have) or even to texture
>>> coordinates at all.
>>>
>>>     That is, you have UV texture coordinates, nothing special, all in
>>> 0..1 range it seems, this is standard usage of UV texture. And texture
>>> coordinates seem OK everywhere -- in Blender, in glTF file exported in
>>> Blender, and in how this glTF is displayed by castle-model-viewer.
>>>
>>>     There's no bug here to solve (in model, in implementations, in any specs).
>>>
>>> 2. Your issue comes from using "Blend Mode" = "Alpha Blend" in
>>> Blender. This makes no sense for your model (you don't have
>>> partially-transparent parts), and makes all sorts of weird rendering
>>> artifacts since various browsers activate alpha blending, and the
>>> faces in your mesh are in ~random order, resulting in this weird look.
>>>
>>>     For an explanation, please read how "alpha blending" aka "partial
>>> transparency" is done in real-time rendering, e.g. in OpenGL (but it's
>>> the same in all GPU APIs).
>>>
>>>     Solution: Just switch "Blend Mode" to "Opaque" in Blender.
>>> Re-export to glTF and everything will look OK. Screenshot from
>>> castle-model-viewer attached.
>>>
>>>     I also attach a screen from Blender where I outlined appropriate
>>> material setting. Note that you should probably also *not* put
>>> anything in Blender's "alpha" slot, it is also useless (but will be
>>> harmless after you set "Blend Mode" to "Opaque").
>>>
>>> Let's continue ev. further discussion here please, to make sure
>>> everyone has all the knowledge.
>>>
>>> ( Hopefully mailing list will accept my attachments -- I remade them
>>> as really compressed JPGs. )
>>>
>>> Regards,
>>> Michalis
>>>
>>>
>>>
>>>
>>>
>>> niedz., 19 maj 2024 o 21:47 John Carlson <yottzumm at gmail.com> napisał(a):
>>> >
>>> > I was able to load the .glb appropriately into blender, and see that the texture was rendered OK by blender. This seems to indicate an issue with the .glb viewers I tried with this file:
>>> >
>>> > gramps/gramps_animated_full_1.glb at main · coderextreme/gramps (github.com)
>>> >
>>> > Here are the online viewers I've tried:
>>> >
>>> > glTF Viewer (donmccurdy.com)
>>> >
>>> > PlayCanvas glTF Viewer
>>> >
>>> > The texture/mesh didn't work
>>> >
>>> > I just tried this one online, and it works!
>>> >
>>> > glTF Sample Viewer (khronos.org)
>>> >
>>> > So it appears that there are serious issues with viewing the .glb in some tools, namely, the above mentioned, and these:
>>> >
>>> > Castle Model Viewer
>>> >
>>> > Sunrize
>>> >
>>> > X3DOM
>>> >
>>> > X_ITE
>>> >
>>> > There are plenty of data files, some as generated by X3D-Edit for you to see in the repository.
>>> >
>>> > coderextreme/gramps: Demo of glTF/glb textures vs X3D textures, exported from Blender (github.com)
>>> >
>>> > By all means, write your own Inlines!
>>> >
>>> > My suggestion, based on many long hours working with different data files, UV files, is that negative coordinates in the TextureCoordinate (point field) are being ignored.  But don't take my word for it, try to fix the texture/mesh in your viewers so it looks like Khronos' viewer!
>>> >
>>> > 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)
>>> >>
>>> >> 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)
>>> >>
>>> >> 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)
>>> >>>
>>> >>> 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.]
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> We discussed future change considerations for X3D and how to better support glTF
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> 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!    😊
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> 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.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> 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?
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> 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.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> 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.
>>> >>>> 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?
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> TODO for future meeting: lay down X3D Recommended Practices page.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> Other activity:
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> 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
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> We are preparing a quarterly update release of X3D-Edit.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> 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
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

More information about the x3d-public mailing list