[x3d-public] TwoSidedMaterial

[Andreas Plesch]

I checked the x3dom implementation of TwoSidedMaterial. It is more
efficient, eg. faster than having two separate Shapes and Geometries for
front and back since it allows rendering of both faces in one call to the
GPU shader. If separateBackColor is requested the shader is modified to
check on the fly with gl_frontfacing (
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/gl_FrontFacing.xhtml)
if the back is rendered and if so use the back colors instead of the front
colors. That is pretty much all that is required.

But it may still be worthwhile to trade a bit of performance of a rarely
used feature for an opportunity to simplify.

I think the fact that after an authors sees missing back faces
TwoSidedMaterial is easier to discover than the tiny looking solid field
and its equivalent functionality, helps explain why it is fairly popular.
The examples probably cover the solid field pretty well. It would still
help to make solid=false the default. It is a more drastic change but may
be ok for a new major version of x3d.





---on the phone---


On Tue, Jan 21, 2020 at 11:11 AM Andreas Plesch <andreasplesch at gmail.com>
wrote:
>
> Thinking about PBR, what would be the consequence of not having a
> TwoSidedPhysicalMaterial ?
>
> I think it means that two sided behaviour would then be only
> achievable with solid=true and duplicate geometries with opposing
> normals each with its own PhysicalMaterial. This does not need to
> impact decisions on TwoSidedMaterial, it appears. PBR is new and how
> to do two sided lighting would also be new for PhysicalMaterial. While
> it would be nice to have parallelism with PhongMaterial, it is not a
> requirement.
>
> But I think I am changing my mind to be more in favor of just
> deprecating TwoSidedMaterial completely although it is harder for
> normal users then to generate the effect. I am not sure, however, that
> x3dom implements the ccw field for primitive geometries like Sphere
> correctly although it may.
>
> If there would be more frequent opportunities to update the spec., I
> would probably prefer to keep TwoSidedMaterial but mark it as on the
> way out, deprecated, and then remove it in the next version. But
> perhaps it is time to remove it now.
>
>
> On Tue, Jan 21, 2020 at 10:32 AM Michalis Kamburelis
> <michalis.kambi at gmail.com> wrote:
> >
> > Andreas Plesch <andreasplesch at gmail.com> wrote:
> > >
> > > There is movement around TwoSidedMaterial. See
> > >
> > > https://github.com/castle-engine/view3dscene/issues/23
> > >
> > > and
> > >
> > >
http://web3d.org/pipermail/x3d-public_web3d.org/2019-December/011594.html
> > >
> > > I would vote to keep a version of it since the alternative of
manually doubling the geometry with inverted normals is too awkward for
normal users.
> > >
> >
> > If we keep TwoSidedMaterial (with sepatateBackColor=true possibility),
> > then we also need a solution for PBR for this. So my proposed
> > TwoSidedAnyMaterial from https://github.com/Web3DConsortium/X3D/pull/8
> > would be relevant. It allows to make two-sided Phong Material or
> > two-sided PhysicalMaterial.
> >
> > ( I don't have an opinion here, whether we should keep
> > TwoSidedMaterial, or remove it and instead have a simple boolean field
> > "twoSided", I just note that *if* we decide that TwoSidedMaterial is
> > useful, then necessarily also new TwoSidedAnyMaterial is useful, to
> > have the same capabilities for Phong and physical materials. )
> >
> > Personally, I never saw real use-cases for TwoSidedMaterial with
> > separateBackColor=true, but maybe my needs were specific :) If many
> > people use with separateBackColor=true, then we should reconsider
> > keeping it indeed.
> >
> > > There is a need, however, to clear up some confusion. As far as I can
judge there is no need for separateBackColor. It should always be true
since this case appears to be the main point of the node.
> > >
> >
> > As per my comments in
> > https://github.com/castle-engine/view3dscene/issues/23 -- I think that
> > right now the specification says something different (solid=false with
> > one-sided Material means that back faces are black). It's also
> > somewhat consistent with implementation (using OpenGL[ES] etc.):
> >
> > - one thing determines backface culing ("solid"), like
glEnable(GL_CULL_FACE)
> >
> > - another, independent thing controls whether the "back" faces have
> > lighting calculated correctly (using TwoSidedMaterial instead of
> > Material). This is typically a code in GLSL shader that inverts a
> > normal if gl_FrontFacing==false.
> >
> > But I could be persuaded to your approach :) I see your point -- right
> > now we have some combinations that aren't really useful:
> >
> > - Using solid=false with one-sided Material is hardly useful, as
> > authors don't really want to see pure black faces.
> >
> > - Using solid-true with TwoSidedMaterial isn't very useful, since you
> > activate two-sided lighting calculation, but then don't render back
> > faces.
> >
> > As I understand, you would prefer to simplify it.
> >
> > - Connect whether "the back faces are visible" with "the back faces
> > have correct lighting calculated" into a single feature, activated in
> > one place (by "solid" field).
> >
> > - And then the only purpose of TwoSidedMaterial would be to achieve
> > *different* colors on front vs back faces.
> >
> > This would actually be somewhat aligned with current CGE
> > implementation too. In CGE I actually *sometimes* realize Material as
> > two-sided (in Phong shading),
> >
https://castle-engine.io/x3d_implementation_shape_extensions.php#section_ext_shading
> > .
> >
> > > Also, there needs to be clarification how solid=true and
TwoSidedMaterial interact. I think x3dom lets TwoSidedMaterial win over
solid=true in the intent to render back faces. Most other browser probably
let solid=true win, eg. will not render back faces at all even with a
TwoSidedMaterial.
> >
> > The current X3D specification is clear here, IMHO:
> >
> > The "solid" field determines whether back faces are visible. It is
> > unrelated to Material/TwoSidedMaterial. So the X3DOM behaviour is not
> > correct, IMHO.
> >
> > I'm not saying that we cannot change it :)
> >
> > Regards,
> > Michalis
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453



-- 
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200121/ebda20d4/attachment.html>