MantisBT - Community
View Issue Details
0022580Community[OCCT] OCCT:Modeling Algorithmspublic2011-06-06 21:152013-03-01 21:43
szy 
jgv 
normalmajor 
assignedopen 
All
[OCCT] 6.5.0 
[OCCT] Unscheduled 
0022580: Improvement of BRepTools_Modifer
RLN 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
No tags attached.
Issue History
2011-08-02 11:31bugmasterCategoryOCCT:MOA => OCCT:Modeling Algorithms
2011-10-21 18:13szyNote Added: 0018390
2011-10-21 18:13szyAssigned Tobugmaster => jgv
2011-10-21 18:13szySeverityfeature => major
2011-10-21 18:13szyStatusacknowledged => assigned
2011-10-21 18:13szyResolutionsuspended => open
2011-10-21 18:13szyProduct Version => 6.5.0
2011-10-21 18:13szyFixed in VersionEMPTY =>
2011-10-21 18:13szyTarget Version => 6.5.3
2011-10-21 18:13szyDescription Updatedbug_revision_view_page.php?rev_id=717#r717
2011-11-22 11:55szyNote Edited: 0017626bug_revision_view_page.php?bugnote_id=17626#r871
2011-11-25 14:28szyDescription Updatedbug_revision_view_page.php?rev_id=1093#r1093
2012-02-09 09:14abvTarget Version6.5.3 => 6.5.4
2012-10-23 19:23abvTarget Version6.5.4 => 6.6.0
2013-03-01 21:43abvTarget Version6.6.0 => Unscheduled

Notes
(0017626)
abv   
2011-06-27 11:30   
(edited on: 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 :-(.


---

(0018390)
szy   
2011-10-21 18:13   
Branch ==> OCC22580_BreptoolsNonsamerangePort.