View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0027075 | Community | OCCT:Modeling Data | public | 2016-01-13 11:53 | 2023-08-01 15:06 |
| Reporter | Roman Lygin | Assigned To | |||
| Priority | normal | Severity | minor | ||
| Status | assigned | Resolution | open | ||
| Product Version | 6.9.1 | ||||
| Target Version | Unscheduled | ||||
| Summary | 0027075: Geom_BSplineCurve cannot be evaluated at the end parameter | ||||
| Description | A B-Spline curve of degree 2 has a range [0,1]. It has the following boundary knots with multiplicities: 1 : -0.0625 1 2 : 0 2 ... 18 : 1 2 19 : 1.0625 2 and has 34 poles. The formula number_of_poles = sum_of_mults - degree - 1 is respected. Given that boundary knots (-0.0625 and 1.0625) are not of multiplicity degree+1, the definition range is [0,1]. However the curve cannot be evaluated at parameter 1 - the value [-1#IND0,-1#IND0] (or perhaps just uninitialized value) is returned. On the other hand, ::Segment(0,1) works correctly by removing the boundary poles. Thus, apparently there is some issue in evaluation process. The curve comes from an IGES file where it has been specified as periodic (i.e. in the sending CAD system it was a periodic B-Spline). This seems to be reasonable as the curve essentially is a closed/periodic one. IGES stores all B-Splines using flat knots and meeting the formula above number_of_poles = sum_of_mults - degree - 1. For periodic B-Splines it just stores a flag but the arrays of knots/multiplicities/poles are not recomputed similar to OCC conventions. | ||||
| Steps To Reproduce | restore pcurve pc 2dcvalue pc 0 x y dump x y #correct 2dcvalue pc 1 x y dump x y #incorrect | ||||
| Tags | No tags attached. | ||||
| Test case number | |||||
|
|
pcurve (1,507 bytes) |
|
|
Dear Roman, You wrote: "IGES stores all B-Splines using flat knots and meeting the formula above number_of_poles = sum_of_mults - degree - 1. For periodic B-Splines it just stores a flag but the arrays of knots/multiplicities/poles are not recomputed similar to OCC conventions." Do you mean OCC IGES reader does this? Or IGES file already contains such definition? Could you attach the IGES file here? |
|
|
Dear Mikhail, This is per IGES specification itself. The excerpt from the original file is enclosed. The point however is that the 'pcurve' corresponds to a real data that may come from outside or can be created in OCC. The issue is not about the OCC IGES reader. |
|
|
iges-excerpt.igs (3,362 bytes) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-01-13 11:53 | Roman Lygin | New Issue | |
| 2016-01-13 11:53 | Roman Lygin | Assigned To | => msv |
| 2016-01-13 11:53 | Roman Lygin | File Added: pcurve | |
| 2016-01-13 12:35 |
|
Note Added: 0049818 | |
| 2016-01-13 12:35 |
|
Assigned To | msv => Roman Lygin |
| 2016-01-13 12:35 |
|
Status | new => feedback |
| 2016-01-13 12:54 | Roman Lygin | Note Added: 0049819 | |
| 2016-01-13 12:54 | Roman Lygin | File Added: iges-excerpt.igs | |
| 2016-01-13 12:55 | Roman Lygin | Assigned To | Roman Lygin => msv |
| 2016-01-13 12:55 | Roman Lygin | Status | feedback => assigned |
| 2016-01-13 13:08 |
|
Assigned To | msv => ssv |
| 2016-10-25 17:00 |
|
Target Version | 7.1.0 => 7.2.0 |
| 2017-07-20 15:30 |
|
Target Version | 7.2.0 => 7.3.0 |
| 2017-12-05 17:09 |
|
Target Version | 7.3.0 => 7.4.0 |
| 2019-08-12 16:45 |
|
Target Version | 7.4.0 => 7.5.0 |
| 2020-09-14 22:54 |
|
Target Version | 7.5.0 => 7.6.0 |
| 2021-08-29 18:51 |
|
Target Version | 7.6.0 => 7.7.0 |
| 2022-10-24 10:43 |
|
Target Version | 7.7.0 => 7.8.0 |
| 2023-08-01 15:06 | dpasukhi | Target Version | 7.8.0 => Unscheduled |
