https://www.web3d.org/wiki/api.php?action=feedcontributions&user=Sevaa&feedformat=atomWeb3D.org - User contributions [en]2022-09-29T05:54:45ZUser contributionsMediaWiki 1.25.1https://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9179Extrusion Edge Cases2016-01-27T16:13:45Z<p>Sevaa: /* Example */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclic)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
Consider [http://www.jishop.com/temp/extrusion/threecoin.png the spine on the linked image].<br />
<br />
We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the middle points of this spine.<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, [https://github.com/x3dom/x3dom/issues/570 an extrusion in X or Z direction looks completely flat].<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in different ways. Consider [http://www.jishop.com/temp/x3d/#ExtrusionDirY the following scene]:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under [http://www.jishop.com/temp/extrusion/DirY_X3DOM.png X3DOM] and [http://www.jishop.com/temp/extrusion/DirY_InRe.png InstantReality], another way under [http://www.jishop.com/temp/extrusion/DirY_Xj3D.png Xj3D].<br />
<br />
==== Public Example ====<br />
<br />
[http://www.jishop.com/temp/x3d/#AV8bHarrier The Harrier model] in the Savage model archive actually has extrusions in the -Y direction. Both wings of the airplane (node DEFs Left_Wing and Right_Wing) are implemented that way. Under X3DOM and Xj3D, the wings are misrendered. From the look of the model, it's obvious that the author expected the SCP to be spanned by {{Overline|(-1,0,0)}} and {{Overline|(0,0,1)}}. InstantReality displays this model as expected, at least the wings are not backwards, like they are under X3DOM.<br />
<br />
See the way it renders in [http://www.jishop.com/temp/extrusion/Harrier_X3DOM.png X3DOM], [http://www.jishop.com/temp/extrusion/Harrier_InRe.png InstantReality], [http://www.jishop.com/temp/extrusion/Harrier_Xj3D.png Xj3D].<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
<br />
=== Floating Point Rounding ===<br />
<br />
The spec calls for conditionals based upon floating point arithmetic results, specifically, the determination of collinearity. Floating point calculations being inherently imprecise, this is a huge can of worms. Details to follow.<br />
<br />
Determination of point coincidence, however, is a safe operation, as long as spine coordinates were hand-written and not tool-generated.<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9080Extrusion Edge Cases2015-11-16T18:09:48Z<p>Sevaa: /* Example */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclic)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
Consider the following case:<br />
<br />
[[Image:Threecoin.png]]<br />
<br />
We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the middle points of this spine.<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, [https://github.com/x3dom/x3dom/issues/570 an extrusion in X or Z direction looks completely flat].<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in different ways. Consider [http://www.jishop.com/temp/x3d/#ExtrusionDirY the following scene]:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under [http://www.jishop.com/temp/extrusion/DirY_X3DOM.png X3DOM] and [http://www.jishop.com/temp/extrusion/DirY_InRe.png InstantReality], another way under [http://www.jishop.com/temp/extrusion/DirY_Xj3D.png Xj3D].<br />
<br />
==== Public Example ====<br />
<br />
[http://www.jishop.com/temp/x3d/#AV8bHarrier The Harrier model] in the Savage model archive actually has extrusions in the -Y direction. Both wings of the airplane (node DEFs Left_Wing and Right_Wing) are implemented that way. Under X3DOM and Xj3D, the wings are misrendered. From the look of the model, it's obvious that the author expected the SCP to be spanned by {{Overline|(-1,0,0)}} and {{Overline|(0,0,1)}}. InstantReality displays this model as expected, at least the wings are not backwards, like they are under X3DOM.<br />
<br />
See the way it renders in [http://www.jishop.com/temp/extrusion/Harrier_X3DOM.png X3DOM], [http://www.jishop.com/temp/extrusion/Harrier_InRe.png InstantReality], [http://www.jishop.com/temp/extrusion/Harrier_Xj3D.png Xj3D].<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
<br />
=== Floating Point Rounding ===<br />
<br />
The spec calls for conditionals based upon floating point arithmetic results, specifically, the determination of collinearity. Floating point calculations being inherently imprecise, this is a huge can of worms. Details to follow.<br />
<br />
Determination of point coincidence, however, is a safe operation, as long as spine coordinates were hand-written and not tool-generated.<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9079Extrusion Edge Cases2015-11-16T18:06:29Z<p>Sevaa: /* Example */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclic)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
Consider the following case:<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the middle points of this spine.<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, [https://github.com/x3dom/x3dom/issues/570 an extrusion in X or Z direction looks completely flat].<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in different ways. Consider [http://www.jishop.com/temp/x3d/#ExtrusionDirY the following scene]:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under [http://www.jishop.com/temp/extrusion/DirY_X3DOM.png X3DOM] and [http://www.jishop.com/temp/extrusion/DirY_InRe.png InstantReality], another way under [http://www.jishop.com/temp/extrusion/DirY_Xj3D.png Xj3D].<br />
<br />
==== Public Example ====<br />
<br />
[http://www.jishop.com/temp/x3d/#AV8bHarrier The Harrier model] in the Savage model archive actually has extrusions in the -Y direction. Both wings of the airplane (node DEFs Left_Wing and Right_Wing) are implemented that way. Under X3DOM and Xj3D, the wings are misrendered. From the look of the model, it's obvious that the author expected the SCP to be spanned by {{Overline|(-1,0,0)}} and {{Overline|(0,0,1)}}. InstantReality displays this model as expected, at least the wings are not backwards, like they are under X3DOM.<br />
<br />
See the way it renders in [http://www.jishop.com/temp/extrusion/Harrier_X3DOM.png X3DOM], [http://www.jishop.com/temp/extrusion/Harrier_InRe.png InstantReality], [http://www.jishop.com/temp/extrusion/Harrier_Xj3D.png Xj3D].<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
<br />
=== Floating Point Rounding ===<br />
<br />
The spec calls for conditionals based upon floating point arithmetic results, specifically, the determination of collinearity. Floating point calculations being inherently imprecise, this is a huge can of worms. Details to follow.<br />
<br />
Determination of point coincidence, however, is a safe operation, as long as spine coordinates were hand-written and not tool-generated.<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=File:Threecoin.png&diff=9078File:Threecoin.png2015-11-16T18:05:00Z<p>Sevaa: A spine with three coincident points in the middle.</p>
<hr />
<div>A spine with three coincident points in the middle.</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9062Extrusion Edge Cases2015-11-03T15:43:54Z<p>Sevaa: /* Example */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclic)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of [http://www.jishop.com/temp/x3d/#ThreeCoin three coincident spine points]. We have a cluster of three coincident points in the middle, [http://www.jishop.com/temp/extrusion/threecoin.png click here see the spine image]. <br />
<br />
Let's consider the generation of the CSP Y for the middle points of this spine.<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, [https://github.com/x3dom/x3dom/issues/570 an extrusion in X or Z direction looks completely flat].<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in different ways. Consider [http://www.jishop.com/temp/x3d/#ExtrusionDirY the following scene]:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under [http://www.jishop.com/temp/extrusion/DirY_X3DOM.png X3DOM] and [http://www.jishop.com/temp/extrusion/DirY_InRe.png InstantReality], another way under [http://www.jishop.com/temp/extrusion/DirY_Xj3D.png Xj3D].<br />
<br />
==== Public Example ====<br />
<br />
[http://www.jishop.com/temp/x3d/#AV8bHarrier The Harrier model] in the Savage model archive actually has extrusions in the -Y direction. Both wings of the airplane (node DEFs Left_Wing and Right_Wing) are implemented that way. Under X3DOM and Xj3D, the wings are misrendered. From the look of the model, it's obvious that the author expected the SCP to be spanned by {{Overline|(-1,0,0)}} and {{Overline|(0,0,1)}}. InstantReality displays this model as expected, at least the wings are not backwards, like they are under X3DOM.<br />
<br />
See the way it renders in [http://www.jishop.com/temp/extrusion/Harrier_X3DOM.png X3DOM], [http://www.jishop.com/temp/extrusion/Harrier_InRe.png InstantReality], [http://www.jishop.com/temp/extrusion/Harrier_Xj3D.png Xj3D].<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
<br />
=== Floating Point Rounding ===<br />
<br />
The spec calls for conditionals based upon floating point arithmetic results, specifically, the determination of collinearity. Floating point calculations being inherently imprecise, this is a huge can of worms. Details to follow.<br />
<br />
Determination of point coincidence, however, is a safe operation, as long as spine coordinates were hand-written and not tool-generated.<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9061Extrusion Edge Cases2015-11-03T15:42:45Z<p>Sevaa: /* Straight spine in -Y direction */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclic)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle, [http://www.jishop.com/temp/extrusion/threecoin.png click here see the image]. <br />
<br />
Let's consider the generation of the CSP Y for the middle points of this spine.<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, [https://github.com/x3dom/x3dom/issues/570 an extrusion in X or Z direction looks completely flat].<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in different ways. Consider [http://www.jishop.com/temp/x3d/#ExtrusionDirY the following scene]:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under [http://www.jishop.com/temp/extrusion/DirY_X3DOM.png X3DOM] and [http://www.jishop.com/temp/extrusion/DirY_InRe.png InstantReality], another way under [http://www.jishop.com/temp/extrusion/DirY_Xj3D.png Xj3D].<br />
<br />
==== Public Example ====<br />
<br />
[http://www.jishop.com/temp/x3d/#AV8bHarrier The Harrier model] in the Savage model archive actually has extrusions in the -Y direction. Both wings of the airplane (node DEFs Left_Wing and Right_Wing) are implemented that way. Under X3DOM and Xj3D, the wings are misrendered. From the look of the model, it's obvious that the author expected the SCP to be spanned by {{Overline|(-1,0,0)}} and {{Overline|(0,0,1)}}. InstantReality displays this model as expected, at least the wings are not backwards, like they are under X3DOM.<br />
<br />
See the way it renders in [http://www.jishop.com/temp/extrusion/Harrier_X3DOM.png X3DOM], [http://www.jishop.com/temp/extrusion/Harrier_InRe.png InstantReality], [http://www.jishop.com/temp/extrusion/Harrier_Xj3D.png Xj3D].<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
<br />
=== Floating Point Rounding ===<br />
<br />
The spec calls for conditionals based upon floating point arithmetic results, specifically, the determination of collinearity. Floating point calculations being inherently imprecise, this is a huge can of worms. Details to follow.<br />
<br />
Determination of point coincidence, however, is a safe operation, as long as spine coordinates were hand-written and not tool-generated.<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9060Extrusion Edge Cases2015-11-03T15:41:47Z<p>Sevaa: /* Public Example */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclic)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle, [http://www.jishop.com/temp/extrusion/threecoin.png click here see the image]. <br />
<br />
Let's consider the generation of the CSP Y for the middle points of this spine.<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, [https://github.com/x3dom/x3dom/issues/570 an extrusion in X or Z direction looks completely flat].<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under [http://www.jishop.com/temp/extrusion/DirY_X3DOM.png X3DOM] and [http://www.jishop.com/temp/extrusion/DirY_InRe.png InstantReality], another way under [http://www.jishop.com/temp/extrusion/DirY_Xj3D.png Xj3D].<br />
<br />
==== Public Example ====<br />
<br />
[http://www.jishop.com/temp/x3d/#AV8bHarrier The Harrier model] in the Savage model archive actually has extrusions in the -Y direction. Both wings of the airplane (node DEFs Left_Wing and Right_Wing) are implemented that way. Under X3DOM and Xj3D, the wings are misrendered. From the look of the model, it's obvious that the author expected the SCP to be spanned by {{Overline|(-1,0,0)}} and {{Overline|(0,0,1)}}. InstantReality displays this model as expected, at least the wings are not backwards, like they are under X3DOM.<br />
<br />
See the way it renders in [http://www.jishop.com/temp/extrusion/Harrier_X3DOM.png X3DOM], [http://www.jishop.com/temp/extrusion/Harrier_InRe.png InstantReality], [http://www.jishop.com/temp/extrusion/Harrier_Xj3D.png Xj3D].<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
<br />
=== Floating Point Rounding ===<br />
<br />
The spec calls for conditionals based upon floating point arithmetic results, specifically, the determination of collinearity. Floating point calculations being inherently imprecise, this is a huge can of worms. Details to follow.<br />
<br />
Determination of point coincidence, however, is a safe operation, as long as spine coordinates were hand-written and not tool-generated.<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9059Extrusion Edge Cases2015-11-03T15:36:22Z<p>Sevaa: /* Public Example */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclic)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle, [http://www.jishop.com/temp/extrusion/threecoin.png click here see the image]. <br />
<br />
Let's consider the generation of the CSP Y for the middle points of this spine.<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, [https://github.com/x3dom/x3dom/issues/570 an extrusion in X or Z direction looks completely flat].<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under [http://www.jishop.com/temp/extrusion/DirY_X3DOM.png X3DOM] and [http://www.jishop.com/temp/extrusion/DirY_InRe.png InstantReality], another way under [http://www.jishop.com/temp/extrusion/DirY_Xj3D.png Xj3D].<br />
<br />
==== Public Example ====<br />
<br />
The Harrier model in the Savage model archive actually has extrusions in the -Y direction. Both wings of the airplane (node DEFs Left_Wing and Right_Wing) are implemented that way. Under X3DOM and Xj3D, the wings are misrendered. From the look of the model, it's obvious that the author expected the SCP to be spanned by {{Overline|(-1,0,0)}} and {{Overline|(0,0,1)}}. InstantReality displays this model as expected, at least the wings are not backwards, like they are under X3DOM.<br />
<br />
See the way it renders in [http://www.jishop.com/temp/extrusion/Harrier_X3DOM.png X3DOM], [http://www.jishop.com/temp/extrusion/Harrier_InRe.png InstantReality], [http://www.jishop.com/temp/extrusion/Harrier_Xj3D.png Xj3D].<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
<br />
=== Floating Point Rounding ===<br />
<br />
The spec calls for conditionals based upon floating point arithmetic results, specifically, the determination of collinearity. Floating point calculations being inherently imprecise, this is a huge can of worms. Details to follow.<br />
<br />
Determination of point coincidence, however, is a safe operation, as long as spine coordinates were hand-written and not tool-generated.<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9058Extrusion Edge Cases2015-11-03T15:34:53Z<p>Sevaa: /* Straight spine in -Y direction */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclic)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle, [http://www.jishop.com/temp/extrusion/threecoin.png click here see the image]. <br />
<br />
Let's consider the generation of the CSP Y for the middle points of this spine.<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, [https://github.com/x3dom/x3dom/issues/570 an extrusion in X or Z direction looks completely flat].<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under [http://www.jishop.com/temp/extrusion/DirY_X3DOM.png X3DOM] and [http://www.jishop.com/temp/extrusion/DirY_InRe.png InstantReality], another way under [http://www.jishop.com/temp/extrusion/DirY_Xj3D.png Xj3D].<br />
<br />
==== Public Example ====<br />
<br />
The Harrier model in the Savage model archive actually has extrusions in the -Y direction. Both wings of the airplane (node DEFs Left_Wing and Right_Wing) are implemented that way. Under X3DOM and Xj3D, the wings are misrendered. From the look of the model, it's obvious that the author expected the SCP to be spanned by {{Overline|(-1,0,0)}} and {{Overline|(0,0,1)}}. InstantReality displays this model as expected, at least the wings are not backwards, like they are under X3DOM.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
<br />
=== Floating Point Rounding ===<br />
<br />
The spec calls for conditionals based upon floating point arithmetic results, specifically, the determination of collinearity. Floating point calculations being inherently imprecise, this is a huge can of worms. Details to follow.<br />
<br />
Determination of point coincidence, however, is a safe operation, as long as spine coordinates were hand-written and not tool-generated.<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9057Extrusion Edge Cases2015-11-03T15:33:17Z<p>Sevaa: /* Coincident Spine Points and Y */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclic)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle, [http://www.jishop.com/temp/extrusion/threecoin.png click here see the image]. <br />
<br />
Let's consider the generation of the CSP Y for the middle points of this spine.<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, [https://github.com/x3dom/x3dom/issues/570 an extrusion in X or Z direction looks completely flat].<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D.<br />
<br />
==== Public Example ====<br />
<br />
The Harrier model in the Savage model archive actually has extrusions in the -Y direction. Both wings of the airplane (node DEFs Left_Wing and Right_Wing) are implemented that way. Under X3DOM and Xj3D, the wings are misrendered. From the look of the model, it's obvious that the author expected the SCP to be spanned by {{Overline|(-1,0,0)}} and {{Overline|(0,0,1)}}. InstantReality displays this model as expected, at least the wings are not backwards, like they are under X3DOM.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
<br />
=== Floating Point Rounding ===<br />
<br />
The spec calls for conditionals based upon floating point arithmetic results, specifically, the determination of collinearity. Floating point calculations being inherently imprecise, this is a huge can of worms. Details to follow.<br />
<br />
Determination of point coincidence, however, is a safe operation, as long as spine coordinates were hand-written and not tool-generated.<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9056Extrusion Edge Cases2015-11-03T15:32:33Z<p>Sevaa: /* Rules for Collinear Spines */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclic)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle, see the image below: <br />
<br />
http://www.jishop.com/temp/extrusion/threecoin.png<br />
<br />
Let's consider the generation of the CSP Y for the middle points of this spine.<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, [https://github.com/x3dom/x3dom/issues/570 an extrusion in X or Z direction looks completely flat].<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D.<br />
<br />
==== Public Example ====<br />
<br />
The Harrier model in the Savage model archive actually has extrusions in the -Y direction. Both wings of the airplane (node DEFs Left_Wing and Right_Wing) are implemented that way. Under X3DOM and Xj3D, the wings are misrendered. From the look of the model, it's obvious that the author expected the SCP to be spanned by {{Overline|(-1,0,0)}} and {{Overline|(0,0,1)}}. InstantReality displays this model as expected, at least the wings are not backwards, like they are under X3DOM.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
<br />
=== Floating Point Rounding ===<br />
<br />
The spec calls for conditionals based upon floating point arithmetic results, specifically, the determination of collinearity. Floating point calculations being inherently imprecise, this is a huge can of worms. Details to follow.<br />
<br />
Determination of point coincidence, however, is a safe operation, as long as spine coordinates were hand-written and not tool-generated.<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9055Extrusion Edge Cases2015-11-03T15:26:35Z<p>Sevaa: /* Example */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclic)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle, see the image below: <br />
<br />
http://www.jishop.com/temp/extrusion/threecoin.png<br />
<br />
Let's consider the generation of the CSP Y for the middle points of this spine.<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D.<br />
<br />
==== Public Example ====<br />
<br />
The Harrier model in the Savage model archive actually has extrusions in the -Y direction. Both wings of the airplane (node DEFs Left_Wing and Right_Wing) are implemented that way. Under X3DOM and Xj3D, the wings are misrendered. From the look of the model, it's obvious that the author expected the SCP to be spanned by {{Overline|(-1,0,0)}} and {{Overline|(0,0,1)}}. InstantReality displays this model as expected, at least the wings are not backwards, like they are under X3DOM.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
<br />
=== Floating Point Rounding ===<br />
<br />
The spec calls for conditionals based upon floating point arithmetic results, specifically, the determination of collinearity. Floating point calculations being inherently imprecise, this is a huge can of worms. Details to follow.<br />
<br />
Determination of point coincidence, however, is a safe operation, as long as spine coordinates were hand-written and not tool-generated.<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9054Extrusion Edge Cases2015-10-31T17:01:06Z<p>Sevaa: </p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclic)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the middle points of this spine.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D.<br />
<br />
==== Public Example ====<br />
<br />
The Harrier model in the Savage model archive actually has extrusions in the -Y direction. Both wings of the airplane (node DEFs Left_Wing and Right_Wing) are implemented that way. Under X3DOM and Xj3D, the wings are misrendered. From the look of the model, it's obvious that the author expected the SCP to be spanned by {{Overline|(-1,0,0)}} and {{Overline|(0,0,1)}}. InstantReality displays this model as expected, at least the wings are not backwards, like they are under X3DOM.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
<br />
=== Floating Point Rounding ===<br />
<br />
The spec calls for conditionals based upon floating point arithmetic results, specifically, the determination of collinearity. Floating point calculations being inherently imprecise, this is a huge can of worms. Details to follow.<br />
<br />
Determination of point coincidence, however, is a safe operation, as long as spine coordinates were hand-written and not tool-generated.<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9053Extrusion Edge Cases2015-10-30T15:31:17Z<p>Sevaa: /* Straight spine in -Y direction */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclic)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the middle points of this spine.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D.<br />
<br />
==== Public Example ====<br />
<br />
The Harrier model in the Savage model archive actually has extrusions in the -Y direction. Both wings of the airplane (node DEFs Left_Wing and Right_Wing) are implemented that way. Under X3DOM and Xj3D, the wings are misrendered. From the look of the model, it's obvious that the author expected the SCP to be spanned by {{Overline|(-1,0,0)}} and {{Overline|(0,0,1)}}. InstantReality displays this model as expected, at least the wings are not backwards, like they are under X3DOM.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
<br />
=== Floating Point Rounding ===<br />
<br />
The spec calls for conditionals based upon floating point arithmetic results, specifically, the determination of collinearity. Floating point calculations being inherently imprecise, this is a huge can of worms. Details to follow.<br />
<br />
Determination of point coincidence, however, is a safe operation, as long as spine coordinates were hand-written and not tool-generated.<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9052Extrusion Edge Cases2015-10-30T15:04:50Z<p>Sevaa: /* Example */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclic)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the middle points of this spine.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D.<br />
<br />
==== Public Example ====<br />
<br />
The Harrier model in the Savage model archive actually has extrusions in the -Y direction. Both wings of the airplane (node DEFs Left_Wing and Right_Wing) are implemented that way. Under X3DOM and Xj3D, the wings are misrendered. From the look of the model, it's obvious that the author expected the SCP to be spanned by {{Overline|(-1,0,0)}} and {{Overline|(0,0,1)}}. InstantReality displays this model as expected, at least the wings are not backwards, like they are under X3DOM.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
<br />
=== Floating Point Rounding ===<br />
<br />
The spec calls for conditionals based upon floating point arithmetic results, specifically, the determination of collinearity. Floating point calculations being inherently imprecise, this is a huge can of worms. Details to follow.<br />
<br />
Determination of point coincidence, however, is a safe operation, as long as spine coordinates were hand-written and not tool-generated.<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9051Extrusion Edge Cases2015-10-30T14:27:33Z<p>Sevaa: /* Public Example */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclic)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the points of this spine.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D.<br />
<br />
==== Public Example ====<br />
<br />
The Harrier model in the Savage model archive actually has extrusions in the -Y direction. Both wings of the airplane (node DEFs Left_Wing and Right_Wing) are implemented that way. Under X3DOM and Xj3D, the wings are misrendered. From the look of the model, it's obvious that the author expected the SCP to be spanned by {{Overline|(-1,0,0)}} and {{Overline|(0,0,1)}}. InstantReality displays this model as expected, at least the wings are not backwards, like they are under X3DOM.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
<br />
=== Floating Point Rounding ===<br />
<br />
The spec calls for conditionals based upon floating point arithmetic results, specifically, the determination of collinearity. Floating point calculations being inherently imprecise, this is a huge can of worms. Details to follow.<br />
<br />
Determination of point coincidence, however, is a safe operation, as long as spine coordinates were hand-written and not tool-generated.<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9050Extrusion Edge Cases2015-10-30T14:15:56Z<p>Sevaa: </p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclic)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the points of this spine.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D.<br />
<br />
==== Public Example ====<br />
<br />
The Harrier model in the Savage model archive actually has extrusions in the -Y direction. Both plane wings are implemented that way. Under X3DOM and Xj3D, the wings are misrendered.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
<br />
=== Floating Point Rounding ===<br />
<br />
The spec calls for conditionals based upon floating point arithmetic results, specifically, the determination of collinearity. Floating point calculations being inherently imprecise, this is a huge can of worms. Details to follow.<br />
<br />
Determination of point coincidence, however, is a safe operation, as long as spine coordinates were hand-written and not tool-generated.<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9049Extrusion Edge Cases2015-10-30T14:12:56Z<p>Sevaa: /* Public Example */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the points of this spine.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D.<br />
<br />
==== Public Example ====<br />
<br />
The Harrier model in the Savage model archive actually has extrusions in the -Y direction. Both plane wings are implemented that way. Under X3DOM and Xj3D, the wings are misrendered.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9048Extrusion Edge Cases2015-10-30T14:12:19Z<p>Sevaa: /* Straight spine in -Y direction */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the points of this spine.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D.<br />
<br />
==== Public Example ====<br />
<br />
The Harrier model in the Savage model archive actually has extrusions in the -Y direction. Both plane wings are implemented that way.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9047Extrusion Edge Cases2015-10-29T21:28:00Z<p>Sevaa: /* Coincident Spine Points */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points and Y ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule might provide different results (see the example below, point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the points of this spine.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9046Extrusion Edge Cases2015-10-29T21:11:28Z<p>Sevaa: /* Straight spine in -Y direction */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3 in the example). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the points of this spine.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9045Extrusion Edge Cases2015-10-29T21:11:07Z<p>Sevaa: /* Spine with ambiguous direction */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3 in the example). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the points of this spine.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D,.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonnull spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9044Extrusion Edge Cases2015-10-29T20:58:41Z<p>Sevaa: /* Example */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3 in the example). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the points of this spine.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D,.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonzero length spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but one frustum is visible while the other is not. Under Xj3D, it doesn't appear at all.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9043Extrusion Edge Cases2015-10-29T20:12:44Z<p>Sevaa: /* Rules for Collinear Spines */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3 in the example). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the points of this spine.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are still some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D,.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonzero length spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but the outer frustum is visible while the inner is not. Under Xj3D, it doesn't appear at all.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9042Extrusion Edge Cases2015-10-29T20:10:27Z<p>Sevaa: /* Example */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3 in the example). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the points of this spine.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The proposed extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DDOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D,.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonzero length spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but the outer frustum is visible while the inner is not. Under Xj3D, it doesn't appear at all.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9041Extrusion Edge Cases2015-10-29T20:09:33Z<p>Sevaa: /* Example */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3 in the example). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the points of this spine.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The suggested extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DDOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D,.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonzero length spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4" beginCap="false" endCap="false"/></code><br />
<br />
It's supposed to represent two square frusta, where the bottom base of the smaller one is glued to the top base of the larger one. <br />
<br />
Under X3DOM, it appears entirely flat. Under InstantReality, it appears, but the outer frustum is visible while the inner is not. Under Xj3D, it doesn't appear at all.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9040Extrusion Edge Cases2015-10-29T20:00:18Z<p>Sevaa: /* Spine with ambiguous direction */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3 in the example). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the points of this spine.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The suggested extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DDOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D,.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests using a nonzero length spine segment, but the spec doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4"/></code><br />
<br />
Under Xj3D and X3DOM is doesn't appear at all. Under InstantReality, it appears, but the inner fold isn't there.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9039Extrusion Edge Cases2015-10-29T19:58:19Z<p>Sevaa: /* Example */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3 in the example). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle. Let's consider the generation of the CSP Y for the points of this spine.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The suggested extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DDOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D,.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests the first nonzero length spine segment, but the standard doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4"/></code><br />
<br />
Under Xj3D and X3DOM is doesn't appear at all. Under InstantReality, it appears, but the inner fold isn't there.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9038Extrusion Edge Cases2015-10-29T19:56:16Z<p>Sevaa: /* Proposed rule amendment */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed Amendment for the Angle/Endpoint Rules ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3 in the example). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The suggested extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DDOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D,.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests the first nonzero length spine segment, but the standard doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4"/></code><br />
<br />
Under Xj3D and X3DOM is doesn't appear at all. Under InstantReality, it appears, but the inner fold isn't there.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9037Extrusion Edge Cases2015-10-29T19:51:16Z<p>Sevaa: /* Example */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed rule amendment ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3 in the example). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The suggested extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-5 0 0 0 0 0 4 4 0 4 4 0 4 4 0 8 0 0" crossSection="-1 0 0 1 1 0 -1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-5,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce different shapes for such a geometry.<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DDOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D,.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests the first nonzero length spine segment, but the standard doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4"/></code><br />
<br />
Under Xj3D and X3DOM is doesn't appear at all. Under InstantReality, it appears, but the inner fold isn't there.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9036Extrusion Edge Cases2015-10-29T19:45:44Z<p>Sevaa: /* The Existing Spec */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The key algorithm for the Extrusion node deals with calculation of the spine-aligned cross section plane (SCP) for every point of the spine. The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of appearance in the spec:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- for the first point in an open spine, subtracting the next spine point from the current one<br />
- for the last point in an open spine, subtracting the current spine point from the previous one, let's call those two together "the endpoint rules"<br />
- for entirely collinear spine - using the spine direction, let's call it "the rotation rule"<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem, the basic angle rule works for those. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the same order:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- if available, reuse of the previous Z<br />
- if not, look-ahead to the first defined Z<br />
- for entirely collinear splines, the Z axis of the coordinate system, rotated, AKA "the rotation rule"<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed rule amendment ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3 in the example). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The suggested extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-1 0 0 0 0 0 1 1 0 1 1 0 1 1 0 2 0 0" crossSection="-1 0 1 1 1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-1,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce extremely bizarre shapes for such a geometry.<br />
<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DDOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D,.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests the first nonzero length spine segment, but the standard doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4"/></code><br />
<br />
Under Xj3D and X3DOM is doesn't appear at all. Under InstantReality, it appears, but the inner fold isn't there.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9035Extrusion Edge Cases2015-10-29T17:35:01Z<p>Sevaa: /* Spine with ambiguous direction */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The algorithm for generating the spine-aligned cross section plane (SCP) is ambiguous, hard to follow, sometimes ill-defined.<br />
<br />
The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of precedence as suggested by the standard:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- subtracting the next spine point from the current one (first point in an open spine)<br />
- subtracting the current spine point from the previous one, let's call those two together "the endpoint rules" (last point in an open spine)<br />
- using the spine direction, in case of a fully collinear spine (the notion of "spine direction" is not defined)<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the suggested order of preference:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- reuse of the previous Z (if available)<br />
- look-ahead to the first defined Z (if not)<br />
- the Z axis of the coordinate system, rotated (the case of entirely collinear splines)<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed rule amendment ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3 in the example). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The suggested extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-1 0 0 0 0 0 1 1 0 1 1 0 1 1 0 2 0 0" crossSection="-1 0 1 1 1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-1,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce extremely bizarre shapes for such a geometry.<br />
<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DDOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D,.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests the first nonzero length spine segment, but the standard doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4"/></code><br />
<br />
Under Xj3D and X3DOM is doesn't appear at all. Under InstantReality, it appears, but the inner fold isn't there.<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9034Extrusion Edge Cases2015-10-29T17:34:12Z<p>Sevaa: /* Rules for Collinear Spines */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The algorithm for generating the spine-aligned cross section plane (SCP) is ambiguous, hard to follow, sometimes ill-defined.<br />
<br />
The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of precedence as suggested by the standard:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- subtracting the next spine point from the current one (first point in an open spine)<br />
- subtracting the current spine point from the previous one, let's call those two together "the endpoint rules" (last point in an open spine)<br />
- using the spine direction, in case of a fully collinear spine (the notion of "spine direction" is not defined)<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the suggested order of preference:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- reuse of the previous Z (if available)<br />
- look-ahead to the first defined Z (if not)<br />
- the Z axis of the coordinate system, rotated (the case of entirely collinear splines)<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed rule amendment ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3 in the example). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The suggested extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-1 0 0 0 0 0 1 1 0 1 1 0 1 1 0 2 0 0" crossSection="-1 0 1 1 1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-1,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce extremely bizarre shapes for such a geometry.<br />
<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline|(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}}, and those are the X and Z axes of the SCP.<br />
<br />
X3DDOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D,.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests the first nonzero length spine segment, but the standard doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4"/></code><br />
<br />
Under Xj3D and X3DOM is doesn't appear at all. Under InstantReality, it appears, but the inner fold isn't there.<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9033Extrusion Edge Cases2015-10-29T17:33:26Z<p>Sevaa: /* Straight spine in -Y direction */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The algorithm for generating the spine-aligned cross section plane (SCP) is ambiguous, hard to follow, sometimes ill-defined.<br />
<br />
The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of precedence as suggested by the standard:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- subtracting the next spine point from the current one (first point in an open spine)<br />
- subtracting the current spine point from the previous one, let's call those two together "the endpoint rules" (last point in an open spine)<br />
- using the spine direction, in case of a fully collinear spine (the notion of "spine direction" is not defined)<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the suggested order of preference:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- reuse of the previous Z (if available)<br />
- look-ahead to the first defined Z (if not)<br />
- the Z axis of the coordinate system, rotated (the case of entirely collinear splines)<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed rule amendment ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3 in the example). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The suggested extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-1 0 0 0 0 0 1 1 0 1 1 0 1 1 0 2 0 0" crossSection="-1 0 1 1 1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-1,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce extremely bizarre shapes for such a geometry.<br />
<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline:(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}, and those are the X and Z axes of the SCP.<br />
<br />
X3DDOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
<code><Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 0 2 1 0 -1 0"/><br />
</Shape></code><br />
<br />
It looks one way under X3DOM and InstantReality, another way under Xj3D,.<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests the first nonzero length spine segment, but the standard doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4"/></code><br />
<br />
Under Xj3D and X3DOM is doesn't appear at all. Under InstantReality, it appears, but the inner fold isn't there.<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9032Extrusion Edge Cases2015-10-29T17:26:35Z<p>Sevaa: /* Proposed rule amendment */</p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The algorithm for generating the spine-aligned cross section plane (SCP) is ambiguous, hard to follow, sometimes ill-defined.<br />
<br />
The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of precedence as suggested by the standard:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- subtracting the next spine point from the current one (first point in an open spine)<br />
- subtracting the current spine point from the previous one, let's call those two together "the endpoint rules" (last point in an open spine)<br />
- using the spine direction, in case of a fully collinear spine (the notion of "spine direction" is not defined)<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the suggested order of preference:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- reuse of the previous Z (if available)<br />
- look-ahead to the first defined Z (if not)<br />
- the Z axis of the coordinate system, rotated (the case of entirely collinear splines)<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed rule amendment ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rule for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3 in the example). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The suggested extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-1 0 0 0 0 0 1 1 0 1 1 0 1 1 0 2 0 0" crossSection="-1 0 1 1 1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-1,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce extremely bizarre shapes for such a geometry.<br />
<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline:(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}, and those are the X and Z axes of the SCP.<br />
<br />
X3DDOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><br />
<Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 1 1 1 0 -1 0"/><br />
</Shape><br />
<br />
<Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 1 1 1 0 -1 0"/><br />
</Shape><br />
</code><br />
<br />
It looks three different ways under X3DOM, Xj3D, and InstantReality.<br />
<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests the first nonzero length spine segment, but the standard doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4"/></code><br />
<br />
Under Xj3D and X3DOM is doesn't appear at all. Under InstantReality, it appears, but the inner fold isn't there.<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9031Extrusion Edge Cases2015-10-29T17:25:04Z<p>Sevaa: </p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== The Existing Spec ==<br />
<br />
The algorithm for generating the spine-aligned cross section plane (SCP) is ambiguous, hard to follow, sometimes ill-defined.<br />
<br />
The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of precedence as suggested by the standard:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- subtracting the next spine point from the current one (first point in an open spine)<br />
- subtracting the current spine point from the previous one, let's call those two together "the endpoint rules" (last point in an open spine)<br />
- using the spine direction, in case of a fully collinear spine (the notion of "spine direction" is not defined)<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the suggested order of preference:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- reuse of the previous Z (if available)<br />
- look-ahead to the first defined Z (if not)<br />
- the Z axis of the coordinate system, rotated (the case of entirely collinear splines)<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
== Proposed rule amendment ==<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rules for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
== Problems with the Spec ==<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3 in the example). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The suggested extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-1 0 0 0 0 0 1 1 0 1 1 0 1 1 0 2 0 0" crossSection="-1 0 1 1 1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-1,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce extremely bizarre shapes for such a geometry.<br />
<br />
<br />
=== Rules for Collinear Spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline:(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}, and those are the X and Z axes of the SCP.<br />
<br />
X3DDOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><br />
<Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 1 1 1 0 -1 0"/><br />
</Shape><br />
<br />
<Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 1 1 1 0 -1 0"/><br />
</Shape><br />
</code><br />
<br />
It looks three different ways under X3DOM, Xj3D, and InstantReality.<br />
<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests the first nonzero length spine segment, but the standard doesn't say so. And it seems like the implementors use, instead, the first and the last point of the spine, which is simpler, but open to errors. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
<br />
==== Example ====<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4"/></code><br />
<br />
Under Xj3D and X3DOM is doesn't appear at all. Under InstantReality, it appears, but the inner fold isn't there.<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9030Extrusion Edge Cases2015-10-29T17:10:52Z<p>Sevaa: </p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== Problem issues ==<br />
<br />
The algorithm for generating the spine-aligned cross section plane (SCP) is ambiguous, hard to follow, sometimes ill-defined.<br />
<br />
The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of precedence as suggested by the standard:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- subtracting the next spine point from the current one (first point in an open spine)<br />
- subtracting the current spine point from the previous one, let's call those two together "the endpoint rules" (last point in an open spine)<br />
- using the spine direction, in case of a fully collinear spine (the notion of "spine direction" is not defined)<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the suggested order of preference:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- reuse of the previous Z (if available)<br />
- look-ahead to the first defined Z (if not)<br />
- the Z axis of the coordinate system, rotated (the case of entirely collinear splines)<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
=== Proposed rule extension ===<br />
<br />
The spec does mention the desire that the SCP Y approximate the tangent to the spine. In spirit of that, we might extend the angle/endpoint rules for both Y and Z by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment in place, the reuse/look-ahead rules for Y becomes unnecessary. <br />
<br />
For spines with all distinct points, this rule extension will produce no difference in tesselation. As for the geometries with matching points, their treatment is wildly inconsistent under existing implementations as it is, so the harm will be minimal.<br />
<br />
See the example below for the effect of this rule.<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the angle rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3 in the example). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The suggested extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-1 0 0 0 0 0 1 1 0 1 1 0 1 1 0 2 0 0" crossSection="-1 0 1 1 1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-1,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce extremely bizarre shapes for such a geometry.<br />
<br />
<br />
=== Collinear spines ===<br />
<br />
If the spine is entirely collinear (and thus doesn't allow for SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline:(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}, and those are the X and Z axes of the SCP.<br />
<br />
X3DDOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><br />
<Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 1 1 1 0 -1 0"/><br />
</Shape><br />
<br />
<Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 1 1 1 0 -1 0"/><br />
</Shape><br />
</code><br />
<br />
It looks three different ways under X3DOM, Xj3D, and InstantReality.<br />
<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests the first nonzero length spine segment, but the standard doesn't say so. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4"/></code><br />
<br />
Under Xj3D and X3DOM is doesn't appear at all. Under InstantReality, it appears, but the inner fold isn't there.<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9029Extrusion Edge Cases2015-10-29T17:00:28Z<p>Sevaa: </p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== Problem issues ==<br />
<br />
The algorithm for generating the spine-aligned cross section plane (SCP) is ambiguous, hard to follow, sometimes ill-defined.<br />
<br />
The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of precedence as suggested by the standard:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (closed spines are treated as cyclical)<br />
- subtracting the next spine point from the current one (first point in an open spine)<br />
- subtracting the current spine point from the previous one, let's call those two together "the endpoint rules" (last point in an open spine)<br />
- using the spine direction, in case of a fully collinear spine (the notion of "spine direction" is not defined)<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem. Null segments (AKA coincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the suggested order of preference:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- reuse of the previous Z (if available)<br />
- look-ahead to the first defined Z (if not)<br />
- the Z axis of the coordinate system, rotated (the case of entirely collinear splines)<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Coincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the subtraction rule and the reuse/look-ahead rule are in conflict here, and might provide different results (see the example below, for point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
The spirit of the spec, however, might suggest that the applicability of the angle/endpoint rules for both Y and Z can be extended by replacing the notions of the next/previous point with next/previous '''distinct''' point.With this amendment, the reuse/look-ahead rule becomes unnecessary. The spec does mention the desire that the SCP Y approximate the tangent to the spine.<br />
<br />
However, introducing such a difference in rules might throw off existing implementations. Again, some existing implementations (notably X3DOM) are non-compliant with the current spec as it is.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The suggested extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-1 0 0 0 0 0 1 1 0 1 1 0 1 1 0 2 0 0" crossSection="-1 0 1 1 1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-1,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce extremely bizarre shapes for such a node.<br />
<br />
<br />
=== Collinear spines ===<br />
<br />
If the spine is entirely collinear (and thus allows for no SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline:(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}, and those are the X and Z axes of the SCP.<br />
<br />
X3DDOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><br />
<Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 1 1 1 0 -1 0"/><br />
</Shape><br />
<br />
<Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 1 1 1 0 -1 0"/><br />
</Shape><br />
</code><br />
<br />
It looks three different ways under X3DOM, Xj3D, and InstantReality.<br />
<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests the first nonzero length spine segment, but the standard doesn't say so. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4"/></code><br />
<br />
Under Xj3D and X3DOM is doesn't appear at all. Under InstantReality, it appears, but the inner fold isn't there.<br />
<br />
<br />
== Possible solutions ==<br />
<br />
<br />
== Resolved issues ==<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9028Extrusion Edge Cases2015-10-29T16:58:52Z<p>Sevaa: </p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== Problem issues ==<br />
<br />
The algorithm for generating the spine-aligned cross section plane (SCP) is ambiguous, hard to follow, sometimes ill-defined.<br />
<br />
The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For SCP Y, there are the following rules, in order of precedence as suggested by the standard:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (open spines are treated as cyclical)<br />
- subtracting the next spine point from the current one (first point in an open spine)<br />
- subtracting the current spine point from the previous one, let's call those two together "the endpoint rules" (last point in an open spine)<br />
- using the spine direction, in case of a fully collinear spine (the notion of "spine direction" is not defined)<br />
- reuse and look-ahead within the point cluster, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For SCP Y, collinear spine segments are not a problem. Null segments (AKA conincident points), however, are.<br />
<br />
For SCP Z, there are the following rules, in the suggested order of preference:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- reuse of the previous Z (if available)<br />
- look-ahead to the first defined Z (if not)<br />
- the Z axis of the coordinate system, rotated (the case of entirely collinear splines)<br />
<br />
For SCP Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Conincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. The difference of the adjacent spine points might not be a null vector; the subtraction rule and the reuse/lookahead rule are in conflict here, and might provide different results (see the example below, for point #3). The standard doesn't specify which rule takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might as well say so.<br />
<br />
The spirit of the spec, however, might suggest that the applicability of the angle/endpoint rules for both Y and Z can be extended by replacing the notions of the next/previous point with next/previous '''distinct''' point.With this amendment, the reuse/look-ahead rule becomes unnecessary. The spec does mention the desire that the SCP Y approximate the tangent to the spine.<br />
<br />
However, introducing such a differece in rules might throw off existing implementations. Again, some existing implementations (e. g. X3DOM) are non-compliant with the current spec as it is.<br />
<br />
==== Example ====<br />
<br />
The case of three coincident spine points. We have a cluster of three coincident points in the middle.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule produces the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The suggested extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules for Z would produce a nonnull SCP Z for any of the points. The extended angle rule, however, would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
The following geometry implements the example:<br />
<br />
<code><Extrusion spine="-1 0 0 0 0 0 1 1 0 1 1 0 1 1 0 2 0 0" crossSection="-1 0 1 1 1 0" scale="1 1 1 1 1 1 2 2 3 3 3 3"/></code><br />
<br />
The first spine point at (-1,0,0) was added to give it a valid SCP Z.<br />
<br />
X3DOM, Xj3D and InstantReality all produce extremely bizarre shapes for such a node.<br />
<br />
<br />
=== Collinear spines ===<br />
<br />
If the spine is entirely collinear (and thus allows for no SCP Z calculation by the angle rule), the standard calls for generating the SCP in the following manner ("the rotation rule"):<br />
<br />
- The direction of the spine is determined (as a unit vector)<br />
- The rotation that takes the vector {{Overline:(0,1,0)}} to the said direction vector is calculated<br />
- This rotation is applied to vectors {{Overline|(1,0,0)}} and {{Overline|(0,0,1)}, and those are the X and Z axes of the SCP.<br />
<br />
X3DDOM implements the rotation rule in a weird way. Under X3DOM, an extrusion in in X or Z direction looks completely flat.<br />
<br />
Discounting that, there are some problems with the rule.<br />
<br />
=== Straight spine in -Y direction ===<br />
<br />
If the vector in the 1st step happens to be (0,-1,0), the rotation in the 2nd step is not unique. X3DOM, InstantReality, and Xj3D implement this case in three different ways. Consider the following scene:<br />
<br />
<code><br />
<Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="0 0 0 0 1 0" solid="false" crossSection="-1 0 1 1 1 0 -1 0"/><br />
</Shape><br />
<br />
<Shape><br />
<Appearance><Material diffuseColor="0 0.5 0.5"/></Appearance><br />
<Extrusion spine="3 1 0 3 0 0" solid="false" crossSection="-1 0 1 1 1 0 -1 0"/><br />
</Shape><br />
</code><br />
<br />
It looks three different ways under X3DOM, Xj3D, and InstantReality.<br />
<br />
<br />
=== Spine with ambiguous direction ===<br />
<br />
The spec doesn't specify what constitutes the "spine direction". It refers to to "the vector formed by the spine points", but depending on the choice of points, it might be a different vector (up to the sign), or even a null one. Common sense suggests the first nonzero length spine segment, but the standard doesn't say so. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but what is its direction?<br />
<br />
Consider the following geometry:<br />
<br />
<code><Extrusion spine="0 0 0 0 1 0 0 0 0" solid="false" scale="1 1 1.2 1.2 1.4 1.4"/></code><br />
<br />
Under Xj3D and X3DOM is doesn't appear at all. Under InstantReality, it appears, but the inner fold isn't there.<br />
<br />
<br />
== Possible solutions ==<br />
<br />
<br />
== Resolved issues ==<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9027Extrusion Edge Cases2015-10-29T15:39:13Z<p>Sevaa: </p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== Problem issues ==<br />
<br />
The algorithm for generating the spine-aligned cross section plane (SCP) is ambiguous, hard to follow, sometimes ill-defined.<br />
<br />
The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For Y, there are the following rules, in order of precedence as suggested by the standard:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (open spines are treated as cyclical)<br />
- subtracting the next spine point from the current one (first point in an open spine)<br />
- subtracting the current spine point from the previous one, let's call those two together "the endpoint rules" (last point in an open spine)<br />
- using the spine direction, in case of a fully collinear spine (the notion of "spine direction" is not defined)<br />
- reuse and look-ahead, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For Y, collinear spine segments are not a problem. Null segments (AKA conincident points), however, are.<br />
<br />
For Z, there are the following rules, in the suggested order of preference:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- reuse of the previous Z (if available)<br />
- look-ahead to the first defined Z (if not)<br />
- the Z axis of the coordinate system, rotated (the case of entirely collinear splines)<br />
<br />
For Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Conincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. First, the difference of the adjacent spine points might not be a null vector; the subtraction rule and the reuse/lookahead rule are in conflict here, and might provide different results. The standard doesn't specify which one takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might say so.<br />
<br />
The spirit of the spec, however, might suggest that the applicability of the angle/endpoint rules for both Y and Z can be extended by replacing the notions of the next/previous point with next/previous '''distinct''' point.With this amendment, the reuse/look-ahead rule becomes unnecessary. However, this might throw off existing implementations. Again, some existing implementations might be non-compliant with the current spec as it is.<br />
<br />
[[Example]]<br />
<br />
The case of three coincident spine points.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
For point #1, the angle rule and the reuse rule produce the matching results for SCP Y - the vector {{overline|(01)}} (in red).<br />
<br />
For point #2, the angle rule produces a null Y. The reuse rule suggests the vector {{overline|(01)}} (in red). The extended angle rule, on the other hand, would produce Y as the vector {{overline|(04)}} (in green).<br />
<br />
For point #3, the angle rule would produce {{overline|(34)}} (in yellow), but the reuse rule would produce {{overline|(01)}} (red). This is a case of two rules producing valid but different results. That's why some kind of clarification of rule precedence in the spec would be necessary. The same unresolved contradiction in rules would arise even in case of two conincident points in the middle of a spine.<br />
<br />
The suggested extended angle rule would still produce {{overline|(04)}} (green) for point # 3.<br />
<br />
It's worth noting that for a spine like this, '''none''' of the existing rules would produce a nonnull SCP Z for any of the points. The extended angle rule, however would; the Z would be produced as {{overline|(10)}}×{{overline|(34)}}<br />
<br />
A similar example can be drawn up for an open spine with two conincident spine points in the beginning or in the end.<br />
<br />
=== Collinear spines ===<br />
<br />
If the spine is collinear (and thus allows for no SCP-Z calculation), the standard calls for generating the SCP in the following manner:<br />
<br />
A. The direction of the spine is determined (as a vector)<br />
B. The rotation that takes the vector (0,1,0) to the said vector is calculated<br />
C. This rotation is applied to vectors (1,0,0) and (0,0,1), and those are the X and Z axes of the SCP.<br />
<br />
There are some problems with that algorithm.<br />
<br />
1. If the vector in step A happens to be (0,-1,0), the rotation in step B is not unique.<br />
<br />
2. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but the standard doesn't specify what constitutes the "spine direction". Common sense suggests the first nonzero length spine segment, but the standard doesn't say so.<br />
<br />
Also, it's worth noting that the popular implementations out there don't follow those rules.<br />
<br />
== Possible solutions ==<br />
<br />
<br />
== Resolved issues ==<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Template:Overline&diff=9026Template:Overline2015-10-29T15:26:53Z<p>Sevaa: Created page with "<span style="text-decoration:overline;">{{{1}}}</span>"</p>
<hr />
<div><span style="text-decoration:overline;">{{{1}}}</span></div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9025Extrusion Edge Cases2015-10-29T15:17:57Z<p>Sevaa: </p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== Problem issues ==<br />
<br />
The algorithm for generating the spine-aligned cross section plane (SCP) is ambiguous, hard to follow, sometimes ill-defined.<br />
<br />
The algorithm boils down to determining two vectors for every spine point - Y and Z. X is then calculated by cross product of those two.<br />
<br />
For Y, there are the following rules, in order of precedence as suggested by the standard:<br />
<br />
- subtracting the next spine point from the previous one, let's call it "the angle rule" (open spines are treated as cyclical)<br />
- subtracting the next spine point from the current one (first point in an open spine)<br />
- subtracting the current spine point from the previous one, let's call those two together "the endpoint rules" (last point in an open spine)<br />
- using the spine direction, in case of a fully collinear spine (the notion of "spine direction" is not defined)<br />
- reuse and look-ahead, suggested implicitly by the "coincident points have the same SCP" line in the spec<br />
<br />
For Y, collinear spine segments are not a problem. Null segments (AKA conincident points), however, are.<br />
<br />
For Z, there are the following rules, in the suggested order of preference:<br />
<br />
- cross product of the two adjacent spine segments, let's call it "the angle rule"<br />
- reuse of the previous Z (if available)<br />
- look-ahead to the first defined Z (if not)<br />
- the Z axis of the coordinate system, rotated (the case of entirely collinear splines)<br />
<br />
For Z calculation, both null and collinear spine segments warrant special treatment.<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Conincident spine points are allowed under the spec. For those, the rules for generating Y are in conflict. First, the difference of the adjacent spine points might not be a null vector; the subtraction rule and the reuse/lookahead rule are in conflict here, and might provide different results. The standard doesn't specify which one takes precedence. If the reuse rule is only supposed to kick in if the subtraction rule returns a null vector, the standard might say so.<br />
<br />
The spirit of the spec, however, might suggest that the applicability of the angle/endpoint rules for both Y and Z can be extended by replacing the notions of the next/previous point with next/previous '''distinct''' point. With this amendment, the reuse/look-ahead rule becomes unnecessary. However, this might throw off existing implementations. Again, some existing implementations might be non-compliant with the current spec as it is.<br />
<br />
[[Examples]]<br />
<br />
The case of three coincident spine points.<br />
<br />
[[File:threecoin.jpg]]<br />
<br />
<br />
The angle rule for those does produce a null vector. <br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Conincident Spine Points with a Bend ===<br />
<br />
Consider the following spine:<br />
<br />
(0,0,0) - (0,1,0) - (0,1,0) - (0,1,1)<br />
<br />
=== Collinear spines ===<br />
<br />
If the spine is collinear (and thus allows for no SCP-Z calculation), the standard calls for generating the SCP in the following manner:<br />
<br />
A. The direction of the spine is determined (as a vector)<br />
B. The rotation that takes the vector (0,1,0) to the said vector is calculated<br />
C. This rotation is applied to vectors (1,0,0) and (0,0,1), and those are the X and Z axes of the SCP.<br />
<br />
There are some problems with that algorithm.<br />
<br />
1. If the vector in step A happens to be (0,-1,0), the rotation in step B is not unique.<br />
<br />
2. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but the standard doesn't specify what constitutes the "spine direction". Common sense suggests the first nonzero length spine segment, but the standard doesn't say so.<br />
<br />
Also, it's worth noting that the popular implementations out there don't follow those rules.<br />
<br />
== Possible solutions ==<br />
<br />
<br />
== Resolved issues ==<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9024Extrusion Edge Cases2015-10-28T21:05:35Z<p>Sevaa: </p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== Problem issues ==<br />
<br />
The algorithm for generating the spine-aligned cross section plane (SCP) is ambiguous, hard to follow, sometimes ill-defined.<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Conincident spine points are allowed under the spec.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Conincident Spine Points with a Bend ===<br />
<br />
Consider the following spine:<br />
<br />
(0,0,0) - (0,1,0) - (0,1,0) - (0,1,1)<br />
<br />
=== Collinear spines ===<br />
<br />
If the spine is collinear (and thus allows for no SCP-Z calculation), the standard calls for generating the SCP in the following manner:<br />
<br />
A. The direction of the spine is determined (as a vector)<br />
B. The rotation that takes the vector (0,1,0) to the said vector is calculated<br />
C. This rotation is applied to vectors (1,0,0) and (0,0,1), and those are the X and Z axes of the SCP.<br />
<br />
There are some problems with that algorithm.<br />
<br />
1. If the vector in step A happens to be (0,-1,0), the rotation in step B is not unique.<br />
<br />
2. If the spine goes: (0,0,0) - (0,1,0) - (0,0,0), it's collinear, but the standard doesn't specify what constitutes the "spine direction". Common sense suggests the first nonzero length spine segment, but the standard doesn't say so.<br />
<br />
Also, it's worth noting that the popular implementations out there don't follow those rules.<br />
<br />
== Possible solutions ==<br />
<br />
<br />
== Resolved issues ==<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaahttps://www.web3d.org/wiki/index.php?title=Extrusion_Edge_Cases&diff=9023Extrusion Edge Cases2015-10-28T20:58:44Z<p>Sevaa: </p>
<hr />
<div>The [http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion Extrusion] node specification has ambiguities [http://web3d.org/pipermail/x3d-public_web3d.org/2015-June/subject.html#3434]<br />
<br />
This wiki page supports discussion on the x3d-public mailing list regarding Extrusion specification edge cases that make consistent modeling difficult.<br />
<br />
== Problem issues ==<br />
<br />
The algorithm for generating the spine-aligned cross section plane (SCP) is ambiguous, hard to follow, sometimes ill-defined.<br />
<br />
=== Coincident Spine Points ===<br />
<br />
Conincident spine points are allowed under the spec.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Conincident Spine Points with a Bend ===<br />
<br />
Consider the following spine:<br />
<br />
(0,0,0) - (0,1,0) - (0,1,0) - (0,1,1)<br />
<br />
=== Collinear spines ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Possible solutions ==<br />
<br />
<br />
== Resolved issues ==<br />
<br />
<br />
== References ==<br />
<br />
<br />
== Resources ==</div>Sevaa