[x3d-public] Specification editors mantis issues: PBR review

Tue Aug 25 07:53:45 PDT 2020

OK thanks for clarification Michalis - None == default Unlit.

On Tue, Aug 25, 2020 at 8:44 AM Michalis Kamburelis <
michalis.kambi at gmail.com> wrote:

> Thanks Doug!
>
> My concern here is more about the consistency of the specification, not
> technical feasibility. I would not like to introduce various combinations,
> just because they can be implemented :) If the existing combinations cover
> all use-cases, then there is no need to introduce "alternative ways of
> doing things", esp. if they would mean complicating the spec (and
> therefore, also complicate code of all X3D browsers).
>
> Also, the "None" should be equivalent to "Unlit with everything as
> default" now :) That is how it is deliberately specified, and I want to
> keep this relation forever :) In Castle Game Engine, I removed all special
> cases of "no material", because now they can be implemented using the same
> UnlitMaterial code/shaders. That is, "material NULL" is exactly 100%
> equivalent to "material UnlitMaterial { }" now.
>
> Regards,
> Michalis
>
>
> wt., 25 sie 2020 o 15:28 GPU Group <gpugroup at gmail.com> napisał(a):
>
>> Appearance.backMaterial .material and None
>> In freewrl I have a None type material. And in shaders I have an array of
>> [2] structs, each struct holding one material and the struct having one
>> enum field for None, Unlit, Physical, Regular. In frag shader I check
>> glFrontFacing and choose the material struct from the array of 2.
>> And that means I can have None on front face and anything on backface or
>> vice versa.
>> That means its technically possible and I didn't have to work too hard at
>> it - just tinkered from how we were doing TwoSidedMaterial.
>> -Doug
>>
>> On Mon, Aug 24, 2020 at 1:49 PM Michalis Kamburelis <
>> michalis.kambi at gmail.com> wrote:
>>
>>> Hi!
>>>
>>> Sorry again that I could not attend our scheduled meeting today. We'll
>>> coordinate a new meeting, and in the meantime I'll try to address the
>>> questions by email, so that the public mailing list has all the info :)
>>>
>>> Answers are inline below.
>>>
>>> Don Brutzman <brutzman at nps.edu> wrote:
>>>
>>>> ---
>>>>
>>>> 2. Spec questions.
>>>>
>>>> a. see new inquiries today regarding PointProperties from Andreas and
>>>> Holger.  Let's continue/contribute on that thread please.
>>>>
>>>
>>> I do not see input from Holger in the PointProperties thread. If there's
>>> some communication off-list, maybe because someone forgot to use "Reply
>>> All", please resend it to the mailing list :)
>>>
>>>
>>>>
>>>> ---
>>>>
>>>> b. 12.2.2 Appearance characteristics
>>>>
>>>> Seems like we can remove the sentences starting with "This set of nodes
>>>> may be extended by creating new nodes derived from..."
>>>>
>>>
>>> Sure, yes.
>>>
>>>
>>>>
>>>> If so, we can likely merge the two corresponding bullet lists.
>>>>
>>>> We might also remove the sentence "This set may be extended by creating
>>>> new nodes derived from the abstract X3DTextureNode base class as defined in
>>>> 18.3.2 X3DTextureNode."
>>>>
>>>> We don't have to give guidance about extending.  (Prototypes are based
>>>> on the first node within ProtoBody so those rules are separately defined.)
>>>>
>>>
>>> Yes, agreed.
>>>
>>>
>>>>
>>>> ---
>>>>
>>>> c. 12.2.3 Two-sided materials
>>>>
>>>> - small wording changes in first section.
>>>>
>>>> - Can't a model Appearance without a material field still have a
>>>> backMaterial field?
>>>>
>>>
>>> No, because that would not be clear.
>>>
>>> Using "backMaterial" means that you want back faces to have different
>>> colors than front faces. Using "backMaterial" without "material" would mean
>>> that you didn't specify what are the front colors. If we would allow this,
>>> we would have to make a decision between two sub-optimal choices:
>>>
>>> 1. "backMaterial <> NULL" and "material = NULL" => means that front is
>>> white unlit, while back is "as specified". This is a sub-optimal choice,
>>> because it is inconsistent with "backMaterial = NULL" and "material <>
>>> NULL", in which both front and back materials are "as specified".
>>>
>>> 2. "backMaterial <> NULL" and "material = NULL" => means that front is
>>> just like back. This is a sub-optimal choice, because user could achieve
>>> the same effect by moving the node from "backMaterial" to "material", and
>>> then it would be also compatible with browsers that don't implement
>>> "backMaterial" (e.g. because they don't yet support all X3D v4 features, or
>>> they don't plan to implement 2-sided materials with different colors). So
>>> authors should place the material node in "material" field to get this
>>> behaviour.
>>>
>>> So it seems like the optimal choice is to prohibit this. That is,
>>> "backMaterial <> NULL" is only allowed when "material <> NULL".
>>>
>>>
>>>>
>>>> - If Appearance material has TwoSidedMaterial and backMaterial has
>>>> another node, can't backMaterial take precedence?
>>>>
>>>
>>> No, IMO.
>>>
>>> That would mean we ignore part of the information ("material" value),
>>> and also that we don't know what is "front" color. If anything,
>>> TwoSidedMaterial should take precedence, because TwoSidedMaterial has full
>>> information. But then, TwoSidedMaterial is deprecated, so it doesn't feel
>>> right that it takes precedence.
>>>
>>> And this means we have a decision with no good solution :)
>>>
>>> So it is better to simply prohibit specifying two things that conflict
>>> with each other. Authors should not use TwoSidedMaterial and backMaterial
>>> at the same time. Conversion from TwoSidedMaterial to backMaterial approach
>>> is straightforward, and can be automated. We should encourage authors to
>>> make this conversion :)
>>>
>>>
>>>> - Appearance only has one texture field.  Why are you talking about
>>>> DEF/USE?
>>>>
>>>
>>> Because textures are also inside material nodes. They can be DEF/USEd
>>> between front and back material. The prose should make it clear:
>>>
>>>
>>> """
>>> Use the same textures with the same mapping.
>>> In other words, the values of the fields <i>xxxTexture</i>
>>> and <i>xxxTextureMapping</i> documented in
>>> <a href="#TextureMapping">12.2.4 Texture mapping specified in material
>>> nodes</a>
>>> shall be equal for both front and back materials.
>>> """
>>>
>>>
>>>>
>>>> We need to discuss the various cases, seems like the allowed
>>>> combinations might be stated more simply.
>>>>
>>>> I suspect that if we primarily define material and backMaterial, then
>>>> note how TwoSidedMaterial can be used, that best sets us up for long term
>>>> (when TwoSidedMaterial is no longer supported).
>>>>
>>>
>>> Agreed, we indeed should focus on (new, non-deprecated) backMaterial
>>> behaviour prose.
>>>
>>> The TwoSidedMaterial can then be explained like "if you use
>>> material=TwoSidedMaterial, then it is equivalent to using material=Material
>>> and backMaterial=Material like this: ...." and here we can write a prose
>>> and an example.
>>>
>>>
>>>>
>>>> ---
>>>>
>>>> 12.2.4 Texture mapping specified in material nodes
>>>>
>>>> - This section doesn't make much sense, especially the "xxxTexture"
>>>> phrasing (I think you mean "emissiveTexture and normalTexture" in
>>>> X3DOneSidedMaterialNode).  Let's discuss please.
>>>>
>>>> Striving for simplification and clarity as best way to achieve
>>>> correctness.
>>>>
>>>
>>> It is an extremely important section :) And by "xxxTexture" I mean **all
>>> "xxxTexture" fields in all XxxMaterial nodes**. So
>>>
>>> - emissiveTexture,
>>> - normalTexture,
>>> - diffuseTexture,
>>> - specularTexture,
>>> - ambientTexture,
>>> - baseTexture,
>>> - metallicRoughnessTexture,
>>> - occlusionTexture.
>>>
>>> Yes, there are a lot of them. That's how modern materials work (in glTF,
>>> Blender, Unity, everywhere?). *All* material parameters can be adjusted by
>>> some texture.
>>>
>>>
>>>>
>>>> ---
>>>>
>>>> 12.2.5 Coexistence of textures specified in material nodes with the
>>>> "Appearance.texture" field
>>>>
>>>> This might be greatly simplified and merged if we get prior
>>>> simplifications done well.
>>>>
>>>> ---
>>>>
>>>> 12.3.4 X3DOneSidedMaterialNode
>>>>
>>>> - Your "Editorial note: We consider merging this abstract node with
>>>> X3DMaterialNode."
>>>>
>>>> Am thinking we should keep both of these in order to support Material
>>>> (which won't change) and X3D3 versus X3D4 PBR rendering.
>>>>
>>>
>>> Supporting Material has no relation to this decision. Of course we will
>>> support Material (with Phong lighting model, 100% compatible with X3D 3).
>>>
>>> But this is not related to the decision "do we merge X3DMaterialNode
>>> with X3DOneSidedMaterialNode". This decision is dictated by the need to
>>> support TwoSidedMaterial for the time being.
>>>
>>> I'm also after *not* merging (IOW, not changing the current spec), my
>>> reasons are 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
>>> .
>>>
>>>
>>>
>>>>
>>>> - "tangent space" discussion can be simplified.
>>>>
>>>
>>> Agreed, definitely. I got carried away when writing this :) The "tangent
>>> space" term, especially when used in the context of normalmaps, is probably
>>> rather clear to everyone, without my long and clumsy explanations in the
>>> spec. After my sentence
>>>
>>>    """The normals are provided in the <i>tangent space</i>"""
>>>
>>> ....I wrote a lot of text/examples that can be definitely
>>> removed/simplified.  Looking forward to simplifying this together :)
>>>
>>>
>>>>
>>>> ---
>>>>
>>>> 12.4.5 Material
>>>>
>>>> - You have a number of textures (seven total!) but only two are listed
>>>> in X3DOneSidedMaterialNode.  Shouldn't they be in the abstract node type
>>>> also?
>>>>
>>>
>>> No.
>>>
>>> The very idea of the abstract type "X3DOneSidedMaterialNode" is that it
>>> serves as the ancestor for various other materials: Material,
>>> PhysicalMaterial, UnlitMaterial.
>>>
>>> The "X3DOneSidedMaterialNode" is *not* a duplication of "Material", that
>>> would not be useful. The "X3DOneSidedMaterialNode" is an ancestor in OOP
>>> terminology, just like all other abstract nodes throughout X3D
>>> specification.
>>>
>>> Feel free to paste this answer to Mantis too. We'll talk about this at
>>> our next meeting. Thank you for review, looking forward to finishing this
>>> together :)
>>>
>>> Best regards,
>>> Michalis
>>> _______________________________________________
>>> x3d-public mailing list
>>> x3d-public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200825/aeea888b/attachment-0001.html>