NURBS Sweep cannot interpolate the path when multiple sections are used

[rendetto]

My tests on the Sweep node were successful(with very good precision) until I tried to use more than 4 sections on the path.
The surface started to deviate from the path and raising the "V Sections" number didn't help.

I did a simple setup where all sections are flat in XY plane, with pivot at World origin:

This is the file I'm testing with:
NURBS-Sweep_Path_Interpolation_Issue.zip

[nortikin]

[rendetto]

I was just checking the Birail node with 6 section curves and the surface goes exactly through the rails.

I don't know if this info is helpful for solving the Sweep problem but I thought it's worth mentioning.

[rendetto]

Well.. it appears that what I stated above is not exactly true. Birail have also weird behavior. I'm planning several tests in order to be sure what happens and when it happens. So stay tuned...

[rendetto]

I found a way to get better path interpolation. Raising the path curve degree + raising the "V Sections" helped for this particular case. Unfortunately those changes created different path shape.

I got similar behavior with Birail node, where the results got better when raising the output "Degree V" and "V Sections".
Raising the degree at this final stage seem helps maintaining the Rails shape ..or I'm talking nonsense :)

The Sweep node does not control the output surface degree independently from the Path degree. Does it make any sense requesting such feature for it?

Thanks

[rendetto]

I did a bunch of tests and the conclusion is that when using "None" for rotations of the Sections we need Path curve to be at least of degree 4. This is the solution that interpolates the Path very closely and the raising of "V-Sections" number did help.

If for some reason we need the Path curve to be strictly cubic, using the other rotation algorithms seem to give better results at interpolation.

For now I consider this issue as a minor problem, since it's a special case (for Path degree 3 only) and we can find solutions tweaking the parameters or input curves.

I started thinking that we could create Discussions on features like Sweep(Monorail) and Birail that need extensive testing and have lots of cases.

I'm not sure if I have to close the issue so @portnov please feel free to do so if you find it unnecessary to stay open at this stage.

Thank you for your great work!

[portnov]

With "Nurbs sweep", it seems there is precision loss if you set "VSections" more than count of profile curves (and number of profile curves is more than 2). Will think what I can do about that.

[rendetto]

Hi @portnov, load of time passed but I managed to do a check on some of my old Sweep setups.
With cfb1cbc there was an obvious precision boost - I'd say results are perfect, but in parallel with this I noticed other setups suffer with an offset in the result surface - no clue why some are OK and some have the offset.

I've noticed that you already addressed this problem with:
https://github.com/nortikin/sverchok/blob/master/utils/surface/nurbs.py#L1331-L1332

What's behind commenting out those two lines? I observe that those move resulting surface back on the source curves, but did this messed up something else that I didn't catch still?

Thanks

[portnov]

I don't remember exactly right now :)
If you think the problem is in these two lines - try to uncomment them and see if that helps :)

[rendetto]

I did and the problem seem solved ..at first glance. I need to do some more checks just to be sure if it doesn't affect something else in a negative way.

[rendetto]

Short update...

I'm extensively testing these days and have no definite conclusions yet. The thing is that the "offset" bug I mentioned is not really a bug, but a consequence of the design. I didn't construct my profiles in XOY - hence the offset. It needs more study for sure. I tried to understand the code behind and so far it looks fairly straightforward to me.

About un-commenting the two lines - they can be considered a feature of their own, but there are some caveats, so enabling those it's not a simple solution. Anyways I definitely can tell that those lines can be used to boost precision but only for special cases. They also can "solve" the offset problem when we don't have the profiles in XOY, but again this is limited for special cases and will "brake" other designs.
Those two lines of code will always snap the profiles(and sections) to the path and that's a special case, because sometimes we could want profiles to be offset from the path. This is a matter of approach to modelling - do we want to construct sweeps with floating profiles around the path or we deliberately force the user to construct profiles that always touch the path.
Both paradigms have their positives and negatives and I need more testing before making a statement.

To be continued...

[rendetto]

After lots of tests I can finally say that the old way of calculating the back vectors can be used again.
This is my proposal for solving most of the problems I encountered: #4858

It's important to mention that after aaeb63c using base_vs for calculating the back_vectors doesn't cause the observed precision loss(mentioned at the beginning of this issue report).

Those are some of the results I got already:

Current Master - using V sections more than input profiles causes resulting surface to fail following the path and the sections):

Proposed PR - exact(almost) interpolation of the path and sections. More V sections will result in tighter interpolation:

Same goes for similar setup but using NoRotation for the sections:

Current Master:

Proposed PR:

This PR doesn't affect negatively setups with floating profiles because does not make forced snap onto the path, so it's seems the best solution for now.