[x3d-public] beyond Blinn-Phong: PBR

[Andreas Plesch]

I should also say that 'channel' currently in x3dom dev is a field of
X3DTextureNode, not of Appearance:

 #X3D V3.2 utf8
PROFILE Interactive

Shape {
  appearance Appearance {
    material Material {
      diffuseTexture ImageTexture {
        channel 123
       ... }
      specularTexture ImageTexture {
        channel 666
        ... }
    }

The default channel is 0.

-Andreas

On Mon, Feb 11, 2019 at 2:01 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
>
> Yes, exactly, that would be the idea. Currently, x3dom restricts the
> "channel" values to 0 and 1 but it could be possible to use any
> number, and have an intermediate map from channel number value to
> actual uniform name.
>
> Is there another X3D node which is referenced by its index in an
> MFNode array ? Switch children come to mind.
>
> So another name for "xxxTextureCoordinateId" may be
> "xxxTextureCoordinateChoice".
>
> -Andreas
>
> On Mon, Feb 11, 2019 at 11:02 AM Michalis Kamburelis
> <michalis.kambi at gmail.com> wrote:
> >
> >  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
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453



-- 
Andreas Plesch
Waltham, MA 02453