[x3d-public] wondering about Texture mapping specified in material nodes, X3D4 usage tradeoffs and draft meeting agenda

[Andreas Plesch]

See below

---on the phone---

On Thu, Sep 24, 2020, 6:34 AM Michalis Kamburelis <michalis.kambi at gmail.com>
wrote:

> From my point of view, we have already progressed here further with
> Andreas, making some of these questions obsolete :) Today I wrote a
> summary of our proposals with Andreas, filling in some details:
>
> A.
> https://github.com/michaliskambi/x3d-tests/wiki/Proposal:-Change-mapping-concept-into-a-number-of-xxxTexCoord-fields-in-geometry
>
> B.
> https://github.com/michaliskambi/x3d-tests/wiki/Proposal:-wrap-index-values-in-a-new-node
>
> Andreas: Please look at them, to see whether this captures what we
> spoke about nicely.


Thanks for writing this up. I think it covers all what had come up.


It also turns out that we don't need "proposal B
> (Index node)" desperately (because your "proposal A (xxxTexCoord
> fields in geometry)" already allows to reuse meshes as a whole). So
> "B" is a good thing to consider anyway, but it becomes an independent
> decision entirely from "A".
>

Agreed. B is independent.

Also agreed that xxxTexCoordIndex nodes are probably not necessary as
explained in the last wiki section.


> As for Don's question "what can I live with": Personally:
>
> - "I can live with" my "mapping" design. I'm obviously heavy biased
> here, as it's my own design and already tested in implementation.
>

If it is possible to get rid of MultiTexture* node requirements and
overloading, it would become less foreign to X3D.


> - I'm afraid 'I cannot live" with the design where texture coordinates
> are inside a material. I gave my arguments above in this thread
> already :) Texture coordinates are conceptually part of a mesh, not
> the material, and putting them in the material creates problems.
>

agreed.


> - "I can live" with the solution in "proposal A". And right now I
> think it's the best way forward (although it also requires most work,
> to encode it in spec, and to test in implementation; but hey, we
> worked on this for so long, I want to make X3Dv4 perfect :) ).
>

If the mapping approach finds more support, I would not want to delay
anything.


> My proposed for Friday schedule is:
>
> - go over any questions (from Don and anyone). I feel that if
> something was unclear from my email communication or wiki pages, then
> it is best to answer it "live".
>
> - go over our proposals with Andreas (links A B above). If we agree
> that "this is best", then I can work on encoding one or both of these
> proposals in the spec (and also implementing them in CGE, to test that
> we didn't miss some issue). I would start with A and defer B, but
> that's my point of view.
>

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.

See below for short responses to Don's specific questions.


> śr., 23 wrz 2020 o 20:28 Don Brutzman <brutzman at nps.edu> napisał(a):
> >
> > Really interesting discussion and investigation, thanks for continued
> review and pushing forward.
> >
> > Excerpt and suggestion follow:
> >
> > > On 9/22/2020 11:24 AM, Michalis Kamburelis wrote:
> > >> We cannot really make diffuseTextureCoord, specularTextureCoord inside
> > >> a mesh -- since diffuse and specular are for Phong. For PBR
> > >> (PhysicalMaterial) we have base, metallicRoughness.
> > >>
> > >> That being said, I believe you're going toward something like my
> > >> "Example F" onhttps://
> github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#can-we-make-texture-mapping-using-def--use
> > >> . This presents a situation where
> > >>
> > >> A. the Material and/or Appearance can be reused
> > >>
> > >> B. the mapping is performed without the need for SFstring "mapping",
> > >> instead it is done using DEF / USE
> > >>
> > >> C. the IndexedFaceSet cannot be reused
> > >>
> > >> So we win A and B, we lose C. Maybe this is a way forward? Preserving
> > >> C has probably the lowest priority. I can agree here that merely
> > >> reusing the "meat" of geometry node can be a solution.
> >
> > 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.
> >
> > Let's consider whether this is less about DEF-USE bookkeeping, and more
> about modeling use cases and usage.  Divide and conquer:
> >
> > ---
> >
> > a. Defining a geometry node (frequently a mesh) can include information
> about common rendering tasks.
> >
> > - 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.
>

The main use case for texCoords is simply that there is no automatic way to
map texture data from a rectangle to complex geometries.

>
> > - We (of course) want best flexibility for both geometry and PBR
> appearance.
> >
> > ---
> >
> > b. Defining a PhysicalMaterial (and other PBR Material nodes) includes
> additional textures which modulating the basic colors in special ways.
>

Texture maps are similarly useful for Phong materials.

>
> > - 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.
> >
> > - Correctly stated?
>

Yes. Texture maps for normal vectors are also widely used for Phong
materials.

>
> > - 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.
> >
> > - 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.
>

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.

>
> > ---
> >
> > c. Do we have functionally viable alternatives?
> >
> > - Classic texture image application remains controlled by keeping
> texCoord coordinates with geometry itself,
>

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.

>
> > - parameters for advanced PBR rendering by materials kept with those
> materials,
>

yes, for the texture maps, no for the texCoords.

>
> > - Since DEF/USE can occur in any order, authors and modeling tools can
> reuse any definition anywhere desired within a model.
>

I think DEF node need to come first ?

>
> > - what about texCoordIndex, are multiple arrays of values for
> specular/diffuse/normal/etc. needed when perturbating the colors of a PBR
> material?
>

probably not.

>
> > - 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?
>

>
> > ---
> >
> > d.  Hopefully this all reduces to a simple choice for our usage
> tradeoff:  are we optimizing for
> >
> > - PBR library reuse (i.e. matching "mapping" fields) or
> >
> > - geometry/Material independence (additional fields in Material nodes,
> more typical X3D approach).
> >
> > ---
> >
> > e. Next steps for X3D4 specification/examples/implementations.
> >
> > Consensus: is everyone able to answer "can I live with that" as our
> threshold to go forward with X3D4 PBR and glTF?
> >
> > - TODO multiple-node "mapping" approach (if selected.  see my TODO recap
> message about 2 hours ago)
> >
> > - TODO Materials field-centric approach (if selected.  apply key points
> from Friday discussion)
> >
> > 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.
> >
> > Thanks for continued posts and preparations for Friday.
> >
> > 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/brutzmante
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200924/bcdcfcd8/attachment-0001.html>