[x3d-public] TwoSidedMaterial and X3DOneSidedMaterial
Don Brutzman
brutzman at nps.edu
Tue Sep 15 10:28:43 PDT 2020
[Posted with permission]
On 9/14/2020 1:05 PM, Michalis Kamburelis wrote:
> [replying]
>
> As for the usefulness of X3DOneSidedMaterialNode: we talked about this :) I wrote my thoughts on https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#why-do-we-need-new-x3donesidedmaterialnode-cannot-we-add-fields-like-emissivexxx-to-x3dmaterialnode .
>
> Basically, we can speculate "what might have been" ("maybe TwoSidedMaterial should not be in X3D?"), but the reality is that TwoSidedMaterial exists in the existing browsers implementations. And we cannot change it. Even drastically removing TwoSidedMaterial in X3D 4.0 would not change this, because browsers will likely want to keep supporting X3D 3 for some time still. Therefore, X3DOneSidedMaterialNode makes sense. Otherwise every browser would need to internally invent such concept on it's own (and possibly each browser would make some mistake along the way).
>
> As for Appearance.material + TwoSidedMaterial:
>
> We talked about this with Andreas on x3d-public mailing list some time ago. I can repeat my general reasoning below:
>
> The description of what happens when Appearance.material contains TwoSidedMaterial is already in the spec. I deliberately decided to keep it simple, instead of inventing rules "what overrides what". Which means that you can only put "TwoSidedMaterial" in "Appearance.material" (not in backMaterial), and in this case you must keep backMaterial = NULL. I see no reason to complicate this simple rule :) For example, nobody (neither specification nor authors) want to put "TwoSidedMaterial" into "backMaterial" -- it neither makes sense, nor does it open the door to any new functionality. So it should just not be allowed. In a practical situation, the way to go is very simple.
>
> If you have TwoSidedMaterial with separateBackColor=TRUE, then author either :
>
> - keeps "TwoSidedMaterial" in "Appearance.material" (the X3D 3 approach, deprecated but allowed in X3D 4)
>
> - or the author splits "TwoSidedMaterial" into two "Material" instances (one in "Appearance.material", one in "Appearance.backMaterial")
>
> And BTW, I still have not seen a "real-life" example of X3D model using TwoSidedMaterial with separateBackColor=TRUE :) I repeat my call from a few months ago: if someone uses this feature in real-life, I'd like to know about it. Until this happens, I consider "TwoSidedMaterial with separateBackColor=TRUE" (and thus, also "Appearance.backMaterial") something that has a very small usage. So, all the more reason to keep it simple (not complicated) in the spec :)
>
> Regards,
> Michalis
- - - - - - - - - - - - - - - - -
This has been a really valuable discussion Michalis... am mostly agreeing, as we consider all the concerns.
Am leaning towards our setting everything up and balancing tradeoffs for best long-term effect in X3D4.
Then, similar to your note below, we list everything a browser needs to do to properly support X3D4 rendering.
This might have some interesting design decisions as well. For example:
- TwoSidedMaterial node is deprecated,
- X3DOneSidedMaterialNode abstract interface was primarily created to avoid inconsistency problems for other nodes with respect to TwoSidedMaterial,
- X3DOneSidedMaterialNode adds little further value, it simply adds fields found in UnlitMaterial and PhysicalMaterial.
So we might decide, from a long-term perspective in the future, that avoiding X3DOneSidedMaterialNode is preferred after removing TwoSidedMaterial, since it will no longer be appropriate.
We might add prose to the (now-deprecated) TwoSidedMaterial node that
- if Appearance field has (for example) material TwoSidedMaterial and a separate backMaterial field defined, then the "backMaterial" field overrides to [material TwoSidedMaterial] field. In other words, only the front-sided fields of TwoSidedMaterial are active if both fields are present.
This approach might let us avoid defining X3DOneSidedMaterialNode abstract node type. The field-description prose can go elsewhere.
================================================================
Example cases for front, back, two-sided materials:
a. Appearance
material Material # active (simplest case)
backMaterial NULL # default material values
b. Appearance
material Material # active (common case)
backMaterial Material # active
c. Appearance
material NULL # default material values
backMaterial Material # active
d. Appearance
material NULL # default material values
backMaterial NULL # default material values
---
e. Appearance
material TwoSidedMaterial # all fields active
backMaterial NULL # (values obtained from TwoSidedMaterial)
f. Appearance
material TwoSidedMaterial # only front fields active
backMaterial Material # active
g. Appearance
material Material # active
backMaterial TwoSidedMaterial # only back fields active for backMaterial
f. Appearance
material TwoSidedMaterial # only front fields active for front
backMaterial TwoSidedMaterial # only back fields active for backMaterial
h. Appearance
material NULL # default material values for front
backMaterial TwoSidedMaterial # back fields active for backMaterial
================================================================
Given such a reconciliation, maybe we wouldn't need to deprecate TwoSidedMaterial?
Of possible interest is that animation tasks might be simplified (or at least more consistent) if Appearance.material and Appearance.backMaterial are available.
On 9/8/2020 11:59 AM, Michalis Kamburelis wrote:>
> Dick and I will be working further soon, planning to post a message summarizing the nature of whether X3D3 browsers loading X3D4 models (via whatever path they arrive) can claim some level of conformance. I think this is important for our transition forward, but not at the expense of correct design for best long-term success.
>
> Tricky business, important that we all understand and get best answers together. Thanks for your efforts Michalis.
>
>
> Admittedly I am very worried here about making a bad decision :) I believe I explained my view on the call, let me summarize it here too, to make it sure it is clear:
>
> In my eyes, if a browser that currently says "I handle X3D 3" wants to say "I handle X3D 4", then it is natural that this browser will have to do some additional work to claim conformance. That is, it is natural that "supporting X3D 4" implies something more than merely "accepting """#X3D V4.0""" header" :)
>
> Of course, we don't want to make it a terrible "burden" on browsers to get a reasonable level of X3D 4 conformance (reasonable profiles). But at the same time, we did introduce some features in X3D 4 that we really want to encourage browsers to implement. X3D authors should be able to expect such features from an X3D browser. This way, there is more benefit from X3D 4, as browsers that "claim X3D 4 support" actually offer X3D authors some capabilities beyond X3D 3.
>
> This means e.g.
>
> - encouraging all browsers to support UnlitMaterial (because it should be trivial to all existing X3D 3 implementations, and it is useful as explained on https://github.com/michaliskambi/x3d-tests/wiki/Why-is-UnlitMaterial-useful )
>
> - encouraging all browsers to support extra Material parameters (because it is common practice in modern renderers; I very expect that X3D renderers are already capable of this, as e.g. InstantReality CommonSurfaceShader extension has a similar idea as X3D 4 Phong Material)
>
> - encouraging browsers to support PhysicalMaterial (because it is a modern way of rendering, and it matches glTF, Blender etc.)
>
> Trying to make it differently (which I fear, as it would be a bad decision) would mean saying "if you want to support X3D 4, just accept the #X3D V4.0 header; you don't need to implement anything beyond X3D 3". This would make life very easy for X3D browsers, but it would also make "supporting X3D 4" an empty statement. An X3D author could not expect anything interesting from a browser that "supports X3D 4" beyond what was already in X3D 3.
>
> Moreover, it would make a problem in levels. Currently, our "levels" in components sort things from "most important, most useful to authors, and easy to implement" (early levels) to "least important, less useful to authors and/or hard to implement" (later levels). And that's good. This also means that some new features have to be inserted "in between" existing levels. As I mentioned on the call, I would lament if "PhysicalMaterial" (important node) or "UnlitMaterial" (important *and* easy to implement node) are in *later* level than e.g. "FillProperties". This would mean that Castle Game Engine can never formally claim conformance with Shape component at the level with PhysicalMaterial, because CGE will realistically never implement FillProperties (because I consider FillProperties to have extremely low usage, and it isn't expressed in e.g. glTF or Blender anyway).
>
> Feel free to quote my opinion on this :)
>
> Regards,
> Michalis
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
More information about the x3d-public
mailing list