When we use FlowAlongSrf, then we want the result on one determined side of the target surface.
In the attached, let’s say on the outside.
Works in most cases, but sometimes not.
Then the result is on the inside.
And I don’t know why.
When this happens, I check for the UV directions of both surfaces.
Ok, that’s easy to understand, no problem.
When the result is on the unwanted side, then I invert the direction of the base surface.
Which results in no effect, results is always the same.
Also when the target dir is flipped.
So what is the rule, how does Rhino decide which side to place the result on?
It should look at the UV directions and the normal of the surface. You need to click on the corresponding corner of each of the two surfaces; the U and V arrows point in the direction of increasing domain of the surface.
I’m just not always sure that where you actually click on the surface in “screen space” is what gets understood by Rhino as the proper UV location in “surface space”, sometimes it seems that Rhino thinks you clicked somewhere else…
Hi Charles - it has some smarts, which, for me, works almost all the time, in that I get the result I want, but as you say, it’s not immediately clear what the rules are if you expect UV and N to always win, which, personally, I’d prefer as well…
Unfortunately, if we have to guess what those “smarts” are and in what situations they will get applied, results are always going to be unpredictable. I prefer a strict set of rules…
Pascal, when you can’t really explain, then it’s time to throw away the smarts.
In trainings, FlowAlongSrf fails ~50%.
It would be good to be able to explain what went wrong, and how to make it working from the beginning.
Perhaps this is a good reason to enrich the help (which says nothing about UV and N).
Mikko did make it work pretty well, but I tend to agree that just using UVN would be better for me and ‘experts’, I’m less sure that it is the right thing for the general user - I understand the arguments for, I’m not sure how the balance of extra complication in understanding for users works out. However, if it really fails to give the expected result half the time…
I normally place a curve in one corner of the ‘from’ surface and use Unrollsrf (mostly) to create the ‘to’ surface, selecting the curve to be unrolled with it for reference.
Idea
Instead of being smart, the command could pretend to be smart and let the user decide.
The command line could offer options to swap UV and direction in a preview state.
This preview could also let switch rigid etc.
This already existing smart behavior could stay as it is.
Just add the overrides in the command line.
We already have such previews for several commands (Array, FilletEdge etc. etc.).
