Why does Patch has a 255 limit for Surface U & V Spans?
Any way to have it go much higher?
Thanks.
What problem are you having you think this would solve?
Thanks for the prompt response.
I’m doing a topology mesh.
I know that according to another thread nurbs are not the best for this.
However, patch at 255 is giving a very good result, except that I wish I could go higher on that number to adjust better to the points.
I ended up doing patches in sections over the point cloud (not really a point cloud but the vertices of the polylines).
That way I was having 255x255 in smaller areas. But I can’t join them together afterwords.
The advice you received about NURBS surfaces being not the best for this use is excellent advice.
The smoothness of a NURBS surface would not only be inefficient, but also implies accuracy that does not exist.
Land topology is best represented by a mesh object.
I am aware of that.
I’d still want to use nurbs.
Any way to use patch with more than 255 U V spans?
Thanks,.
Sorry, no. That’s how the command was designed and written.
There’s no way to change that without rewriting the command.
Why 255 though? What’s so special about that figure? Is that the point when Rhino crashes or something? H
2 ^ 8 was convenient I suppose.
-Pascal
Seems arbitrary…
Sure. The limit used to be 50, as that could possibly crush a 32-bit 1999-era computer.
It’s not a tool you should be using AT ALL outside of very specific tasks, it should be one of those hidden test commands you need to search to know exists, and asking for more spans is not going to make it more suitable, you’re just going to dig yourself a deeper hole.
2 Likes
Curious why the Patch tool would be different from any other command type in terms of usage/availability (I’ve heard similar things said of NetworkSrf). It’s quick and powerful for generating smooth surfaces. Have found I use it on the regular in designs to terminate open cylinders with a tangentially contiguous cap like shown in the first part of this video -
… coincidentally also some cool topographic techniques there later on
Yeah, yeah, patch bad, baaaaaahd patch… We hear you…
But why 255? Your guess is as good as mine.
My guess is 255 is an arbitrary number, selected when a number was needed for coding to proceed. It was probably thought at the time to be significantly larger than would be needed for any reasonable use of Patch.
Maybe a good time for a review if that’s the case. No longer in 1999. And do they still sell 32bit computers? H
Have you tried MeshPatch?
The 255 combined span limit in Patch does not apply to a user supplied “Starting surface”.
However
Patch executed using a starting surface of degree 1 in both directions with 250 x 250 spans. However the 64GB memory on my system was 100% used and Rhino effectively locked up. It too several attempts to end Rhino using Task Manager.
Because it produces overly-complex, uneditable surfaces. There are 2 situations where it’s required. 1–filling in corners where multiple fillets come together such that no mathematically precise solution exists. 2–poorly fitting a surface to topographical lines or random points, for workflows that have more to do with decades-ago limitations of downstream software than any idea that it’s actually a good thing to do.
I routinely use Patch to fit surfaces to large numbers of points from scans of boat hulls, and obtain high quality results. I have previously posted about my workflow; for example Hull surface from point cloud measurements - #3 by davidcockey
I also use a similar workflow to fit surfaces to sets of boat “lines”.
@JimCarruthers What alternative workflow do you suggest?
Bad patch, go sit in corner, baaaaaahd patch…
I’m just curious about the rationale behind the 255 - I never understood why. Thanks for your thoughts everyone.
We’d like the Patch command to finish in a reaonable amount of time and not run your system out of memory. These values seem to have work good enough.
– Dale