<div dir="ltr">OK thanks for clarification Michalis - None == default Unlit.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 25, 2020 at 8:44 AM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thanks Doug!</div><div><br></div><div>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).<br></div><div><br></div><div>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.<br></div><div><br></div><div>Regards,</div><div>Michalis<br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">wt., 25 sie 2020 o 15:28 GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Appearance.backMaterial .material and None</div>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.<div>And that means I can have None on front face and anything on backface or vice versa.</div><div>That means its technically possible and I didn't have to work too hard at it - just tinkered from how we were doing TwoSidedMaterial.</div><div>-Doug</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 24, 2020 at 1:49 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Hi!</div><div><br></div><div>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 :)<br></div><div><br></div><div>Answers are inline below.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">---<br>
<br>
2. Spec questions.<br>
<br>
a. see new inquiries today regarding PointProperties from Andreas and Holger. Let's continue/contribute on that thread please.<br></blockquote><div><br></div><div>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 :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
---<br>
<br>
b. 12.2.2 Appearance characteristics<br>
<br>
Seems like we can remove the sentences starting with "This set of nodes may be extended by creating new nodes derived from..."<br></blockquote><div><br></div><div>Sure, yes.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If so, we can likely merge the two corresponding bullet lists.<br>
<br>
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."<br>
<br>
We don't have to give guidance about extending. (Prototypes are based on the first node within ProtoBody so those rules are separately defined.)<br></blockquote><div><br></div><div>Yes, agreed.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
---<br>
<br>
c. 12.2.3 Two-sided materials<br>
<br>
- small wording changes in first section.<br>
<br>
- Can't a model Appearance without a material field still have a backMaterial field?<br></blockquote><div><br></div><div>No, because that would not be clear. <br></div><div><br></div><div>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:<br></div><div><br></div><div>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".</div><div><br></div><div>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.<br></div><div><br></div><div>So it seems like the optimal choice is to prohibit this. That is, "backMaterial <> NULL" is only allowed when "material <> NULL".<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- If Appearance material has TwoSidedMaterial and backMaterial has another node, can't backMaterial take precedence?<br></blockquote><div><br></div><div>No, IMO.</div><div><br></div><div>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.</div><div><br></div><div>And this means we have a decision with no good solution :) <br></div><div><br></div><div>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 :)<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Appearance only has one texture field. Why are you talking about DEF/USE?<br></blockquote><div><br></div><div>Because textures are also inside material nodes. They can be DEF/USEd between front and back material. The prose should make it clear:<br></div><div><br></div><div><br></div><div>"""</div><div><table><tbody><tr><td id="gmail-m_7782457055730126022gmail-m_-6536638434524112123gmail-m_-5383362334160789510gmail-LC280">Use the same textures with the same mapping.</td>
</tr>
<tr>
</tr></tbody></table><table><tbody><tr><td id="gmail-m_7782457055730126022gmail-m_-6536638434524112123gmail-m_-5383362334160789510gmail-LC281"> In other words, the values of the fields <span><</span><span>i</span><span>></span>xxxTexture<span></</span><span>i</span><span>></span></td>
</tr>
<tr>
</tr></tbody></table><table><tbody><tr><td id="gmail-m_7782457055730126022gmail-m_-6536638434524112123gmail-m_-5383362334160789510gmail-LC282"> and <span><</span><span>i</span><span>></span>xxxTextureMapping<span></</span><span>i</span><span>></span> documented in</td>
</tr>
<tr>
</tr></tbody></table><table><tbody><tr><td id="gmail-m_7782457055730126022gmail-m_-6536638434524112123gmail-m_-5383362334160789510gmail-LC283"> <span><</span><span>a</span> <span>href</span>="<span>#TextureMapping</span>"<span>></span>12.2.4 Texture mapping specified in material nodes<span></</span><span>a</span><span>></span></td>
</tr>
<tr>
</tr></tbody></table> shall be equal for both front and back materials.</div><div>"""<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
We need to discuss the various cases, seems like the allowed combinations might be stated more simply.<br>
<br>
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).<br></blockquote><div><br></div><div>Agreed, we indeed should focus on (new, non-deprecated) backMaterial behaviour prose.</div><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
---<br>
<br>
12.2.4 Texture mapping specified in material nodes<br>
<br>
- This section doesn't make much sense, especially the "xxxTexture" phrasing (I think you mean "emissiveTexture and normalTexture" in X3DOneSidedMaterialNode). Let's discuss please.<br>
<br>
Striving for simplification and clarity as best way to achieve correctness.<br></blockquote><div><br></div><div>It is an extremely important section :) And by "xxxTexture" I mean **all "xxxTexture" fields in all XxxMaterial nodes**. So <br></div><div><br></div><div>- emissiveTexture, <br></div><div>- normalTexture, <br></div><div>- diffuseTexture, <br></div><div>- specularTexture, <br></div><div>- ambientTexture, <br></div><div>- baseTexture, <br></div><div>- metallicRoughnessTexture, <br></div><div>- occlusionTexture.</div><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
---<br>
<br>
12.2.5 Coexistence of textures specified in material nodes with the "Appearance.texture" field<br>
<br>
This might be greatly simplified and merged if we get prior simplifications done well.<br>
<br>
---<br>
<br>
12.3.4 X3DOneSidedMaterialNode<br>
<br>
- Your "Editorial note: We consider merging this abstract node with X3DMaterialNode."<br>
<br>
Am thinking we should keep both of these in order to support Material (which won't change) and X3D3 versus X3D4 PBR rendering.<br></blockquote><div><br></div><div>Supporting Material has no relation to this decision. Of course we will support Material (with Phong lighting model, 100% compatible with X3D 3).</div><div><br></div><div>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.</div><div><br></div><div>I'm also after *not* merging (IOW, not changing the current spec), my reasons are on <a href="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" target="_blank">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</a> .<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- "tangent space" discussion can be simplified.<br></blockquote><div><br></div><div>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 <br></div><div><br></div><div> """<span></span>The normals are provided in the <span><</span><span>i</span><span>></span>tangent space<span></</span><span>i</span><span>>"""</span></div><div><span><br></span></div><div><span>....I wrote a lot of text/examples that can be definitely removed/simplified. Looking forward to simplifying this together :)<br></span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
---<br>
<br>
12.4.5 Material<br>
<br>
- 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?<br></blockquote><div><br></div><div>No.</div><div><br></div><div>The very idea of the abstract type "X3DOneSidedMaterialNode" is that it serves as the ancestor for various other materials: Material, PhysicalMaterial, UnlitMaterial. </div><div><br></div><div>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.<br></div><div> </div>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 :)</div><div class="gmail_quote"><br></div><div class="gmail_quote">Best regards,</div><div class="gmail_quote">Michalis<br></div></div>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>