<div dir="auto">Sorry to nudge in here after all this time.</div><div dir="auto"><br></div><div dir="auto">Consider three types of output on the web:  hyper-movies, hypertext (or hyper symbols), and hyper-volumes/hyper-shapes, then also consider the combination of any two: textured movie shapes or screens, textured text, text as a shape, text as voxels, movie screen made from symbols or shapes, etc. and then the combination of the three.</div><div dir="auto"><br></div><div dir="auto">I believe that an X3D standard of the future should be able to describe the above combinations.</div><div dir="auto"><br></div><div dir="auto">Please place your efforts on some minimal version of the above and also plot a plan for all combinations the base output types.</div><div dir="auto"><br></div><div dir="auto">“If you build it, he will come” — Field of Dreams</div><div dir="auto"><br></div><div dir="auto">John “Think Holodeck” Carlson</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 24, 2020 at 5:35 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-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">From my point of view, we have already progressed here further with<br><br>Andreas, making some of these questions obsolete :) Today I wrote a<br><br>summary of our proposals with Andreas, filling in some details:<br><br><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" target="_blank">https://github.com/michaliskambi/x3d-tests/wiki/Proposal:-Change-mapping-concept-into-a-number-of-xxxTexCoord-fields-in-geometry</a><br><br><br><br>B. <a href="https://github.com/michaliskambi/x3d-tests/wiki/Proposal:-wrap-index-values-in-a-new-node" rel="noreferrer" target="_blank">https://github.com/michaliskambi/x3d-tests/wiki/Proposal:-wrap-index-values-in-a-new-node</a><br><br><br><br>Andreas: Please look at them, to see whether this captures what we<br><br>spoke about nicely. It also turns out that we don't need "proposal B<br><br>(Index node)" desperately (because your "proposal A (xxxTexCoord<br><br>fields in geometry)" already allows to reuse meshes as a whole). So<br><br>"B" is a good thing to consider anyway, but it becomes an independent<br><br>decision entirely from "A".<br><br><br><br>As for Don's question "what can I live with": Personally:<br><br><br><br>- "I can live with" my "mapping" design. I'm obviously heavy biased<br><br>here, as it's my own design and already tested in implementation.<br><br><br><br>- I'm afraid 'I cannot live" with the design where texture coordinates<br><br>are inside a material. I gave my arguments above in this thread<br><br>already :) Texture coordinates are conceptually part of a mesh, not<br><br>the material, and putting them in the material creates problems.<br><br><br><br>- "I can live" with the solution in "proposal A". And right now I<br><br>think it's the best way forward (although it also requires most work,<br><br>to encode it in spec, and to test in implementation; but hey, we<br><br>worked on this for so long, I want to make X3Dv4 perfect :) ).<br><br><br><br>My proposed for Friday schedule is:<br><br><br><br>- go over any questions (from Don and anyone). I feel that if<br><br>something was unclear from my email communication or wiki pages, then<br><br>it is best to answer it "live".<br><br><br><br>- go over our proposals with Andreas (links A B above). If we agree<br><br>that "this is best", then I can work on encoding one or both of these<br><br>proposals in the spec (and also implementing them in CGE, to test that<br><br>we didn't miss some issue). I would start with A and defer B, but<br><br>that's my point of view.<br><br><br><br>Regards,<br><br>Michalis<br><br><br><br><br><br><br><br>śr., 23 wrz 2020 o 20:28 Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> napisał(a):<br><br>><br><br>> Really interesting discussion and investigation, thanks for continued review and pushing forward.<br><br>><br><br>> Excerpt and suggestion follow:<br><br>><br><br>> > On 9/22/2020 11:24 AM, Michalis Kamburelis wrote:<br><br>> >> We cannot really make diffuseTextureCoord, specularTextureCoord inside<br><br>> >> a mesh -- since diffuse and specular are for Phong. For PBR<br><br>> >> (PhysicalMaterial) we have base, metallicRoughness.<br><br>> >><br><br>> >> That being said, I believe you're going toward something like my<br><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" 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><br>> >> . This presents a situation where<br><br>> >><br><br>> >> A. the Material and/or Appearance can be reused<br><br>> >><br><br>> >> B. the mapping is performed without the need for SFstring "mapping",<br><br>> >> instead it is done using DEF / USE<br><br>> >><br><br>> >> C. the IndexedFaceSet cannot be reused<br><br>> >><br><br>> >> So we win A and B, we lose C. Maybe this is a way forward? Preserving<br><br>> >> C has probably the lowest priority. I can agree here that merely<br><br>> >> reusing the "meat" of geometry node can be a solution.<br><br>><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>><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>> ---<br><br>><br><br>> a. Defining a geometry node (frequently a mesh) can include information about common rendering tasks.<br><br>><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><br>><br><br>> - We (of course) want best flexibility for both geometry and PBR appearance.<br><br>><br><br>> ---<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><br>><br><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>><br><br>> - Correctly stated?<br><br>><br><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>><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><br>><br><br>> ---<br><br>><br><br>> c. Do we have functionally viable alternatives?<br><br>><br><br>> - Classic texture image application remains controlled by keeping texCoord coordinates with geometry itself,<br><br>><br><br>> - parameters for advanced PBR rendering by materials kept with those materials,<br><br>><br><br>> - Since DEF/USE can occur in any order, authors and modeling tools can reuse any definition anywhere desired within a model.<br><br>><br><br>> - what about texCoordIndex, are multiple arrays of values for specular/diffuse/normal/etc. needed when perturbating the colors of a PBR material?<br><br>><br><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><br>><br><br>> ---<br><br>><br><br>> d.  Hopefully this all reduces to a simple choice for our usage tradeoff:  are we optimizing for<br><br>><br><br>> - PBR library reuse (i.e. matching "mapping" fields) or<br><br>><br><br>> - geometry/Material independence (additional fields in Material nodes, more typical X3D approach).<br><br>><br><br>> ---<br><br>><br><br>> e. Next steps for X3D4 specification/examples/implementations.<br><br>><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>><br><br>> - TODO multiple-node "mapping" approach (if selected.  see my TODO recap message about 2 hours ago)<br><br>><br><br>> - TODO Materials field-centric approach (if selected.  apply key points from Friday discussion)<br><br>><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>><br><br>> Thanks for continued posts and preparations for Friday.<br><br>><br><br>> all the best, Don<br><br>> --<br><br>> Don Brutzman  Naval Postgraduate School, Code USW/Br       <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br><br>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149<br><br>> X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br><br><br><br>_______________________________________________<br><br>x3d-public mailing list<br><br><a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br><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><br></blockquote></div></div>