View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0025971 | Community | OCCT:Modeling Data | public | 2015-03-23 12:20 | 2015-06-25 16:08 |
| Reporter | Roman Lygin | Assigned To | bugmaster | ||
| Priority | high | Severity | minor | ||
| Status | closed | Resolution | fixed | ||
| Product Version | 6.8.0 | ||||
| Target Version | 6.9.0 | Fixed in Version | 6.9.0 | ||
| Summary | 0025971: Near B-Spline knots get merged after saving/restoring (exporting/importing) | ||||
| Description | A model coming out of Shape Healing has B-Spline pcurve with knots differing in 17th position. After exporting to STEP it cannot be read back as the precision got lost and knots get fully equal and the B-Spline ctor throws an exception in CheckCurveData(). What happens is the following. The original edge lies on an original longer pcurve and has some shorter range [a,b]. b is very close to an existing B-Spline knot. Then GeomLib::SameRange() called inside FixSameParameter() converts a trimmed curve on the original B-Spline and sets a 3D curve range [A,B]. This B-Spline had a knot very near the split point and although the delta is > Epsilon(K(i)), which is checked in CheckCurveData(), after saving to a text file, the double numbers become fully collapsed. There are different approaches to address this, for instance: 1. Make various adjustments in multiple algorithms (during import/export, ConvertToBSpline, BSplineCurve::Segment(),...) 2. Create an explicit pre-processing function (e.g. in BSplCLib) which would check and adjust knot array by moving them apart by at least Precision::PConfusion(). Such fixes are often made in IGES and STEP importers. 3. Make BSpline ctor less sensitive to merged knots and for instance have it call to the above function. In this case B-Spline ctor itself could be less sensitive to such round-off errors. A discussion will be open on dev.opencascade.org to solicit opinions on the best course of actions. | ||||
| Steps To Reproduce | restore C:/temp/a_328_1.brep a fixshape f a 1e-6 explode f e dump f_4 Knots : 12 : 6.28318530717959 1 13 : 6.28318530717959 4 stepwrite a f C:/temp/f.stp #inside the file there are two merged knots 6.28318530718,6.28318530718 stepread C:/temp/f.stp ff #select 1 numsh ff # no faces tps c #Exception caught for the shell | ||||
| Tags | No tags attached. | ||||
| Test case number | bugs moddata_2(013) bug253, bugs moddata_3(014) bug25971 | ||||
|
|
a_328_1.zip (642 bytes) |
|
|
Branch CR25971 has been created by Roman Lygin. SHA-1: 6ec1e6d868b37ad4b56da887ee2807c3a245b52f Detailed log of new commits: Author: Roman Lygin Date: Tue Mar 24 19:25:28 2015 +0400 0025971: Near B-Spline knots get merged after saving/restoring (exporting/importing) |
|
|
Conservative fix made which only ensures sufficient delta (Precision::PConfusion()) in BSplCLib::Reparametrize(). The other likely candidate InsertKnots() left unchanged until a first case is encountered. The fix ensures that new range really gets [U1, U2] as this may be expected by the caller algorithm (e.g. SameRange() or user's). If the delta between the last and last but one knot is less than required threshold, then iterates back trying to adjust the knot reducing their values. |
|
|
Another candidate for alignment is ShapeConstruct_Curve::FixKnots(). |
|
|
Reviewed. |
|
|
Dear BugMaster, Branch CR25971 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested. SHA-1: 6ec1e6d868b37ad4b56da887ee2807c3a245b52f Number of compiler warnings: occt component: Linux: 18 (18 on master) Windows: 0 (0 on master) products component: Linux: 11 (11 on master) Windows: 4 (4 on master) Regressions/Differences: http://occt-tests/CR25971-master-occt-64/Debian60-64/summary.html http://occt-tests/CR25971-master-occt-64/Windows-64-VC10/summary.html de iges_1 P5 de step_2 B8, C9, D6, E7 de step_3 D1 Testing on Linux: Total MEMORY difference: 88265082 / 88458413 [-0.22%] Total CPU difference: 50133.61000000006 / 53140.31000000024 [-5.66%] Testing on Windows: Total MEMORY difference: 50008751 / 50016623 [-0.02%] Total CPU difference: 14766.446256099613 / 14819.845398399693 [-0.36%] There is difference in images found by testdiff: http://occt-tests/CR25971-master-occt-64/Windows-64-VC10/diff-Windows-64-VC10.html bugs vis bug24717 |
|
|
Branch CR25971 has been updated forcibly by msv. SHA-1: b46ddd23f10d84485997875a013825fbee5f450d |
|
|
I have analyzed one of regressions, the test de iges_1 P5. With the fix, several handled exceptions occur in the method CheckCurveData. In the result, several edges are not fixed, and the nature of regression itself is different number of vertices in the resulting shape. I have caught the problematic knots data in the fixed method BSplCLib::Reparametrize. The input array contains 10 items, with the range [0.67018055240076602,0.70588240000000002]. The requested range is U1=0.70588239799999997, U2=0.70588240000000002. We can see that the new length is equal to 2e-9. There is no room in the range to place 10 knots having distance between them greater than 1e-9. As the result, the procedure ruins the knots sequence, violating ascending order, and this later leads to exception in CheckCurveData. One possible solution would be to restrict movement of knots after scaling, limiting shift value so that after shifting the ratio between neighboring intervals did not changed significantly. This would preserve the form of the knots sequence and even more so avoid distortion of ascending order. However, after discussion with ABV, we came to conclusion that the overall fix could be made in another way. If the coinciding knots are created during splitting in the Segment method, it might be better to treat such cases in that code, rather than let Reparametrize distort the knots form on regular base. Dear Roman, please let me know if you are willing to continue the fix. If so I shall send you private shape data needed to perform the regressed test. |
|
|
One more point is: if Segment() is called with arguments leading to creation of very small interval (<1e-9), I believe it is better to eliminate this interval instead of trying to increase it to 1e-9. This way we can avoid creation of small parametric intervals which are possible source of problems anyway. |
|
|
One more point. It would be very nice to prepare a test case that was a starting point to this issue. I mean a draw script with possible shape (or better shape generated on the fly) that reproduce problem of not enough precision of import/export through a file. Roman, I shall be very pleased if you could prepare a test case. |
|
|
Hi Mikhail, Thank you for your triaging. The very start point was a customer file which I obviously cannot disclose. Anyway, the synthetic reproducer was already provided in the report and is an excerpt of one of the subshapes with similar issues. Please let me know if there is anything you might need further details on. My efforts on fixing have been deferred and unless you want to take ownership of this bug and continue on your own, please do send me the private data, so that I or my team could resume at any moment. |
|
|
Branch CR25971 has been updated forcibly by msv. SHA-1: 35dd50465f24604f938c5cc074a6b4b19f9e5e6d |
|
|
I have re-based the branch CR25971 on current master and put there the newly added test case "bugs fclasses bug25971" based on the steps to reproduce. The test case is classified as "Bad" on master and as "Improvement" on the branch. "Todo" lines are to be removed from the script when the solution is ready to be integrated. |
|
|
Branch CR25971_1 has been created by Roman Lygin. SHA-1: 43ebf89c220b4bbbabdf78ccb907f3b0b594e789 No new revisions were added by this update. |
|
|
Mikhail, Andrey, A new version of the fix (possibly interim) has been pushed as CR25971_1 branch. The status has not been upgraded to resolved yet, as I would like to try a better fix even if the current one seems to work fine. Below are some comments: 1. I've followed your recommendation to address the issue upstream in Segment(). There was already a code that tried to stick the split point to existing knot if the distance was within epsilon. Now this epsilon was increased to at least Precision::PConfusion(). 2. The fix works fine: no regression on public data and on the IGES case de iges_1 P5. The STEP cases ( de step_3 D1 de step_2 B8, C9, D6, E7) now contain the following differences: (example of de step_3 D1) Error : 3 differences with reference data found : Reference data - NBSHAPES : Solid = 0 ( 0 ) Shell = 95 ( 106 ) Face = 95 ( 106 ) Summary = 1451 ( 1665 ) Current data - NBSHAPES : Solid = 0 ( 0 ) Shell = 106 ( 106 ) Face = 106 ( 106 ) Summary = 1665 ( 1665 ) Investigation reveals that prior to the fix there were lost entities (e.g. 11 faces, 95 vs 106) due to exact same error which the bug report 25971 is about - during loopback test, the near knots were saved in a STEP file as equal values and reading back led to exceptions (CheckCurveData() and lost entities). Now the fix addresses this, B-Splines are different and STEP files are stored differently and can be read back. Thus, this is an improvement, not a regression and the reference data needs to be updated. 3. The fix is currently applied to Geom2d_BSplineCurve::Segment(). Natural intent would be to apply it likewise to Geom_BSplineCurve::Segment(), however apparently these codes diverged significantly in the past. So an attempt to synchronize them may likely lead to regressions as this is too sensitive code. Ideally, most B-Spline methods implementations should be template-based and just compile for 2D/3D cases but obviously this is a good effort in its own, and is beyond this bug report. So my course of actions will be: - try to have a synchronized code - run regressions tests on public data - if fails, rollback back to current fix and just insert comments that this 2D-only fix was a deliberate choice - if succeeds, the fix will be pushed to the repository so that you can cover the entire test suite - if fails, rollback - if succeeds, you integrate the entire fix. Does that sound OK with you ? Thank you, Roman |
|
|
For the sake of better clarity, let me add some further details on the original issue: 1. Knots of original 2D B-Spline curve: [1] -1.5707963267949001 double [2] -1.4279966607226364 double ... [10] -0.28559933214452715 double [11] -0.14279966607226346 double [12] 2.2204460492503131e-016 double [13] 0.14279966607226369 double .... [23] 1.5707963267949001 double 2. Edge range on this p-curve: [-1.5707963267949001, 1.3322676295501878e-015] Eps(k12) = 2.2204460492503131e-016 < |1.3322676295501878e-015 - 2.2204460492503131e-016| 3. Segment() is called with (-1.5707963267949001, 1.3322676295501878e-015) and creates: [1] -1.5707963267949001 double ... [11] -0.14279966607226346 double [12] 2.2204460492503131e-016 double [13] 1.3322676295501878e-015 double 4. Reparametrize() is called with (4.7123889803846861, 6.2831853071795880) and creates: new 12 = 6.2831853071795871 new 13 = 6.2831853071795880 Eps (new 12) = 8.8817841970012523e-016, also < | 6.2831853071795880 - 6.2831853071795871| 5. Saving to text format collapses new knots 12 and 13: 6.28318530717958 6.28318530717958 6. Restoring throws an exception. |
|
|
Roman, sorry but I have not found the new branch in the repository. |
|
|
Concerning the plan of actions described in the note 0025971:0039944, it is good. And thank you for the note 0025971:0039945, it just confirms our hypothesis. |
|
|
Branch CR25971_2 has been created by Roman Lygin. SHA-1: 43ebf89c220b4bbbabdf78ccb907f3b0b594e789 No new revisions were added by this update. |
|
|
Branch CR25971_1 has been updated by Roman Lygin. SHA-1: 7d1c80335fc067aac43fb2b6200f4e0b81789654 Detailed log of new commits: Author: Roman Lygin Date: Fri Apr 17 15:31:32 2015 +0400 0025971: Near B-Spline knots get merged after saving/restoring (exporting/importing) |
|
|
Unfortunately the attempt to align implementations did not work out - regressions showed up even after an attempt to redesign the 2D case (see enclosed excerpt for Geom2d_BSplineCurve::Segment()). Using the same code for 3D case produced even greater number of regressions. So the only feasible action at this moment could be to accept the prior fix (in CR25971_1 branch). And at some point in time to allocate a project to align implementations of 2D/3D curve and Geom_BSplineSurface() investigating regressions. |
|
|
Geom2d_BSplineCurve_streamlined_fix_excerpt.zip (1,309 bytes) |
|
|
Dear Roman, I did not understand the nature of your trials in 3D case. Did you tried just the same patch as for 2D? Like the below patch: diff --git a/src/Geom/Geom_BSplineCurve.cxx b/src/Geom/Geom_BSplineCurve.cxx index 01a3a06..2c9de2a 100644 --- a/src/Geom/Geom_BSplineCurve.cxx +++ b/src/Geom/Geom_BSplineCurve.cxx @@ -35,6 +35,7 @@ #include <BSplCLib.hxx> #include <BSplCLib_KnotDistribution.hxx> #include <BSplCLib_MultDistribution.hxx> +#include <Precision.hxx> #include <Standard_NotImplemented.hxx> #include <Standard_ConstructionError.hxx> #include <Standard_OutOfRange.hxx> @@ -570,7 +571,7 @@ void Geom_BSplineCurve::Segment(const Standard_Real U1, AbsUMax = Max(AbsUMax, Max(Abs(FirstParameter()),Abs(LastParameter()))); // Modified by Sergey KHROMOV - Fri Apr 11 12:15:40 2003 End - Standard_Real Eps = 100. * Epsilon(AbsUMax); + Standard_Real Eps = Max (Epsilon(AbsUMax), Precision::PConfusion()); InsertKnots( Knots, Mults, Eps); If not, then I would propose to insert this fix to the branch for testing. |
|
|
Also, the similar simple change can be done in surface methods: Geom_BSplineSurface::Segment Geom_BSplineSurface::CheckAndSegment |
|
|
Branch CR25971_2 has been updated by abv. SHA-1: 6b840be0620a63b35924454e6031be9be5e06860 Detailed log of new commits: Author: Roman Lygin Date: Fri Apr 17 15:31:32 2015 +0400 0025971: Near B-Spline knots get merged after saving/restoring (exporting/importing) Precision used to consider B-Spline knots identical is restricted to be not less than Precision::PConfusion() in Geom2d_BSplineCurve::Segment(). Affected tests updated (improvements) |
|
|
I have pushed the fix rebased on current master and with corrected test cases to branch CR25971_2 |
|
|
Reviewed, please test |
|
|
Hello Mikhail, Andrey, Thank you for your support in moving this forward. I ran out of cycles and won't have any free ones to continue with this any time soon :-(. Just for the record, here is what was my course of actions: 1. Tried the 2D-only fix as in the branch CR25971_1 on public and private set - OK. 2. Tried to have a better 2D case - the one which was attached to this bug report - fail. The need for this reworked/simplified patch is that current code in Geom2d_BSplineCurve::Segment() is prone to issues - the loop analyzing the distance between existing knots and parameters and comparing with aEps may choose a wrong far distant knot. For instance: ki-1, ki, ki+1, ki+2 - all distances < 1e-9 insert U in [ki-1,ki] the loop will stick U to ki+2, not to ki-1. Therefore an attempt was to first find an interval for U (via LocateParameter() which itself should simply call BSplCLib::Hunt() and adjust to ki if U=ki) and then stick to left or right. 3. 0000002 adjusted for Geom_BSplineCurve::Segment() - fail 4. Geom_BSplineSurface::Segment() was in the middle of refactoring (trying to use logic of 0000002) when all those regressions started to show up. So in general this rather seems as a significant dedicated effort to align implementations and to enforce maximum possible code reuse instead of duplication and divergence. You might want to fork a dedicated feature request as a follow up of this bug report. Looking forward to getting the complete test run results. Roman |
|
|
If we decide to make the same patch for 3d curve and surface, the following info can be useful. I have run all tests and got the following 3 regressions: CASE boolean bcut_complex N6: FAILED (bad shape) CASE boolean bopfuse_complex E5: FAILED (bad shape) CASE bugs modalg_5 bug24746: FAILED (error) |
|
2015-04-21 15:19 developer |
0002-Make-the-same-patch-for-3d-curve-and-surface.patch (2,309 bytes) |
|
|
I have uploaded the patch mentioned above as the file 0002-Make-the-same-patch-for-3d-curve-and-surface.patch. |
|
|
Dear BugMaster, Branch CR25971_2 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested on Release mode. SHA-1: 6b840be0620a63b35924454e6031be9be5e06860 Number of compiler warnings: occt component : Linux: 18 (18 on master) Windows: 0 (0 on master) products component : Linux: 4 (4 on master) Windows: 0 (0 on master) Regressions/Differences: No regressions/differences Testing cases: http://occt-tests/CR25971-2-master-occt-64/Debian60-64/bugs/moddata_3/bug25971.html http://occt-tests/CR25971-2-master-occt-64/Windows-64-VC10/bugs/moddata_3/bug25971.html bugs moddata_3(014) bug25971: OK Testing on Linux: occt component : Total MEMORY difference: 95185562 / 94542797 [+0.68%] Total CPU difference: 53319.87999999919 / 52220.829999999456 [+2.10%] products component : Total MEMORY difference: 23733009 / 23676267 [+0.24%] Total CPU difference: 17536.789999999975 / 17777.469999999976 [-1.35%] Testing on Windows: occt component : Total MEMORY difference: 57139226 / 57149644 [-0.02%] Total CPU difference: 15989.244494498982 / 16281.184765899072 [-1.79%] products component : Total MEMORY difference: 15561089 / 15564896 [-0.02%] Total CPU difference: 6400.034625599986 / 6585.207812599981 [-2.81%] There are following differences in images found by testdiff. http://occt-tests/CR25971-2-master-occt-64/Debian60-64/diff-Debian60-64.html http://occt-tests/CR25971-2-master-occt-64/Windows-64-VC10/diff-Windows-64-VC10.html IMAGE de step_2 C9: C9.png differs IMAGE de step_3 D1: D1.png differs |
|
|
Branch CR25971_2 has been updated by mkv. SHA-1: ff612506d8081ac39d7c836ae37c7db38f0f025a Detailed log of new commits: Author: mkv Date: Thu Apr 23 19:07:00 2015 +0300 Test case for issue CR25971 |
|
|
Dear msv, could you please review following test case bugs moddata_3(014) bug25971 This test case is OK on current master also. |
|
|
Test case is OK. Really, in current master the test is OK also. It might be due to some recent changes. Anyway, please integrate this test as it is. |
|
|
Dear BugMaster, Branch CR25971_2 is TESTED. |
|
|
Branch CR25971 has been deleted by inv. SHA-1: 35dd50465f24604f938c5cc074a6b4b19f9e5e6d |
|
|
Branch CR25971_1 has been deleted by inv. SHA-1: 7d1c80335fc067aac43fb2b6200f4e0b81789654 |
|
|
Branch CR25971_2 has been deleted by inv. SHA-1: ff612506d8081ac39d7c836ae37c7db38f0f025a |
|
occt: master 7b1c1b7c 2015-04-30 11:17:13 Committer: bugmaster Details Diff |
0025971: Near B-Spline knots get merged after saving/restoring (exporting/importing) Precision used to consider B-Spline knots identical is restricted to be not less than Precision::PConfusion() in Geom2d_BSplineCurve::Segment(). Affected tests updated (improvements) Test case for issue CR25971 |
Affected Issues 0025971 |
|
| mod - src/Geom2d/Geom2d_BSplineCurve.cxx | Diff File | ||
| mod - tests/bugs/moddata_2/bug253 | Diff File | ||
| add - tests/bugs/moddata_3/bug25971 | Diff File | ||
| mod - tests/de/step_2/B8 | Diff File | ||
| mod - tests/de/step_2/C9 | Diff File | ||
| mod - tests/de/step_2/D6 | Diff File | ||
| mod - tests/de/step_2/E7 | Diff File | ||
| mod - tests/de/step_3/D1 | Diff File | ||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-03-23 12:20 | Roman Lygin | New Issue | |
| 2015-03-23 12:20 | Roman Lygin | Assigned To | => msv |
| 2015-03-23 12:20 | Roman Lygin | File Added: a_328_1.zip | |
| 2015-03-24 17:08 | Roman Lygin | Relationship added | related to 0023175 |
| 2015-03-24 17:11 | Roman Lygin | Relationship added | related to 0022989 |
| 2015-03-24 19:26 | git | Note Added: 0038857 | |
| 2015-03-24 19:31 | Roman Lygin | Note Added: 0038858 | |
| 2015-03-24 19:31 | Roman Lygin | Status | new => resolved |
| 2015-03-24 19:32 | Roman Lygin | Note Added: 0038859 | |
| 2015-03-25 15:32 |
|
Note Added: 0038891 | |
| 2015-03-25 15:32 |
|
Assigned To | msv => bugmaster |
| 2015-03-25 15:32 |
|
Status | resolved => reviewed |
| 2015-03-25 15:36 |
|
Assigned To | bugmaster => apv |
| 2015-03-30 14:30 |
|
Note Added: 0038978 | |
| 2015-03-30 14:30 |
|
Assigned To | apv => msv |
| 2015-03-30 14:30 |
|
Status | reviewed => assigned |
| 2015-03-30 17:33 | git | Note Added: 0039000 | |
| 2015-04-01 10:11 |
|
Note Added: 0039070 | |
| 2015-04-01 10:11 |
|
Assigned To | msv => Roman Lygin |
| 2015-04-01 10:19 |
|
Note Added: 0039072 | |
| 2015-04-01 10:30 |
|
Note Added: 0039074 | |
| 2015-04-07 15:08 | Roman Lygin | Note Added: 0039310 | |
| 2015-04-08 18:06 | git | Note Added: 0039381 | |
| 2015-04-08 18:11 |
|
Note Added: 0039382 | |
| 2015-04-08 18:12 |
|
Note Edited: 0039382 | |
| 2015-04-08 18:13 |
|
Note Edited: 0039382 | |
| 2015-04-08 18:13 |
|
Note Edited: 0039382 | |
| 2015-04-17 10:29 | git | Note Added: 0039943 | |
| 2015-04-17 11:13 | Roman Lygin | Note Added: 0039944 | |
| 2015-04-17 11:13 | Roman Lygin | Assigned To | Roman Lygin => msv |
| 2015-04-17 11:13 | Roman Lygin | Status | assigned => feedback |
| 2015-04-17 11:19 | Roman Lygin | Note Added: 0039945 | |
| 2015-04-17 14:54 |
|
Note Added: 0039956 | |
| 2015-04-17 14:54 |
|
Assigned To | msv => Roman Lygin |
| 2015-04-17 15:05 |
|
Note Added: 0039957 | |
| 2015-04-17 15:24 | git | Note Added: 0039958 | |
| 2015-04-17 15:32 | git | Note Added: 0039962 | |
| 2015-04-17 16:15 | Roman Lygin | Note Added: 0039970 | |
| 2015-04-17 16:15 | Roman Lygin | Assigned To | Roman Lygin => msv |
| 2015-04-17 16:15 | Roman Lygin | Status | feedback => resolved |
| 2015-04-17 16:16 | Roman Lygin | File Added: Geom2d_BSplineCurve_streamlined_fix_excerpt.zip | |
| 2015-04-17 18:45 |
|
Note Added: 0039998 | |
| 2015-04-17 18:46 |
|
Note Edited: 0039998 | |
| 2015-04-17 18:47 |
|
Assigned To | msv => Roman Lygin |
| 2015-04-17 18:53 |
|
Note Added: 0039999 | |
| 2015-04-17 18:53 |
|
Status | resolved => assigned |
| 2015-04-18 16:08 | git | Note Added: 0040024 | |
| 2015-04-18 18:12 |
|
Test case number | => bugs moddata_2 bug253 |
| 2015-04-18 18:12 |
|
Note Added: 0040025 | |
| 2015-04-18 18:12 |
|
Assigned To | Roman Lygin => bugmaster |
| 2015-04-18 18:12 |
|
Priority | normal => high |
| 2015-04-18 18:12 |
|
Status | assigned => resolved |
| 2015-04-18 18:12 |
|
Target Version | => 6.9.0 |
| 2015-04-18 18:13 |
|
Note Added: 0040026 | |
| 2015-04-18 18:13 |
|
Status | resolved => reviewed |
| 2015-04-20 13:15 | Roman Lygin | Note Added: 0040044 | |
| 2015-04-20 21:31 |
|
Assigned To | bugmaster => mkv |
| 2015-04-21 15:18 |
|
Note Added: 0040074 | |
| 2015-04-21 15:19 |
|
File Added: 0002-Make-the-same-patch-for-3d-curve-and-surface.patch | |
| 2015-04-21 15:20 |
|
Note Added: 0040075 | |
| 2015-04-23 19:07 |
|
Note Added: 0040180 | |
| 2015-04-23 19:07 | git | Note Added: 0040181 | |
| 2015-04-23 19:08 |
|
Note Added: 0040182 | |
| 2015-04-23 19:08 |
|
Assigned To | mkv => msv |
| 2015-04-23 19:08 |
|
Status | reviewed => feedback |
| 2015-04-23 19:09 |
|
Test case number | bugs moddata_2 bug253 => bugs moddata_2(013) bug253, bugs moddata_3(014) bug25971 |
| 2015-04-24 11:58 |
|
Note Added: 0040199 | |
| 2015-04-24 11:58 |
|
Assigned To | msv => bugmaster |
| 2015-04-24 11:58 |
|
Status | feedback => reviewed |
| 2015-04-24 15:50 |
|
Assigned To | bugmaster => mkv |
| 2015-04-28 20:52 |
|
Note Added: 0040390 | |
| 2015-04-28 20:52 |
|
Assigned To | mkv => bugmaster |
| 2015-04-28 20:52 |
|
Status | reviewed => tested |
| 2015-05-07 11:18 | bugmaster | Changeset attached | => occt master 7b1c1b7c |
| 2015-05-07 11:18 | bugmaster | Status | tested => verified |
| 2015-05-07 11:18 | bugmaster | Resolution | open => fixed |
| 2015-05-14 15:28 |
|
Status | verified => closed |
| 2015-05-14 15:30 |
|
Fixed in Version | => 6.9.0 |
| 2015-05-14 16:32 | git | Note Added: 0041037 | |
| 2015-05-14 16:32 | git | Note Added: 0041038 | |
| 2015-05-14 16:32 | git | Note Added: 0041039 |
