View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0022580CommunityOCCT:Modeling Algorithmspublic2011-06-06 21:152013-03-01 21:43
ReporterszyAssigned Tojgv 
PrioritynormalSeveritymajor 
Status assignedResolutionopen 
OSAll 
Product Version6.5.0 
Target VersionUnscheduled 
Summary0022580: Improvement of BRepTools_Modifer
DescriptionRLN contribution.
fix355
- Summary: Improvement of BRepTools_Modifer
- Detailed description:
         Removal of static in BRepTools_Modifier
         Modifier lost pcurve ranges on non-SameRange edges

fix475
- Summary: Port on gcc4.4
- Detailed description: BRepTools_Modifier.cxx
- Dependency: fix355
TagsNo tags attached.
Test case number

Activities

abv

2011-06-27 11:30

manager   ~0017626

Last edited: 2011-11-22 11:55

 Note that fix rln_355 causes regression: see mail of RLN, 26.06.2011:

----

I have been working on fixing regression introduced by my modification in
BRepTools_Modifier (http://www.opencascade.org/org/forum/thread_20945/) and
realized there is a principal limitation in _Modifier/_Modification. (For SZY:
The fix to blame is fix355, so you might want to hold its integration. Make
sure you do not introduce it when working on fix475 which is made on top of it.)

Here are details.
In plain 6.5.0 (6.5.1) BRepTools_Modifier::Rebuild() de-facto assumes that an
edge is (and remains) same-range and therefore freely propagates ranges from 3D
curve onto pcurve(s). This breaks non-same range edges. Fix355 was targeted to
fix this issue by re-applying the original range to the new edge. However this
introduced a regression (described on above forum thread) - when new pcurve
range does not match original one. This happens, for example, during scaling on
some particular combinations (e.g. 3D and 2D lines on some surfaces, e.g.
planes or cylinders).

The question is how to fix both problems (non-same range and changing pcurve
range) ? The best reliable approach I see is to extend
BRepTools_Modification::NewCurve2d() API to return a new range. It could also
be applied to ::NewCurve() for 3D curve, which is currently solved by
NewParameter() method. This would be quite a significant API change requiring
updates throughout OCC code (and perhaps of some advanced users). However in
most cases the modifications would be straightforward - just return a previous
range. Moreover, to mitigate oversight, _Modifier could default returned
parameters to old range before calling NewCurve2d().
Trying to design a work-around, I thought to change
_TransformModification::NewCurve2d() and save new pcurve ranges in new edge
NewE (which is currently fully ignored), for a case of changing range. Then
BRepTools_Modifier would first check if there is a new range in NewE and use
it, if not - default code would work. Though feasible, this approach does not
look really effective, rather a hack.

That's why I am asking your opinion if you would be fine if your team or I
myself could extend BRepTools_Modification API. I can do this, but will need
your commitment to promptly integrate it as merging modifications with every
new OCC release will be a nightmare :-(.


---

szy

2011-10-21 18:13

manager   ~0018390

Branch ==> OCC22580_BreptoolsNonsamerangePort.

Issue History

Date Modified Username Field Change
2011-08-02 11:31 bugmaster Category OCCT:MOA => OCCT:Modeling Algorithms
2011-10-21 18:13 szy Note Added: 0018390
2011-10-21 18:13 szy Assigned To bugmaster => jgv
2011-10-21 18:13 szy Severity feature => major
2011-10-21 18:13 szy Status acknowledged => assigned
2011-10-21 18:13 szy Resolution suspended => open
2011-10-21 18:13 szy Product Version => 6.5.0
2011-10-21 18:13 szy Fixed in Version EMPTY =>
2011-10-21 18:13 szy Target Version => 6.5.3
2011-10-21 18:13 szy Description Updated
2011-11-22 11:55 szy Note Edited: 0017626
2011-11-25 14:28 szy Description Updated
2012-02-09 09:14 abv Target Version 6.5.3 => 6.5.4
2012-10-23 19:23 abv Target Version 6.5.4 => 6.6.0
2013-03-01 21:43 abv Target Version 6.6.0 => Unscheduled