[x3d-public] Extrusion texture coordinates

[Andreas Plesch]

https://gist.githubusercontent.com/andreasplesch/66a7e249c52814d22e570d9b5db74984/raw/b81780446f63b6aa56e804eb1d8734f178c9817e/Extrusion_texture_test.x3d

has a quick test of how texture coordinates are assigned to Extrusion
spines:

https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/66a7e249c52814d22e570d9b5db74984/raw/b81780446f63b6aa56e804eb1d8734f178c9817e/Extrusion_texture_test.x3d

Cheers, Andreas

On Sun, Jul 13, 2025 at 11:11 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> Hi Don,
>
> This is a very helpful response. See comments below.
>
> On Sun, Jul 13, 2025 at 12:29 PM Don Brutzman <don.brutzman at gmail.com>
> wrote:
>
>> Thanks for noticing this Andreas.
>>
>> To answer your question generally, the functionality of the specification
>> is expected to be unambiguous.
>>
>>    - X3D Architecture version 4.1 draft, clause 13 Geometry3D
>>    component,  13.3.5 Extrusion
>>    -
>>    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/geometry3D.html#Extrusion
>>
>> To answer specifically, I believe we have always thought of *relative *distance
>> along the spine as the fraction [0..1] and that is consistent with other
>> u-v-w type mappings in the X3D specification.
>>
>
> Using relative distance makes most sense to me as well. I just looked up
> default ElevationGrid texture coordinates which are also a bit ambiguous:
> "The default texture coordinates range from (0,0) at the first vertex to
> (1,1) at the last vertex.". But since points are regularly spaced by
> nature, it is less of an issue. It is more or less obvious that the height
> component should not be considered for texture coordinate assignment.
>
>
>> What do you think of this suggested addition after the "Textures are
>> mapped..." sentence that you have quoted above:
>>
>>    - "Relative distances from beginning to end along the *crossSection *and
>>    *spine *curves are used to compute values in the range [0..1]."
>>
>>
> That works pretty well. There may be a lingering question: Relative to
> what ? "Distances relative to the total length from .." or perhaps
> "Distances from beginning to end normalized to the total length along .."
> may be clearer.
>
>
>> Note that there might only be multiple coincident points for a *spine *vection,
>> permitting rotations of the *crossSection* according to the orientations
>> field about that single point.
>>
>
> Yes, that is well defined. The only other question was about spines with
> only a single point, repeated, which may be somewhat useful.
>
> As another potential special case, let's consider all *crossSection *points
>> to be coincident.  Am not seeing anything in the specification forbidding
>> that.  For a rendered result, am expecting to see a single line connecting
>> each of those single-point *crossSection *perimeters, i.e. a line made
>> up of segment(s) that gets extruded at an appropriate distance from the
>> spine.
>>
>
> I am unsure about this special case because it produces a geometric line
> rather than a surface. The spec. procedure to connect points to
> quadrilaterals will produce degenerate, zero area triangles in this case.
> So the spec. would need to be amended, I believe.
> It is pretty straightforward to define a basic crossSection very small
> relative to the spine length, for an author: "0.001 0.001, 0 -0.001, -0.001
> 0.001, 0.001 0.001"
> Or scaling the default crossSection.
>
>
>> Editorially, I think we ought to be wary about defining forbidden
>> ill-defined cases.  Such definitions can be unexpectedly ambiguous, and
>> special handling (from forbidden status) might detract unnecessarily from
>> Extrusion animations.
>>
>
> The single point spine case is currently forbidden. It may be hard to
> define in such a way that it would behave well when part of a spine
> animation. So I tend to agree although there are probably cases when it
> would be useful, but texturing these may still be difficult to become
> unambiguous.
>
> Note that treating collinear points as special in the spec. already may
> lead to inconsistent animations if spine points line up during an
> animation, in the case where collinearity removes flipping of the SCP z
> axis.
>
> Of note is that we do have a number of example Extrusion nodes intended to
>> test baseline capabilities and special cases.  If you or anyone thinks we
>> should add more cases, please advise (single-point *crossSection *
>> perhaps).
>>
>>    - X3D Example Archives: X3D4AM, X3D for Advanced Modeling, Geometric
>>    Shapes, Extrusion Examples Test
>>    -
>>    https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/GeometricShapes/ExtrusionExamplesTestIndex.html
>>
>> These helped uncover issues introduced trying to deal with other issues
> ;)
>
>
>> Thanks for noting and considering a possible specification improvement.
>> Have fun with X3D Extrusion!  😀
>>
>
> I may try to create a textured simple extrusion like a cylinder with a
> long and short spine section to demonstrate the impact of texture
> coordinate generation, probably based on a conformance example..
>
> Cheers, -Andreas
>
> all the best, Don
>>
>>
>> On Sat, Jul 12, 2025 at 11:40 PM Andreas Plesch via x3d-public <
>> x3d-public at web3d.org> wrote:
>>
>>> Looking into how to generate texture coordinates for Extrusions with all
>>> coincident spine points, I noticed this section in the spec.:
>>>
>>> "Textures are mapped so that the coordinates range in the U direction
>>> from 0 to 1 along the crossSection curve (with 0 corresponding to the first
>>> point in crossSection and 1 to the last) and in the V direction from 0 to 1
>>> along the spine curve (with 0 corresponding to the first listed spine point
>>> and 1 to the last)."
>>>
>>> V varies along the spine from 0 to 1. The spec. does not define how V
>>> should vary. x3dom uses the distance between spine points to define V.
>>> Another option may be to use the index of a spine point to define V. There
>>> may be other strategies.
>>>
>>> Both options produce similar results if the spine points are regularly
>>> spaced. However, in the case of a spine with all coincident points, the
>>> results will be very different. Using distance, all Vs will be 0 (except
>>> for last to satisfy the spec.). Using the index, Vs will be distributed.
>>>
>>> Should the spec. better define how Extrusion UVs should vary ?
>>>
>>> Cheers, -Andreas
>>>
>>> _______________________________________________
>>> x3d-public mailing list
>>> x3d-public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>


-- 
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250714/2ff6206f/attachment-0001.html>