[x3d-public] wondering about Texture mapping specified in material nodes [corrected]
Michalis Kamburelis
michalis.kambi at gmail.com
Tue Sep 22 11:24:08 PDT 2020
We cannot really make diffuseTextureCoord, specularTextureCoord inside
a mesh -- since diffuse and specular are for Phong. For PBR
(PhysicalMaterial) we have base, metallicRoughness.
That being said, I believe you're going toward something like my
"Example F" on https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#can-we-make-texture-mapping-using-def--use
. This presents a situation where
A. the Material and/or Appearance can be reused
B. the mapping is performed without the need for SFstring "mapping",
instead it is done using DEF / USE
C. the IndexedFaceSet cannot be reused
So we win A and B, we lose C. Maybe this is a way forward? Preserving
C has probably the lowest priority. I can agree here that merely
reusing the "meat" of geometry node can be a solution.
Regards,
Michalis
wt., 22 wrz 2020 o 19:21 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
>
> see below:
>
> On Tue, Sep 22, 2020 at 9:30 AM Michalis Kamburelis
> <michalis.kambi at gmail.com> wrote:
> >
> > Andreas Plesch <andreasplesch at gmail.com> wrote:
> > >> But I don't see the proposed alternative solution as valid. If we
> > >> prevent reusing Appearance or Material or geometry nodes, then we lose
> > >> an important property of a model format design. (That other formats
> > >> like glTF allow, and authoring tools like Blender explicitly support.)
> > >
> > >
> > > I think gltf just allows reuse of data components of a geometry or a texture, not the complete geometry or appearance.
> >
> > glTF has a mechanism to reuse glTF materials (primitive links to
> > material index,
> > https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#meshes
> > ).
> >
> > And "glTF material" is probably more like "X3D appearance" than "X3D
> > material". E.g. glTF material also specifies things like alpha
> > blending mode and alpha cutoff (neither of which has an official
> > analogy in X3D spec, but one has CGE / InstantReality extension in
> > Appearance.blendMode, one has X3DOM extension in Appearance.
> > alphaClipThreshold). It's not a perfect correspondence though.
>
> ok. Complete materials can be reused in gltf.
>
> >
> > Indeed glTF doesn't have a direct mechanism to reuse whole primitive
> > with a different appearance. Since it expresses indexes as a buffer
> > (unlike IndexedFaceSet.coordIndex), copying the "meat" of geometry is
> > easy in case of glTF.
>
> So perhaps the design goal would be to make it easy in x3d as well ?
>
> >
> > >> Reusing the "meat" of the geometry is quite involved, as not
> > >> everything is prepared for this:
> > >
> > >
> > > Still, this is as x3d currently is designed as I understand it.
> >
> > Right now you can easily reuse a mesh (IndexedFaceSet) by DEF / USE in
> > X3D. Like in https://github.com/michaliskambi/x3d-tests/blob/master/pbr/enhanced_phong_material/mapping_second_shape_reusing_geometry.x3dv
> > , "geometry USE MyMesh". This is possible since mesh doesn't have
> > direct links to a material.
>
> Of course. I rather wanted to point out that currently in x3d you
> would reuse a coordinate node, and would have to copy an index field.
>
> > >
> > >>
> > >> - For example indexes are not "wrapped" in another node in an
> > >> IndexedFaceSet, so they would just have to be repeated. Unless we
> > >> invent a new node "Indexes { MFInt32 index }" but it would complicate
> > >> the overall design, and be a significant compatibility break from X3D
> > >> 3.
> > >
> > >
> > > True, perhaps we need such a break.
> >
> > I think that would be a big compatibility break :) Every
> > IndexedFaceSet will be broken if we require to "wrap" indexes in a new
> > node. So nearly all X3D 3 models would need to be reworked into X3D 4.
>
> Yes but it is worth considering. v3 models of course still work in v3.
> The required reworking can be easily automated.
>
> > Unless we'll allow both methods (use "SFNode coordIndexNode" if
> > non-NULL, otherwise fallback to "MFInt32 coordIndex"). But this then
> > complicates our spec with a "compatibility cludge".
> >
> > >
> > >>
> > >> - Also such reuse doesn't allow the browser to easily "see" that we're
> > >> not reusing geometry. If a browser has geometry-specific resources
> > >> (like OpenGL VBOs) that could be reused, now it can just check that 2
> > >> geometry nodes have equal references, and advise the author to reUSE
> > >> the geometry nodes. If we instead make direct reusing of geometry
> > >> nodes impossible (and the author can only reuse the "meat") then the
> > >> browser would have to make field-by-field comparison (complicated, as
> > >> it should account for various geometry nodes).
> > >
> > >
> > > not sure if thinking about implementation details should guide a design.
> >
> > In general, IMHO: If we make an efficient implementation of some
> > common use-case hard (harder than it is in e.g. glTF, or in Blender's
> > information) then I say we did a poor job :) A proper design should be
> > guided by the practical capabilities of the underlying systems. All
> > real-time graphic API have a concept similar to "per-vertex data",
> > "texture data", "compiled shader" etc.
>
> Hopefully a good design would also make the implementation efficient
> if not easy.
>
> > But I agree that not everything needs to be a "common use-case", we
> > should limit this label to really important things.
> >
> > If anything, I would say that reusing geometries is not really
> > critical, so maybe there's a field to improve here.
> >
> > But reusing materials or appearances remains critical. In this case
> > it's also about authoring tools usage. For authors, reusing materials
> > or appearances makes intuitive sense too. Blender exposes this feature
> > directly.
>
> Agreed. But the only requirement then is to decouple texture
> coordinates from Appearance/Material (which is already the case in
> v3).
>
> >
> > >> Indeed it is tricky :) I certainly see the reason for this discussion,
> > >> but I don't yet see any better solution than the current mapping
> > >> SFString.
> > >
> > >
> > > I do not think gltf has a similar mapping mechanism ?
> > >
> >
> > See my answer to Don in the nearby thread :)
>
> Apologies, I missed that.
>
> >
> > glTF doesn't have exactly this mechanism, but it has a simplified
> > version of it. In particular glTF:
> >
> > - limits the number of textures to 2 (but X3D 3 has already committed
> > to supporting arbitrary number of texture slots with multi-texturing)
> >
> > - glTF doesn't allow to specify mapping names as strings, instead they
> > remain just integers on one side. So just 0 or 1. I'm cool with
> > changing our mapping to be integers, but this was rejected as not
> > descriptive.
>
> Well, is it then a major step to say "emissiveTexCoord" instead of
> "texCoord_1" ?
>
> > Pasting here the relevant parts:
> >
> > """
> > The important things:
> >
> > 1. a mesh can expose a number of attributes, in particular TEXCOORD_0
> > and TEXCOORD_1 (identified just by strings in JSON, which can be
> > directly used for our SFstring mapping). See
> > https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#meshes
> > .
> >
> > 2. a material can indicate using a specific texture with a texture
> > coordinate number (0 or 1, matching to TEXCOORD_0 and TEXCOORD_1). See
> > https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#materials
>
> I think this means then saying
>
> normalTexCoord USE="TEXCOORD_1"
>
> where TEXCOORD_1 was previously defined for another texture (say
> emissiveTexCoord).
>
> Let's see if I can translate that to your example B:
>
> Shape {
> appearance DEF MyAppearance Appearance {
> material DEF MyMaterial Material {
> diffuseTexture ImageTexture { url "diffuse.png" }
> normalTexture ImageTexture { url "normal-map.png" }
> specularTexture ImageTexture { url "specular.png" }
> }
> }
> geometry DEF MyMesh IndexedFaceSet {
> coordIndex [ 0 1 2 3 ]
> coord Coordinate {
> point [
> 0 0 0, ...
> ]
> }
> diffuseTextureCoord DEF TEXCOORD_0 texCoord {
> point [
> 0 0,
> 4 0,
> 4 4,
> 0 4,
> ]
> }
> normalTextureCoord USE TEXCOORD_0
> specularTextureCoord DEF TEXCOORD_1 texCoord {
> point [
> 0.1 0,
> 40 0,
> 4 40,
> 0 4,
> ]
> }
>
> }
> }
> }
>
> # EXAMPLE B First, define one shape that defines also MyAppearance, see above.
>
> # Then define another shape using MyAppearance.
> Shape {
> appearance USE MyAppearance
> geometry IndexedFaceSet { # some different mesh
> coordIndex [ 0 1 2 3 4 5 .... ]
> coord Coordinate {
> point [
> ....
> ]
> }
> diffuseTextureCoord DEF B_TEXCOORD_0 texCoord {
> point [
> ...
> ]
> }
> normalTextureCoord USE B_TEXCOORD_0
> specularTextureCoordinate DEF B_TEXCOORD_1 texCoord {
> point [
> ...
> ]
> }
>
> }
> }
> }
>
> That seems to work ?
>
> Regards, -Andreas
>
> PS: I should check how x3dom currently does it.
>
> > So multiple meshes can use the same material. They only need to
> > support the required number of texture coordinates. In our case, it
> > would mean they need to expose the required texture mapping values.
> >
> > So it is similar to the mapping SFstring I propose, except we changed
> > mapping to a more general SFstring while in glTF it is an integer.
> > (This change was after our discussion some time ago; initially I
> > proposed to make it SFInt32, which would map 100% to glTF).
> > """
> >
> > Regards,
> > Michalis
>
> --
> Andreas Plesch
> Waltham, MA 02453
More information about the x3d-public
mailing list