[x3d-public] beyond Blinn-Phong: PBR

[Andreas Plesch]

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