[x3d-public] wondering about Texture mapping specified in material nodes [corrected]

Andreas Plesch andreasplesch at gmail.com
Tue Sep 22 05:37:19 PDT 2020


Please see below,

---on the phone---

On Tue, Sep 22, 2020, 4:08 AM Michalis Kamburelis <michalis.kambi at gmail.com>
wrote:

> Andreas Plesch <andreasplesch at gmail.com> wrote:
> >
> > In Michalis mapping approach, what happens if the given mapping strings
> do not match up, eg. do not have the proper partner ? Presumably undefined
> behaviour, but probably hard to validate with a stylesheet.
>
> Indeed, the mappings should match (
>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#TextureMapping
> says """If the xxxTextureMapping field is not empty, it must refer to
> a corresponding X3DSingleTextureCoordinateNode node on a list of
> texture coordinates. """). I agree it introduces a difficulty to
> validate with a stylesheet.
>
> But I don't see the proposed alternative solution as valid. If we
> prevent reusing Appearance or Material or geometry nodes, then we lose
> an important property of a model format design. (That other formats
> like glTF allow, and authoring tools like Blender explicitly support.)
>

I think gltf just allows reuse of data components of a geometry or a
texture, not the complete geometry or appearance.


> >
> > Intuitively, it seems desirable to follow Don's explicit field naming
> approach, to allow for better validation and to keep with precedence of not
> having custom labels. This is just intuition, let's think about it.
> >
> > However, I think the explicit xxxTexCoord fields would need to stay in
> the geometry node (where it is now). This would then allow for reuse of
> Appearance (for example if it uses a texture catalog) for multiple
> geometries. But then the geometry (IFS) could not be reused with another
> Appearance (same officer but different uniform). I think there the solution
> is traditionally to indeed define a new Geometry but still reuse the 'meat'
> of the base Geometry, eg. the coordinate node and indices (indicating that
> they should perhaps be in their own node as well).
>
> Reusing the "meat" of the geometry is quite involved, as not
> everything is prepared for this:
>

Still, this is as x3d currently is designed as I understand it.


> - For example indexes are not "wrapped" in another node in an
> IndexedFaceSet, so they would just have to be repeated. Unless we
> invent a new node "Indexes { MFInt32 index }" but it would complicate
> the overall design, and be a significant compatibility break from X3D
> 3.
>

True, perhaps we need such a break.


> - Also such reuse doesn't allow the browser to easily "see" that we're
> not reusing geometry. If a browser has geometry-specific resources
> (like OpenGL VBOs) that could be reused, now it can just check that 2
> geometry nodes have equal references, and advise the author to reUSE
> the geometry nodes. If we instead make direct reusing of geometry
> nodes impossible (and the author can only reuse the "meat") then the
> browser would have to make field-by-field comparison (complicated, as
> it should account for various geometry nodes).
>

not sure if thinking about implementation details should guide a design.


> >
> > Another option may be to put the explicit xxxTexCoord fields in
> Appearance but outside of Material. Then Geometry could be shared. New
> Appearances would be required for different Geometries but they could still
> reuse the same Material with all the textures. That option may have
> potential but would be a departure.
>
> But reusing Appearance is also important :) Appearance has fields like
> shaders, pointProperties and more. Reusing them makes sense in X3D,
> and it directly maps to reusing some OpenGL resources (OpenGL shaders)
> across a number of geometries.
>


But you could reuse shaders or PointProperties individually, just not the
Appearance as a whole.

>
> Indeed it is tricky :) I certainly see the reason for this discussion,
> but I don't yet see any better solution than the current mapping
> SFString.
>

I do not think gltf has a similar mapping mechanism ?

Best, Andreas


> Regards,
> Michalis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200922/2d8759fd/attachment.html>


More information about the x3d-public mailing list