<div dir="auto"><div>See below<br><br><div data-smartmail="gmail_signature">---on the phone---</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 24, 2020, 6:34 AM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From my point of view, we have already progressed here further with<br>
Andreas, making some of these questions obsolete :) Today I wrote a<br>
summary of our proposals with Andreas, filling in some details:<br>
<br>
A. <a href="https://github.com/michaliskambi/x3d-tests/wiki/Proposal:-Change-mapping-concept-into-a-number-of-xxxTexCoord-fields-in-geometry" rel="noreferrer noreferrer" target="_blank">https://github.com/michaliskambi/x3d-tests/wiki/Proposal:-Change-mapping-concept-into-a-number-of-xxxTexCoord-fields-in-geometry</a><br>
<br>
B. <a href="https://github.com/michaliskambi/x3d-tests/wiki/Proposal:-wrap-index-values-in-a-new-node" rel="noreferrer noreferrer" target="_blank">https://github.com/michaliskambi/x3d-tests/wiki/Proposal:-wrap-index-values-in-a-new-node</a><br>
<br>
Andreas: Please look at them, to see whether this captures what we<br>
spoke about nicely. </blockquote></div></div><div dir="auto"><br></div><div dir="auto">Thanks for writing this up. I think it covers all what had come up.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It also turns out that we don't need "proposal B<br>
(Index node)" desperately (because your "proposal A (xxxTexCoord<br>
fields in geometry)" already allows to reuse meshes as a whole). So<br>
"B" is a good thing to consider anyway, but it becomes an independent<br>
decision entirely from "A".<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Agreed. B is independent. </div><div dir="auto"><br></div><div dir="auto">Also agreed that xxxTexCoordIndex nodes are probably not necessary as explained in the last wiki section.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As for Don's question "what can I live with": Personally:<br>
<br>
- "I can live with" my "mapping" design. I'm obviously heavy biased<br>
here, as it's my own design and already tested in implementation.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">If it is possible to get rid of MultiTexture* node requirements and overloading, it would become less foreign to X3D.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- I'm afraid 'I cannot live" with the design where texture coordinates<br>
are inside a material. I gave my arguments above in this thread<br>
already :) Texture coordinates are conceptually part of a mesh, not<br>
the material, and putting them in the material creates problems.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">agreed.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- "I can live" with the solution in "proposal A". And right now I<br>
think it's the best way forward (although it also requires most work,<br>
to encode it in spec, and to test in implementation; but hey, we<br>
worked on this for so long, I want to make X3Dv4 perfect :) ).<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">If the mapping approach finds more support, I would not want to delay anything.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
My proposed for Friday schedule is:<br>
<br>
- go over any questions (from Don and anyone). I feel that if<br>
something was unclear from my email communication or wiki pages, then<br>
it is best to answer it "live".<br>
<br>
- go over our proposals with Andreas (links A B above). If we agree<br>
that "this is best", then I can work on encoding one or both of these<br>
proposals in the spec (and also implementing them in CGE, to test that<br>
we didn't miss some issue). I would start with A and defer B, but<br>
that's my point of view.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Deferring B, eg. allowing reuse of index fields by making them SFNode values, would be ok with me, as well. Conceptually, it would be a small change but it still requires standards work.</div><div dir="auto"><br></div><div dir="auto">See below for short responses to Don's specific questions. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
śr., 23 wrz 2020 o 20:28 Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank" rel="noreferrer">brutzman@nps.edu</a>> napisał(a):<br>
><br>
> Really interesting discussion and investigation, thanks for continued review and pushing forward.<br>
><br>
> Excerpt and suggestion follow:<br>
><br>
> > On 9/22/2020 11:24 AM, Michalis Kamburelis wrote:<br>
> >> We cannot really make diffuseTextureCoord, specularTextureCoord inside<br>
> >> a mesh -- since diffuse and specular are for Phong. For PBR<br>
> >> (PhysicalMaterial) we have base, metallicRoughness.<br>
> >><br>
> >> That being said, I believe you're going toward something like my<br>
> >> "Example F" onhttps://<a href="http://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#can-we-make-texture-mapping-using-def--use" rel="noreferrer noreferrer" target="_blank">github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#can-we-make-texture-mapping-using-def--use</a><br>
> >> . This presents a situation where<br>
> >><br>
> >> A. the Material and/or Appearance can be reused<br>
> >><br>
> >> B. the mapping is performed without the need for SFstring "mapping",<br>
> >> instead it is done using DEF / USE<br>
> >><br>
> >> C. the IndexedFaceSet cannot be reused<br>
> >><br>
> >> So we win A and B, we lose C. Maybe this is a way forward? Preserving<br>
> >> C has probably the lowest priority. I can agree here that merely<br>
> >> reusing the "meat" of geometry node can be a solution.<br>
><br>
> Yes, have been thinking in similar directions. This is all boiling down to a tradeoff question. If all the necessary information is known, then _where_ we put the information is the design choice.<br>
><br>
> Let's consider whether this is less about DEF-USE bookkeeping, and more about modeling use cases and usage. Divide and conquer:<br>
><br>
> ---<br>
><br>
> a. Defining a geometry node (frequently a mesh) can include information about common rendering tasks.<br>
><br>
> - For example, texture coordinates (texCoord and texCoordIndex) are defined as part of the mesh so that texture images can be applied appropriately to the mesh. Different rectangular images thus have comparable effects for a given piece of geometry.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">The main use case for texCoords is simply that there is no automatic way to map texture data from a rectangle to complex geometries.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> - We (of course) want best flexibility for both geometry and PBR appearance.<br>
><br>
> ---<br>
><br>
> b. Defining a PhysicalMaterial (and other PBR Material nodes) includes additional textures which modulating the basic colors in special ways.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Texture maps are similarly useful for Phong materials.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> - For example, RGB bits in a 2D array (an ImageTexture or PixelTexture perhaps) define special rendering perturbations on the base and emissive colors, normal vectors, etc.<br>
><br>
> - Correctly stated?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes. Texture maps for normal vectors are also widely used for Phong materials.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> - It is not seem possible for a modeled IndexedFaceSet to foresee all of the different ways it might be rendered. Indeed, the PhysicalMaterial might be changing at run time for whatever reasons.<br>
><br>
> - Thus, a given PhysicalMaterial node needs some way to refer to the properties being used to render geometry, either via "mapping" relationships shared by multiple nodes, or each relationship specifically defined by fields.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It is more standard to have the reverse point if view. A PhysicalMaterial cannot foresee how it might be associated with some geometry in a shape. Thus, geometries need to have texcoord fields for texture mapping. Only the geometry knows the details of this mapping.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> ---<br>
><br>
> c. Do we have functionally viable alternatives?<br>
><br>
> - Classic texture image application remains controlled by keeping texCoord coordinates with geometry itself,<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I think it is useful to start to consider texCoord as having the same function as diffuseTexCoord. Then, in another step, as being a fallback value for any texcoords.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> - parameters for advanced PBR rendering by materials kept with those materials,<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">yes, for the texture maps, no for the texCoords.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> - Since DEF/USE can occur in any order, authors and modeling tools can reuse any definition anywhere desired within a model.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I think DEF node need to come first ?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> - what about texCoordIndex, are multiple arrays of values for specular/diffuse/normal/etc. needed when perturbating the colors of a PBR material?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">probably not.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> - if PBR material libraries can be defined that are independent of geometry they are applied to, does reuse mean they have "mapping" fields embedded that the geometry meshes would need to match?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> ---<br>
><br>
> d. Hopefully this all reduces to a simple choice for our usage tradeoff: are we optimizing for<br>
><br>
> - PBR library reuse (i.e. matching "mapping" fields) or<br>
><br>
> - geometry/Material independence (additional fields in Material nodes, more typical X3D approach).<br>
><br>
> ---<br>
><br>
> e. Next steps for X3D4 specification/examples/implementations.<br>
><br>
> Consensus: is everyone able to answer "can I live with that" as our threshold to go forward with X3D4 PBR and glTF?<br>
><br>
> - TODO multiple-node "mapping" approach (if selected. see my TODO recap message about 2 hours ago)<br>
><br>
> - TODO Materials field-centric approach (if selected. apply key points from Friday discussion)<br>
><br>
> How does this look as default agenda for our discussions Friday? Hoping we can make the most of our precious time together. Pending feedback, will post.<br>
><br>
> Thanks for continued posts and preparations for Friday.<br>
><br>
> all the best, Don<br>
> --<br>
> Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank" rel="noreferrer">brutzman@nps.edu</a><br>
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>
> X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a>te<br>
</blockquote></div></div></div>