BRepOffsetAPI_MakePipeShell result in inaccurate shape when using -DT mode and DT_ShapeDivide on the spine

I have a similar result (pipe looking like a cross) with the Attachment 4 (ZIP) where the spine is a polyline and with a single profile.

And I also reproduce in C++ using C0BSplineToSequenceOfC1BSplineCurve instead of ShapeUpgrade_ShapeDivideContinuity to convert the spine from C0 to C1 with the data from original Attachment 5 (ZIP).

Dear Participant, there is a problem with your entry data.
As you can see on attached file (Attachment 10 (PNG)), profile_4.brep lies "deaper" on spine than needed to recive correct result.
You also can recive more correct result if you exclude this profile from sweep algorithm, but not good enough (see attached file Attachment 7 (PNG), script: Attachment 12 (TCL))
If you want to recieve result, passing through all presented profiles, it is needed to use 'buildsweep' command without '-C' or '-R' parameters, but resulting shape will have curvature on top border (see attached file Attachment 8 (PNG), script: Attachment 12 (TCL))

Dear Commenter 1, thank you for your feedback.

I see what you mean about profile number 4, there is indeed a problem with the data.

However, in Attachment 4 (ZIP) there is only one profile and we have a similar "cross" result. Using 'buildsweep' command without '-C' or '-R' parameters does not help. Is there also a problem with the data?

Branch [archived branch] has been created by Participant.

[revision removed]


Detailed log of new commits:

Author: Commenter 1
Date: Tue Oct 19 17:50:53 2021 +0300

    0032447: Modeling Algorithms - BRepOffsetAPI_MakePipeShell result in inaccurate shape when using -DT mode and DT_ShapeDivide on the spine
    
    Changed tolerance for test

Dear Participant, unfortunately, on the "sample_polyline" configuration of the input data, the algorithm can’t handle corner trimming due to the location of the inner edges of the guide spine.
The algorithm sequentially processes the faces, built on the edges and tries to find the line along which it will be necessary to trim the intersecting faces.
See below the picture explaining this process (Attachment 9 (PNG)).
As we can see on the above picture, this line can’t be built.
                               
At the same time, to get a valid result a work around may be used.
The attached tcl script implements some small workaround allowing to get a valid result.

We can offer you two possible approaches:
Solution 1: Continue investigation and solution elaboration.
            This problem requires additional more deep
            investigation/debugging of internal algorithm for a fixing
            solution elaboration.
            The exact estimation of the requested additional budget will be
            sent you by mail.

Solution 2: Use the workaround.
            This approach is presented by the ‘tcl’ script (Attachment 14 (TCL)).
            The script eliminates the problem of the location of the edges
            of the guide spine.
            You can play this script and check does it work for you.

Dear Commenter 1, thank you for your feedback.

Solution 2 does indeed produce correct results.

However, at the moment I fix the shape with fixshape before testing it for validity, in order to solve other construction problems. And after fixshape, the invalid "cross" shape, result of the sample, becomes valid, and I cannot detect the problem anymore. I'll see if I can get rid of fixshape and use the workaround for the other construction problems that were fixed by fixshape.

I'll discuss with my colleagues the solutions you suggested.

Branch [archived branch] has been updated forcibly by Participant.

[revision removed]

I've added 6 samples of spines and profiles for which the resulting pipes display a cross shape (Attachment 3 (ZIP)). I hope this will help debugging and developing a solution.

Dear Participant,
Thank you for your feedback and attached samples.
I have researched new samples, but unfortunately, almost all samples (exclude the sample_cross_4) have an indepensable geometry for the current set of input parameters of the algorithm bacause the trimming is not possible for them due to the inability to draw a red line,since the algorithm requires that the green lines intersect (see on attached picture).

Current samples can be resolved by changing your scripts to:

mksweep s
setsweep -DT
addsweep p
buildsweep r -S

In this part of the script, we change transition mode (delete "-C" flag) to avoid the necessity for corner trimming.

Dear Commenter 1,

Thank you for your feedback, I see what you mean, I'll double-check the data.

However, IMO without the "-C" the shape is inaccurate, the extremities are wrong and the width should be uniform (sample_cross_6):

Dear Participant, My colleagues and I had discussions about your problem, and we have a question to you about possible solution (you can see it on the attached doc-file).

Dear Commenter 1, thank you for your feedback.

Regarding your question:
> does it matter to you the number of sub-shapes in the resulting shape?
No, it does not matter, you can merge the edges that smoothly connect to each other, as long as the resulting shape corresponds to the input spine and profile(s).

Regarding your recommendations on the input data, I'see what can be done.

I have a question about this recommendation:
> Lack of the smooth connections between neighboring edges of the spine
What do you mean exactly by `smooth`? The spine I provide is a wire, with connected edges.

Dear Participant, you are right, that the spine is a wire with connected edges.
But under this paragraph, I meant to aviod wires, consisting of the edges, which connected with neighboring edges at angles, near 180 degrees (see on attached picture).
And, if it possible, it is better to combine these edges into one.

Dear Participant, for solve your problem, we offer to you the following solution:
We will add new flag for "mksweep" command, which will allow you to change input spine in accordance with the recommendations for a smooth connections automatically.
We need to know your decision about this solution.

Dear Commenter 1,

I am ok with adding a new flag to the "mksweep" command (and its C++ equivalent). As long as I can use this flag all the time, or I can programmatically determine when to use this flag.

Branch [archived branch] has been updated forcibly by Participant.

[revision removed]

Branch [archived branch] has been updated forcibly by Participant.

[revision removed]

Branch [archived branch] has been updated forcibly by Participant.

[revision removed]

Branch for review:
OCCT - CR32447

Results of testing:
http://jenkins-test-occt.nnov.opencascade.com/view/CR32447-master-Commenter 1/view/COMPARE/

Please add some cases testing history. See, for instance, the cases "bugs modalg_7 bug28949_*".

Branch [archived branch] has been updated forcibly by Participant.

[revision removed]

Branch [archived branch] has been created by Participant.

[revision removed]


Detailed log of new commits:

Author: Commenter 1
Date: Wed May 11 18:17:31 2022 +0300

    0032447: BRepOffsetAPI_MakePipeShell result in inaccurate shape when using -DT mode and DT_ShapeDivide on the spine
    
    Added new option '-C' with possibility to set value of Angular and linear tolerances to 'mksweep' command to correct input spine by merging smooth connected neighboring edges

Branch [archived branch] has been updated forcibly by Participant.

[revision removed]

Branch [archived branch] has been updated forcibly by Participant.

[revision removed]

Remarks:

1. Make default values of AngTol and LinTol in the command mksweep, must be

mksweep : mksweep wire [-C [AngTol LinTol]]

Also add to the comment notice that AngTol is in degrees.

2. There is no any check in your tests except checkshape: there must be also check of number of subshapes in the result, check of lengths of the results of the command "modified", check of areas of the results of the command "generated", picture of the result.

Branch [archived branch] has been updated forcibly by Participant.

[revision removed]

Reviewed.

Branches for integration:
OCCT – CR32447
Products – NOT

Combination -
OCCT branch : [archived branch]
master SHA - [revision removed]
[revision removed]
Products branch : [archived branch] SHA - [revision removed]
was compiled on Linux, MacOS and Windows platforms and tested in optimize mode.

Number of compiler warnings:
No new/fixed warnings

Regressions/Differences/Improvements:
No regressions/differences

CPU differences:
Debian80-64:
OCCT
Total CPU difference: 18742.72000000061 / 18677.050000000647 [+0.35%]
Products
Total CPU difference: 11723.460000000106 / 11729.870000000092 [-0.05%]
Windows-64-VC14:
OCCT
Total CPU difference: 20706.5625 / 20665.84375 [+0.20%]
Products
Total CPU difference: 13249.46875 / 13282.171875 [-0.25%]


Image differences :
No differences that require special attention

Memory differences :
No differences that require special attention

Branch [archived branch] has been deleted by Participant.

[revision removed]

Branch [archived branch] has been deleted by Participant.

[revision removed]

Dear Participant,
We added new flag '-C' to 'mksweep' command, which corrects the input spine by merging smooth connected neighboring edges.
You can also use ShapeUpgrade_UnifySameDomain class to programmatically correct input spine.