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

Michalis Kamburelis michalis.kambi at gmail.com
Thu Sep 24 03:34:18 PDT 2020


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

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.

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

- "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 :) ).

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.

Regards,
Michalis



ś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.
>
> - 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.
>
> - 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?
>
> - 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.
>
> ---
>
> c. Do we have functionally viable alternatives?
>
> - Classic texture image application remains controlled by keeping texCoord coordinates with geometry itself,
>
> - parameters for advanced PBR rendering by materials kept with those materials,
>
> - Since DEF/USE can occur in any order, authors and modeling tools can reuse any definition anywhere desired within a model.
>
> - what about texCoordIndex, are multiple arrays of values for specular/diffuse/normal/etc. needed when perturbating the colors of a PBR material?
>
> - 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/brutzman



More information about the x3d-public mailing list