# Difference between revisions of "Extrusion Edge Cases"

(→Problem issues) |
|||

Line 4: | Line 4: | ||

== Problem issues == | == Problem issues == | ||

+ | |||

+ | The algorithm for generating the spine-aligned cross section plane (SCP) is ambiguous, hard to follow, sometimes ill-defined. | ||

=== Coincident Spine Points === | === Coincident Spine Points === | ||

− | + | Conincident spine points are allowed under the spec. | |

− | + | ||

− | + | ||

1. The algorithm for generating Y for the SCP is ill defined if three spine points in a row are coincident. In the spirit of the spec, reusing the last value of Y makes sense, but the spec doesn't say so. | 1. The algorithm for generating Y for the SCP is ill defined if three spine points in a row are coincident. In the spirit of the spec, reusing the last value of Y makes sense, but the spec doesn't say so. | ||

Line 15: | Line 15: | ||

2. The algorithm for generating Y for the SCP at the first point of an open spine is ill defined if the first two spine points are coincident. Similarly, one may employ look-ahead to the first non-null spine segment, but the spec doesn't say so. | 2. The algorithm for generating Y for the SCP at the first point of an open spine is ill defined if the first two spine points are coincident. Similarly, one may employ look-ahead to the first non-null spine segment, but the spec doesn't say so. | ||

− | + | === Conincident Spine Points with a Bend === | |

+ | |||

+ | Consider the following spine: | ||

+ | |||

+ | (0,0,0) - (0,1,0) - (0,1,0) - (0,1,1) | ||

+ | |||

+ | === Collinear spines === | ||

+ | |||

+ | 1. The wording for generating the first (and only) SCP for collinear spines is unclear; specifically, "rotation along the axis" is a funny notion. I can imagine a translation along the axis and a rotation around an axis, but not a "rotation along something". Here's how I understand it: you calculate a rotation that takes the vector (0,1,0) to the spine direction vector (the first nonnull spine segment), then you apply the same rotation to the vector (0,0,1), and that's the Z for the SCP. Notably, that's *not* how the popular X3DOM implementation treats those cases. | ||

− | + | 2. If the above interpretation is right, the algorithm is ill defined if the spine goes in the negative Y direction. The rotation between (0,1,0) and (0,-1,0) is not uniquely defined, and the resultant SCP Z can be anywhere in the XZ plane. | |

== Possible solutions == | == Possible solutions == |

## Revision as of 12:58, 28 October 2015

The Extrusion node specification has ambiguities [1]

This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.

## Contents

## Problem issues

The algorithm for generating the spine-aligned cross section plane (SCP) is ambiguous, hard to follow, sometimes ill-defined.

### Coincident Spine Points

Conincident spine points are allowed under the spec.

1. The algorithm for generating Y for the SCP is ill defined if three spine points in a row are coincident. In the spirit of the spec, reusing the last value of Y makes sense, but the spec doesn't say so.

2. The algorithm for generating Y for the SCP at the first point of an open spine is ill defined if the first two spine points are coincident. Similarly, one may employ look-ahead to the first non-null spine segment, but the spec doesn't say so.

### Conincident Spine Points with a Bend

Consider the following spine:

(0,0,0) - (0,1,0) - (0,1,0) - (0,1,1)

### Collinear spines

1. The wording for generating the first (and only) SCP for collinear spines is unclear; specifically, "rotation along the axis" is a funny notion. I can imagine a translation along the axis and a rotation around an axis, but not a "rotation along something". Here's how I understand it: you calculate a rotation that takes the vector (0,1,0) to the spine direction vector (the first nonnull spine segment), then you apply the same rotation to the vector (0,0,1), and that's the Z for the SCP. Notably, that's *not* how the popular X3DOM implementation treats those cases.

2. If the above interpretation is right, the algorithm is ill defined if the spine goes in the negative Y direction. The rotation between (0,1,0) and (0,-1,0) is not uniquely defined, and the resultant SCP Z can be anywhere in the XZ plane.