SPORPH is driving me nuts

[osuire]

OK, I’ve got some surfaces to deform, and Sporph looks like the perfect component for this since I was able to generate a “Starting” surface and a “Target” surface which should work.

To put all the chances on my side, I made a cluster for orienting all these surfaces in the same way (u, v, n) so that there should be no doubt as to the orientation of the resulting “Sporphed” geometry.

Alas, it seems that having the same u, v, n orientation for my Starting and Target surfaces is not enough to have the “0,0” uv point the same.

NURBS mindfu**ing at it’s best.

Bloody Sporph driving me nuts.gh (3.0 MB)

OH, and the “Reorient surf based on guide surf” cluster i made there is really what the “Flip” component should do, with the option of selecting u, v, n compliance (true/false), IMO.

[osuire]

I realize that it works if I “reparameterize” the “Starting” and “Target” surfaces.
I wish that type of dorky NURBS book-keeping was done automatically.

[Michael_Pryor]

I wish that type of dorky NURBS book-keeping was done automatically.

True, but then you would have ones complaining that they can’t not reparameterize it
Guess that it why it is an option (maybe you could set them on and cluster it).

[osuire]

Could you give me an example where reparameterizing would be a problem ?

[andheum (Andrew Heumann)]

I tend to agree with you that reparameterize should be on by default, but I understand why sometimes one might not want to.

In certain cases, surface or curve parameter domains are actually meaningful, and you can take advantage of them. For instance, a simple rectangular (1-degree x 1-degree) planar surface has U and V dimension according to its lengths; so if I want to find the point at 4,7 relative to the surface’s coordinate system, I can use the UV coordinate of (4,7). A Sphere’s UV parameterization follows its spherical coordinates, where U and V are the polar and azimuthal angles in radians.

[osuire]

Hi Andrew,

Hmmm… That all sounds like textbook examples.
UV coordinates are inherent to NURBS maths, just as bytes are inherent to the way computers work.
Yet, as a user, I certainly don’t want to get my hands dirty with them ; I want to use high-level tools that keep those nasty critters under the hood, and get some work done.

Consider the way Rhino uses the Nurbs parameters to create meshes. Does that make any sense in regards to the goal of producing an approximation of a surface ? No.
It’s just easier for the guy who coded it, but has no benefit to the user ; quite the contrary actually : Rhino meshes are hideous and often flat out useless.

[andheum (Andrew Heumann)]

you asked for examples, i gave you examples

[osuire]

Yep, thanks for proving my point

[seghierkhaled]

Did you tried this script to fix uv directions? works fine

Sorting/unitizying multiple surfaces direction UVS

A while back I was working on this problem a bit, then I put it away. I think the cylinder idea is a good one, so this is an example that creates a bounding cylinder on vertical surfaces. It does join all connected surfaces. Joining surfaces into breps does unify the normal direction of each surface, however, it does not unify the UV direction. The UV’s can still be miss-matched, which can be frustrating. This should work for the pictured example. [UnifyDirections] So, this isn’t a totally uni…

Sporph 2.gh (3.0 MB)