Sweep SOP behavior unpredictable? Bug? (Windows 11600)

Bugs
1

“The cross-section primitives are placed at each point of the backbone perpendicular to it.”
“In most cases, it is best to build the cross section primitives in the XY plane; Sweep will automatically orient them properly along the backbone”

sweepfix.tox (13.4 KB)

This description does not match my experience. Please see attached. I have spent enough time trying to figure this out that I have concluded it is likely a bug, or that the operator requires the inputs to be formatted somehow that went over my head.

In this example I have multiple 2d outline primitives, all on the XY plane, acting as backbones. Using the same line section as cross section in each example. Each primitive sweeps at a different angle, only sporadically perpendicular to XY as the docs claim it should be.

I have a hacky method of getting past it, by measuring the angle with an object chop, and using a second sweep set to roll at that angle. But it is an imperfect correction, and does not explain why it happens to begin with.

Please confirm that this is a bug, if it is not, please guide me on how to reliably get a parallel sweep with any incoming 2d xy outline as a backbone.

Thank you!

2

Sorry for the confusion here, the documentation isn’t very clear on the math that is going on behind the scenes.

The short answer is that if you create the cross section in the XY plane as the documentation suggests, then you should probably create the backbone in the horizontal XZ plane. This configuration will mean that the “up” vector for each cross section matches the positive Y axis and will be consistent between each of your cases.

The reasoning here is that the “up” vector is calculated as the cross product of the line direction of the backbone and the positive z axis. So, any vertical change in your backbone will cause the cross section to rotate around the backbone line.

So, in your cases the backbone outlines are all vertically aligned causing the cross sections to be rotated differently in each of your cases.

I hope that answers your questions. I could see an adding an option to control how that up vector is calculated similar to what we do with the LookAt system on the Geometry COMPs.

3

First of all thank you very much for taking a look. However I am still baffled and I do not get it. It all feels wildly inconsistent still to my brain. I think your up vector idea is very intriguing

If you think you could fix it by adding a controllable up vector, please do! Consider it an emphatic RFE. That sounds like what it needs to make it consistent. I would really love for this sweep idea to work to the full capacity of its accuracy to create angle fixed equal distance curves.

Here is another example that takes the backbone in the z up, y up ,and x up, and utilizes 4 cross sections :12 sweeps at once. In all cases the “best” one changes erratically (system looks for whodunnit based upon flattest profile across all possible sweeps). (i omitted the other 2 vectors for the cross section, because they create a parallel plane/parallels sweep, but never parallell plane/perpendicular sweep required for SDF

whodunnitCapture
whodunnitCapture812×352 30.4 KB

Anyways please have a gander at this example and confirm to me that there is no way to make this process consistent as sweep stands, and I will use it as is for a while.

There are 2 problems, one is that the ideal sweep changes from shape to shape(whodunnit?), and the second problem is that often time the sweeps are slightly off, like a rounding error of.0000007 instead of a true 0. This adds inconsistencies when using a ray sop in the next step of the process to remove outliers from the SDF. I wouldn’t mind using 12 sweeps and picking the best if one of them was always a perfect 0

Although you’ll find a handful that do find a true zero showing that it is possible, (likely with your up vector fixidea!)

Another bug to note is your new fix for op viewer for sop for this build is not quite right. this example shows only 1 of 2 sop op viewers can keep up with automated changes. This can be observed at /swept_away/Prim_SDF/subprim0

sweep forum example (2).5.toe (21.4 KB)

For bug hunters: please go to /swept_away/Prim_SDF/subprim0/sweeptesting/sweepme and observe how you cannot get consistent 2d results from the sweep sop There is a slider you can change out for the automated prim changing once you see the flaw in sweep.

For anyone reading along, this is a virtually functional SOP-only 2d equal distance curve, standard distance function etc. This is for CNC pathing but could be used for similar ideas etc.

4

I’ve been looking through your file, and just so that I’m clear on the issue, the problem is that the final results are not perfectly flat in the z direction?

I’m generally not surprised there are slight differences in each version just because of the limits of floating point math. Even though the orientations should work out to be equivalent, the fact that the backbone geometry is unique for each example means slight differences in calculating the rotation matrices for each cross section.

I can take a look at the math to see if there is any room for improvement, but floating point numbers are always imprecise and you need to work with tolerances rather than exact values.

Is it possible to just zero out the z coordinates for your mesh?

5

Thanks for having a look through the file!

You are right it is likely to do with being perfectly flat. I have tried flattening it manually, and it does make a great deal of improvement, but not quite the same as perfect sweep.

This example is less chaotic and perhaps clearer, it is just a lower case r. This r will give a perfect sweep, but you can also get the imperfect sweep by rotating the backbone. Many shapes do not reveal a perfect sweep so easily, many do . so this is a good example to study. I was hoping since this is possible here , then maybe it could be made possible in all cases…?

The example compares using the perfect sweep and the manually flattened imperfect sweep sent to a ray sop. Although both shapes seem the same, the imperfect sweep gives some inconsistencies in the ray. The perfect sweep is accurate and awesome in the ray.

In the example I just used a handful of text dats to comment.

/swept_away/Prim_SDF/subprim0/sweeptesting/sweepme

sweepsandrays.2.toe (20.1 KB)

Thanks again for having a look!