<div dir="auto"><div>Please see below,<br><br><div data-smartmail="gmail_signature">---on the phone---</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 22, 2020, 4:08 AM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank" rel="noreferrer">andreasplesch@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
<br>
Indeed, the mappings should match (<br>
<a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#TextureMapping" rel="noreferrer noreferrer" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#TextureMapping</a><br>
says """If the xxxTextureMapping field is not empty, it must refer to<br>
a corresponding X3DSingleTextureCoordinateNode node on a list of<br>
texture coordinates. """). I agree it introduces a difficulty to<br>
validate with a stylesheet.<br>
<br>
But I don't see the proposed alternative solution as valid. If we<br>
prevent reusing Appearance or Material or geometry nodes, then we lose<br>
an important property of a model format design. (That other formats<br>
like glTF allow, and authoring tools like Blender explicitly support.)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I think gltf just allows reuse of data components of a geometry or a texture, not the complete geometry or appearance.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> 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.<br>
><br>
> 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).<br>
<br>
Reusing the "meat" of the geometry is quite involved, as not<br>
everything is prepared for this:<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Still, this is as x3d currently is designed as I understand it. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- For example indexes are not "wrapped" in another node in an<br>
IndexedFaceSet, so they would just have to be repeated. Unless we<br>
invent a new node "Indexes { MFInt32 index }" but it would complicate<br>
the overall design, and be a significant compatibility break from X3D<br>
3.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">True, perhaps we need such a break.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- Also such reuse doesn't allow the browser to easily "see" that we're<br>
not reusing geometry. If a browser has geometry-specific resources<br>
(like OpenGL VBOs) that could be reused, now it can just check that 2<br>
geometry nodes have equal references, and advise the author to reUSE<br>
the geometry nodes. If we instead make direct reusing of geometry<br>
nodes impossible (and the author can only reuse the "meat") then the<br>
browser would have to make field-by-field comparison (complicated, as<br>
it should account for various geometry nodes).<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">not sure if thinking about implementation details should guide a design.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> 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.<br>
<br>
But reusing Appearance is also important :) Appearance has fields like<br>
shaders, pointProperties and more. Reusing them makes sense in X3D,<br>
and it directly maps to reusing some OpenGL resources (OpenGL shaders)<br>
across a number of geometries.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">But you could reuse shaders or PointProperties individually, just not the Appearance as a whole.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Indeed it is tricky :) I certainly see the reason for this discussion,<br>
but I don't yet see any better solution than the current mapping<br>
SFString.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I do not think gltf has a similar mapping mechanism ? </div><div dir="auto"><br></div><div dir="auto">Best, Andreas</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
Michalis<br>
</blockquote></div></div></div>