[x3d-public] beyond Blinn-Phong: PBR

[Michalis Kamburelis]

 Andreas Plesch <andreasplesch at gmail.com> wrote:
>
> Michalis,
>
> well, the alternative would be add a SFInt32 'channel' field to
> X3DTextureCoordinate and X3DTextureTransform which then would be
> inherited by all derived nodes.
>
> It would have all the same advantages including sharing.
>
> MultiTextureXXX nodes would be only used for MultiTexture textures.
>
> BTW, the spec. does not spell out what to do if a
> MultiTextureCoordinate node is used as a choice inside another
> MultiTextureCoordinate node which is allowed by the signature and
> presumably schema. It is a minor and unrelated point since it is clear
> that this just leads to undefined behavior.
>
> The implicit mapping for MultiTexture between textures and texture
> coordinates/transforms by their index in their arrays feels
> underspecified to me but this also unrelated.
>
> The main disadvantage of introducing a 'channel' field is that the
> Geometry.texcoord and Appearance.textureTransform fields would need to
> become MFNode fields and that there is a perceived overlap with
> MultiTextureCoordinate. It would be also necessary to define if
> 'channel' is used with MultiTexture (ignore) and what to do if the
> same channel number is used for multiple texcoords ( undefined, or
> last one wins).
>
> The main advantage is for authors. Adding another set of texture
> coordinates would mean just adding another TextureCoordinate node. And
> then referring to its channel wherever the coordinates are used. It
> would be a more natural transition from a single set of texcoords to
> multiple sets. Also it is conceptually easier to understand for
> authors that all MultiTexture* nodes work together and only together,
> as they were originally designed.
>
> Hm, I was actually ready to say that precedence trumps all and that
> therefore just expanding the intended use of
> MultiTextureCoordinate/Transform is appropriate but I am not so sure
> anymore :)
>
> It is true, I believe, that elevating MutliTextureCoordinate/Transform
> for use with other nodes requires the least amount of spec. work.
>
> -Andreas
>

To be clear, you propose that one could write something like this:

"""
#X3D V3.2 utf8
PROFILE Interactive

Shape {
  appearance Appearance {
    material Material {
      diffuseTexture ImageTexture { ... }
      diffuseTextureCoordinateChannel 123
      specularTexture ImageTexture { ... }
      specularTextureCoordinateChannel 666
    }
    textureTransform [
      TextureTransform {
        channel 123
        translation 1 1
      }
    ]
  }
  geometry IndexedFaceSet {
    texCoord [
      TextureCoordinate {
        channel 123
        point [ ... ]
      }
      TextureCoordinateGenerator {
        channel 666
        mode "COORDS"
      }
    ]
  }
}
"""

I deliberately used wild channel numbers (123, 666) above to emphasize
that these are user-invented identifiers, and they bear no effect on
how the coordinates are actually passed to OpenGL. Am I right in
understanding your idea? There is no harm is assigning large channel
numbers, they are only used by the X3D browser to "connect it all
together". The browser sees that there are only 2 texture coordinates
(actually, only 1 explicit, since TextureCoordinateGenerator is
calculated in shader).

I'm not sure about this, but I'm no longer sure about my approach either :)

- There is a danger in your case that you use the same channel id
multiple times, as you mention. It should be disallowed IMHO, and
browsers encouraged to make at least a prominent warning (if not
error) in such case, otherwise I see it as potential for hard-to-find
bugs.

- Indeed, sharing is now possible, and it's even easier in your
version (you just always use "diffuseTextureCoordinateChannel 123",
whereas in my approach you can reuse TextureCoordinate node, but
various shapes will refer to it using different
"diffuseTextureCoordinateIndex XXX").

- And I like that you avoid introducing a new node (like
MultiTextureCoordinate), thus avoiding the problem "what happens if
one puts MultiTextureCoordinate inside MultiTextureCoordinate"
(answer: nobody knows, it's undefined).

- I would prefer to rename "channel" to something meaning "unique
identifier". But not "id", since CommonSurfaceShader already uses
"xxxTextureCoordinatesId" to mean "texture coordinate index", which is
actually the source of my initial idea... So, I guess I don't really
have a better name than "channel" :)

Still thinking, I see the advantages of both approaches.

( I guess we come to this from a bit different mindset. If you expect
all MultiTextureXxx nodes to be somehow forming a "one coherent
system", then using MultiTextureCoordinate/Transform for a different
purpose, without MultiTexture, may feel "dirty". For  me,
MultiTextureCoordinate/Transform were just a way to provide multiple
texture coordinates, and they were not that tightly coupled with
MultiTexture node. But I recognize that this is just a different way
of thinking, and both ways make sense :) )

Regards,
Michalis