[x3d-public] 3D Working Group agenda 23 FEB 2023: progress reports, proposed Metaverse group, glTF extensions, X3D 4.1 feature discussion
Michalis Kamburelis
michalis.kambi at gmail.com
Fri Feb 24 11:23:46 PST 2023
As for image-based lights:
- Indeed, KHR_lights_environment is still only a PR, though from what
I understood -- it has general support as "good direction". It just
takes a while to iron out the details.
- The relation to EXT_lights_image_based, as they state themselves:
"This extension is based on EXT_lights_image_based, with the major
difference being that KTX2 is used as a container format for cubemap
textures." https://github.com/KhronosGroup/glTF/pull/1956 . In the
end, the basic concepts are similar, and X3D EnvironmentLight can
likely match both.
- In some way, we have it easier in X3D, because we already have
cubemaps, we have X3DEnvironmentTextureNode . To support KTX or KTX2
for cubemaps, we don't need to invent here anything - we just use
ImageCubeMapTexture .
- My notes about it are on
https://github.com/michaliskambi/x3d-tests/wiki/Image-Based-Lighting-(EnvironmentLight-node)
. Initial tests on
https://github.com/michaliskambi/x3d-tests/tree/master/pbr/environment_light
. Along with some initial implementation in CGE/view3dscene, but it's
really only initial -- I sample light cubemap, but I use the color
(most likely) in wrong way.
As for punctual lights:
- See my notes on
https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D#punctual-lights
.
- Reading Holger notes, I think we match exactly in what we do between
X_ITE and CGE (great!).
- Indeed most parameters have sensible equivalent from glTF to X3D.
- Indeed attenuation is just (0, 0, 1).
- You can take a look at "TPunctualLights.ReadLight" in
https://github.com/castle-engine/castle-engine/blob/master/src/scene/load/x3dloadinternalgltf.pas#L685
.
- In Castle Game Engine I added extension to interpret radius = -1 as
infinity, so when reading glTF I just do "if glTF radius = 0 then X3D
radius := -1 else X3D radius := glTF radius".
Regards,
Michalis
pt., 24 lut 2023 o 20:06 Holger Seelig <holger.seelig at yahoo.de> napisał(a):
>
> I have done this, as shown below, not handling umbra and attenuation leads to (0, 0, 1):
>
> All:
>
> light === gltf .light
>
> lightNode .color = light .color
> lightNode .intensity = light .intensity
>
> Spot:
>
> lightNode .radius = light .range
> lightNode .cutOffAngle = light .outerConeAngle
> lightNode .beamWidth = light .innerConeAngle
> lightNode .attenuation = (0, 0, 1)
>
> Point:
>
> lightNode ._radius = light .range
> lightNode ._attenuation = (0, 0, 1);
>
> Note that radius 0 means infinity.
>
> Best regards,
> Holger
>
> > Am 24.02.2023 um 19:43 schrieb Andreas Plesch <andreasplesch at gmail.com>:
> >
> > Hi Holger, Michalis,
> >
> > The glTF lights map pretty well to the X3D lights. But there are some
> > differences in terms of attenuation and umbra and perhaps other
> > details, I believe. Could you point me to how you deal with these
> > minor differences before I start to perhaps implement ?
> >
> > Thanks, Andreas
> >
> > On Fri, Feb 24, 2023 at 1:32 PM Holger Seelig <holger.seelig at yahoo.de> wrote:
> >>
> >> X_ITE supports the following extensions:
> >>
> >> - KHR_materials_unlit implemented with PhysicalMaterial because of gamma correction.
> >>
> >> - KHR_materials_emissive_strength - implemented by adding emissiveStrength field to X3DOneSidedMaterialNode.
> >>
> >> - KHR_lights_punctual - mapped to Point/Spot/DirectonalLight
> >>
> >> - KHR_texture_transform - mapped to X3D TextureTransform
> >>
> >> - KHR_materials_pbrSpecularGlossiness - not really supported, without a SpecularGlossinessMaterial node there will be no real support, but PhysicalMaterial is more straightforward.
> >>
> >> Best regards,
> >> Holger
> >>
> >>
> >>
> >> Am 24.02.2023 um 19:15 schrieb Michalis Kamburelis <michalis.kambi at gmail.com>:
> >>
> >> From others:
> >>
> >> 1. Blender: they support a number of extensions at import and export:
> >> https://docs.blender.org/manual/en/dev/addons/import_export/scene_gltf2.html#extensions
> >>
> >> 2. CGE supports ( https://castle-engine.io/gltf ):
> >>
> >> - KHR_materials_unlit - unlit materials. This translates nicely to
> >> X3D4 UnlitMaterial.
> >>
> >> - KHR_lights_punctual - define lights (point, spot, directional)
> >> within glTF file. These translate nicely to X3D lights (with unbounded
> >> intensity in X3D4).
> >>
> >> - KHR_texture_transform - transform (scale, offset, rotate) texture
> >> coordinates. These translate to X3D texture coordinate transformation
> >> nodes.
> >>
> >> - KHR_materials_pbrSpecularGlossiness - support for alternative
> >> specification of material parameters using specular-glossiness. Only
> >> partial support — without textures. Extension considered deprecated by
> >> Khronos in favor of KHR_materials_specular.
> >>
> >> My most important plans:
> >>
> >> - X3D nodes for binary meshes (I know X3DOM has this already) and then
> >> KHR_draco_mesh_compression
> >>
> >> - EnvironmentLight in X3D4, consistent with EXT_lights_image_based ,
> >> KHR_lights_environment .
> >>
> >> 3. Everyone: As you see, there is a big overlap between all these
> >> extension lists (X3DOM, Blender, CGE) and that's good :)
> >>
> >> Some glTF extensions are quite popular and in practice supported by
> >> all/most glTF viewers.
> >>
> >> Regards,
> >> Michalis
> >>
> >> pt., 24 lut 2023 o 17:56 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
> >>
> >>
> >> On glTF extension below:
> >>
> >>
> >> ...
> >> 4. glTF Extensions.
> >>
> >> Recent email threads have pointed out that X3D 4.0 normatively references
> >> glTF 2.0. Meanwhile numerous glTF extensions are available. Nothing
> >> prohibits X3D browsers/players/tools from going beyond baseline glTF 2.0 -
> >> the "X" in X3D is Extensible. 8)
> >>
> >> There is benefit to software developers, content authors and end users to
> >> having a shared strategy on what new features to support. Considering and
> >> supporting such a list is further suitable as a Web3D Recommendation as a
> >> stepping stone towards future pursuit of X3D 4.1 with International
> >> Standards Organization (ISO).
> >>
> >>
> >>
> >>
> >> Here are a few glTF extensions that have been proposed. Let's discuss which
> >> have high value and deserve consideration as part of a shared strategy.
> >>
> >>
> >>
> >> * EnvironmentLight
> >> * emissiveColor bloom
> >> * Draco geometry compression
> >> * Human animation
> >> * Others?
> >>
> >>
> >> x3dom supports a few extensions:
> >>
> >> "KHR_materials_pbrSpecularGlossiness", (now deprecated and replaced by
> >> KHR_materials_specular)
> >> "KHR_materials_unlit",
> >> "KHR_texture_transform"
> >>
> >> Soon it will also support Draco decompression.
> >>
> >> KHR prefixed extensions are sanctioned by Khronos.
> >>
> >> Here is a complete list:
> >>
> >> KHR_draco_mesh_compression
> >> KHR_lights_punctual
> >> KHR_materials_clearcoat
> >> KHR_materials_emissive_strength
> >> KHR_materials_ior
> >> KHR_materials_iridescence
> >> KHR_materials_sheen
> >> KHR_materials_specular
> >> KHR_materials_transmission
> >> KHR_materials_unlit
> >> KHR_materials_variants
> >> KHR_materials_volume
> >> KHR_mesh_quantization
> >> KHR_texture_basisu
> >> KHR_texture_transform
> >> KHR_xmp_json_ld
> >>
> >> KHR_lights_punctual may be feasible to support, and KHR_xmp_json_ld is
> >> about metadata and also should be possible to translate to Metadata
> >> nodes.
> >>
> >> EXT_lights_image_based is a multi-vendor extension related to EnvironmentLight
> >>
> >> -Andreas
> >>
> >>
> >>
> >>
> >>
> >>
> >> 5. X3D 4.1 feature discussion. (carried over from last week)
> >>
> >>
> >>
> >> Many possibilities! The "X" in X3D is Extensible, so pursuit of further
> >> evolution is an essential part of our design. We benefit from (but are not
> >> limited by) ISO stability, since implementers can experiment with innovative
> >> practices and also match Web3D Consortium recommended practices.
> >>
> >>
> >>
> >> a. Near term: resolving Sound component differences with Web Audio API.
> >> Some noted issues will likely get deferred as X3D 4.1 issues.
> >> b. In progress: HAnim2/X3D4 additions for site names, poses, and
> >> clothing to provide support for apparel.
> >> c. What else? What's next?
> >>
> >>
> >>
> >> Wishing best progress. Have fun with X3D! 8)
> >>
> >>
> >>
> >> all the best, Don
> >>
> >> --
> >>
> >> Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu
> >>
> >> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
> >>
> >> X3D graphics, virtual worlds, Navy robotics https://
> >> faculty.nps.edu/brutzman
> >>
> >>
> >>
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230224/a7f27407/attachment.html>
> >> -------------- next part --------------
> >> A non-text attachment was scrubbed...
> >> Name: smime.p7s
> >> Type: application/pkcs7-signature
> >> Size: 5353 bytes
> >> Desc: not available
> >> URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230224/a7f27407/attachment.p7s>
> >>
> >> ------------------------------
> >>
> >> Subject: Digest Footer
> >>
> >> _______________________________________________
> >> x3d-public mailing list
> >> x3d-public at web3d.org
> >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >>
> >>
> >> ------------------------------
> >>
> >> End of x3d-public Digest, Vol 167, Issue 76
> >> *******************************************
> >>
> >>
> >>
> >>
> >> --
> >> Andreas Plesch
> >> Waltham, MA 02453
> >>
> >> _______________________________________________
> >> 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
> >>
> >>
> >
> >
> > --
> > Andreas Plesch
> > Waltham, MA 02453
>
More information about the x3d-public
mailing list