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

Thu Sep 24 06:06:13 PDT 2020

Sorry to nudge in here after all this time.

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.

I believe that an X3D standard of the future should be able to describe the
above combinations.

Please place your efforts on some minimal version of the above and also
plot a plan for all combinations the base output types.

“If you build it, he will come” — Field of Dreams

John “Think Holodeck” Carlson

On Thu, Sep 24, 2020 at 5:35 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. 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
>
>
>
> _______________________________________________
>
> x3d-public mailing list
>
> x3d-public at web3d.org
>
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200924/f3cc0724/attachment.html>