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