[x3d-public] TwoSidedMaterial deprecation by adding Appearance backMaterial field

[Don Brutzman]

Dick, Michalis and I had an excellent discussion reviewing this issue today.

We will proceed with option 2.2. below and see how that works out.

a. TwoSidedMaterial becomes Appearance/material/backMaterial for Phong rendering (VRML/X3D3 rendering).
b. Thus allow two-sided material in PBR rendering as well.
c. TwoSidedMaterial at a minimum deprecated.

OBTW meanwhile am concerned that we might need to remove it entirely from X3D4.  The functionality of Material/TwoSidedMaterial/PhysicalMaterial is achievable in the scene graph, but we might not be able to make validation of content models tractable, it opens the door to the dreaded "XML nondeterministic content model" validation difficulties, which also manifests in other ways (JSON encoding).  X3DMaterialNode object type may help reconcile this...  We'll see.

We also discussed potential specification prose.  More work on that certainly, it will converge.

Go Michalis Go!   8)

On 2/3/2020 1:19 AM, Michalis Kamburelis wrote:
> Yes, if we choose the option "two-sided materials with different colors are useful, let's introduce backMaterial" then PBR needs are satisfied. The field would accept X3DMaterialNode (just like front "Appearance.material") and allow PhysicalMaterial.
> 
> An appropriate prose can be added to make sure the front and back materials match (that you cannot put Material in front, PhysicalMaterial in back etc., and textures match -- to make things easy to implement). In my PBR PR there's a prose at TwoSidedAnyMaterial that can be adapted:)
> 
> I agree that this is more performant than two separate meshes.
> 
> Regards,
> Michalis
> 
> pon., 3.02.2020, 02:01 użytkownik Andreas Plesch <andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>> napisał:
> 
>     There is a chicken and egg problem. Without the functionality being
>     available for modelers, it may not be missed. A more interesting
>     analyses may be how many models would benefit from a back material
>     option. Models which only have an outside like most gaming assets are
>     not in this class of models. Abstract surfaces from math or physics or
>     are more likely to benefit from distinguishing a back and front. There
>     may be other classes of models.
> 
>     The other arguments for two sided material is that it is more
>     performant than two separate surfaces.
> 
>     For PBR, could the backMaterial value not just be allowed to be a
>     PhysicalMaterial ?
> 
>     But simplification in itself is valuable, too.
> 
>     On Sun, Feb 2, 2020 at 4:16 PM Michalis Kamburelis
>     <michalis.kambi at gmail.com <mailto:michalis.kambi at gmail.com>> wrote:
>      >
>      > > Wondering what you think about compatibility with PBR upgrades: does allowing either legacy TwoSidedMaterial or equivalent Appearance/material/backMaterial approaches result in major difficulty implementing PBR?  If two-sided materials are a problematic drawback for PBR, that is important to know.
>      >
>      > Let us carefully distinguish two cases here:
>      >
>      > 1. Two-sided materials *with the same colors on both sides* are easy
>      > to implement. And most software / formats supports them, I think.
>      >
>      >     This is called "two-sided lighting" commonly, and one just inverts
>      > a normal vector before calculations to do it.
>      >
>      >     These materials are also already possible in X3D thanks to the
>      > "solid" field. As Andreas found, X3D specification of "solid" already
>      > includes wording to perform two-sided lighting in this case. So, no
>      > new X3D fields are necessary, and TwoSidedMaterial node is not
>      > necessary.
>      >
>      > 2. Two-sided materials *with different color on front / back sides*
>      > are a small burden to implement. It is the same burden for Phong as
>      > well as for PBR materials. You need to pass two sets of colors, and
>      > switch between them.
>      >
>      >     It's not a *major* burden. They are still relatively easy. I'm
>      > mostly arguing because I don't see this burden as "justified".
>      >
>      >     (Note that in X3Dv4, materials can also refer to textures, but in
>      > this case I would say that both front and back must refer to the same
>      > texture nodes.)
>      >
>      >     That is why I argue in favor of just deprecating this option.
>      >
>      >     For example: CGE doesn't implement TwoSidedMaterial with
>      > separateBackColor=TRUE. And I don't plan to implement it soon -- until
>      > I get a report asking me to implement it. I just don't see it as
>      > useful enough, when other software / formats doesn't support it
>      > either. You will not be able to export such materials from Blender any
>      > time soon, anyway. glTF doesn't have it either, so you don't need it
>      > to convert glTF -> X3D.
>      >
>      >     Two-sided materials *with different color on front / back sides*
>      > also require some action on the spec side. Because the current
>      > TwoSidedMaterial is only for Phong material. So the decision about
>      > this affects what to do with PBR.
>      >
>      >     My point  of view: We need to decide whether two-sided materials
>      > with different front / back colors are useful.
>      >
>      >     2.1. (my view) They are not useful (and are some burden to
>      > implement). So let's just deprecate "TwoSidedMaterial", and be done
>      > for X3D 4.0. If users report they are needed, then in X3D 4.1 we add
>      > "backMaterial". The browsers can  of course keep supporting
>      > "TwoSidedMaterial" forever, we just make it clear to users to not rely
>      > on it.
>      >
>      >     2.2. (your view, as I understand it) They are useful. So we
>      > deprecate TwoSidedMaterial, and add "backMaterial" in X3D 4.0. This
>      > way this feature remains available for both Phong and PBR materials.
>      > IOW, if we decide that it is useful -> it has to available for both
>      > Phong and PBR materials, to keep them both full-featured.
>      >
>      >     I'm cool to be persuaded to 2.2 :) My opinion is definitely not in
>      > the stone. But I would really like to see some real-world cases when
>      > they are used by 3D artists. I'm arguing now just from my experience
>      > -- I never saw this feature used, or requested, by 3D artists. Of
>      > course my experience is limited to my use-cases :)
>      >
>      > Regards,
>      > Michalis
> 
>     -- 
>     Andreas Plesch
>     Waltham, MA 02453
> 

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman