[x3d-public] TwoSidedTexture node

[Michalis Kamburelis]

2017-11-03 18:36 GMT+01:00 Andreas Plesch <andreasplesch at gmail.com>:
> There was a question a while ago on x3dom issues if there is a
> TwoSidedTexture node similar to the TwoSidedMaterial node:
>
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/shape.html#TwoSidedMaterial
>
> There is MultiTexture so it is not unreasonable to expect a TwoSidedTexture.
>
> Is there a way currently to have a different texture on the backside
> apart from duplicating the shape ?
>
> What could be good way to generalize such that different material,
> texture, or common surface shader nodes can be used simultaneously on
> backs and fronts ?
>
> Perhaps a BackAppearance node ?
>

1. BackAppearance seems a bit "too flexible to implement" for me ---
it would also allow for different "shaders" for front and back faces,
since I guess "Appearance.shaders" can be different than
"BackAppearance.shaders". And I have no idea how to implement such
thing (with a single draw call :) ). Typically only the fragment
shader really knows which side you're looking at.

2. In fact, even TwoSidedTexture seems a bit uneasy to implement for
me, if the children of TwoSidedTexture could be any texture node,
including MultiTexture. You could then specify that

- front side has MultiTexture e.g. with 3 textures inside (e.g. some
cubemap multiplied by some 2d texture multiplied by some 3d texture)
- back side has MultiTexture e.g. with 2 textures inside (e.g. some 2d
texture added to some other 2d texture)

IOW, you could have different texture logic/equations for front and
for back side. I can implement this :), but I'm not sure is this
acceptable to all implementors.

In contrast, the existing TwoSidedMaterial has much simpler
implementation: both front and back sides have lighting calculated
using the exact same equations, only the parameters to these equations
are different depending on which side you're looking at.

Following this, I think a safer version of TwoSidedTexture would be
something that cannot have MultiTexture as a children, and maybe even
that requires that both front and back textures are the same kind
(both 2d, or both 3d, or both cubemaps...). And MultiTexture can have
(as a children) a TwoSidedTexture. So then you could do (in classic
encoding):

Appearance {
  texture TwoSidedTexture {
    front ImageTexture { url "front.png" }
    back ImageTexture { url "back.png" }
  }
}

or

Appearance {
  texture MultiTexture {
    texture [
      ImageTexture { url "first_layer.png" }
      TwoSidedTexture {
        front ImageTexture { url "second_layer_front.png" }
        back ImageTexture { url "second_layer_back.png" }
      }
    ]
  }
}

I think this would be OK to implement :)

3. I'm not sure how much is such TwoSidedTexture needed, in practice.
You can already achieve a similar effect by reusing the same geometry
but with different "ccw" value. E.g.

----
Shape {
  geometry IndexedFaceSet {
    DEF MyCoord Coordinate { ... }
    ccw TRUE
    solid TRUE # this is the default, I just emphasise it here
    coordIndex ...
  }
  appearance Appearance {
    # configure Material, Texture, etc. for ccw=true side
  }
}
Shape {
  geometry IndexedFaceSet {
    USE MyCoord
    ccw FALSE
    solid TRUE # this is the default, I just emphasise it here
   coordIndex ... # unfortunately, you have to repeat coordIndex here
  }
  appearance Appearance {
    # configure Material, Texture, etc. for ccw=false side
  }
}
----

The above is not perfect (a renderer will make 2 draw calls, and you
need to duplicate coordIndex contents). But it already works, in all
browsers, and you can change any Appearance parameter this way :)

Regards,
Michalis