Just a reminder that if the “McNeel” team ever wants to fix the bug that occurs due to the combined UV direction for the “Match target isocurve direction”, they must allow selecting either “Match target isocurve direction U”, "“Match target isocurve direction V” or both. This means that upon placing the tick to one of the above modes, their circle must convert into a square, giving the user a clear indication that they could be combined together if necessary. (meaning the user will be able to put two ticks on both).
This is a no brainer. Just a basic cascade list with text buttons (already used by many options in the same panel). I wonder how long it will take for the Rhino developers to bring that functionality in Rhino 9?
I’m curious what happened with these buttons for a quick one-click change of saved custom zebra styles? What’s the current look of the panel? (Rhino 7 user here)
This one was requested numerous times for years (since Rhino 6 was the latest version), and my super huge hope is that it will be finally added to Rhino 9, because it’s annoying to write ti manually countless of times daily.
“Split” and “Trim” Command line options:
Add a “Flip” button (like the one used in “Loft”) for the “Blend surface” tool. Currently, the lack of that particular option forces the user to cancel the command and redo the picking of all input surface edges all over again. Manually flipping the handle ends returns the following error message in the Command line:
"Shape ends are out of order
BlendSrf failed to make a surface."
Having that option should improve the workflow, because it will let the users window-select the input surface edges and then flip the direction if necessary. Window selection for “Blend surface” is very useful for tiny edges (including when using the “Chain edges” mode) as the user will not be forced to zoom-in the camera too close to be able to pick an edge that appears too small on the screen.
It’s a different thing. The “Tutorial mode” is meant to show only the command of the key/mouse button combination, in order to help students with the learning of Rhino. Including video tutorials.
It would help if there are 6 commands to select various types of surfaces based on their control point and knot structure:
Select all Bezier/single-span surfaces;
Select Bezier/single-span surfaces only with degree 5 and 6 control points (both are super useful to identify the clean surfaces);
Select all surfaces with knots (super useful to identify knotted surfaces that may cause issues with the surface quality, especially after control point editing);
Select surfaces with more than X amount of control points (the user should type the minimum number of control points in the command line);
Select surfaces with the same X degree in both directions (the user should type the degree in the command line). This command will select only surfaces that share the same degree in both directions;
Select surfaces with X degree in any direction (the user should type the degree in the command line). This is similar to the above option, except that Rhino will also select the surfaces with a different degree in either direction, as long as at least one of the directions falls under the criteria. For example, if the user types degree 2, the command will select cylinders and other geometry with degree 2 in one direction and a different degree in the opposite direction (degree 1, degree 3 etc).
I will repeat my request to add an extra option for the “Match surface” tool called “Minimum distance” or “Limit multi-spans”, in order to limit the amount of spans that are generated with the “Refine” option. This also should be implemented in any other surface creation and editing tool that uses a similar option to refine the surface. “Blend surface”, “Sweep 2 rails”, “Sweep 1 rail”, “Loft”, “Patch” etc. All of these will benefit from that new setting to create a lightweight surface at the cost of a slight deviation.
It’s very annoying to have like 20-100 unwanted spans all placed in a tight space within a millimeter, just because there is some extremely minor deviation relative to the target edge(s). Being able to limit the minimum distance between the new spans will make the geometry much more easier to edit subsequently, while the deviation of the matched surface will be still good enough to join the surfaces.
This also makes the life easier, because sometimes my Rhino 7 really struggles to calculate the matched surface due to the gazillion multi-spans that are generated. I had numerous cases where Rhino simply froze forever or crashed due to the inability to calculate the multi-spans. Ideally, a default setting of 1 unit (1 millimeter of whatever the user prefers) should prevent many of the issues that occur.
For example, this matched surface has 242 spans, most of which are totally unnecessary.
Before matching, there was a minor deviation that I don’t think needed so many extra spans to achieve the desired 0,001 mm tolerance, since the gap was already less than that. Of course, not using “Refine” will not add extra spans, but in many cases the deviation is just barely above the file tolerance and adding a huge amount of spans is an overkill in my opinion.
Some tools will benefit from having an active edge continuity analysis, such like “Blend surface” and basically all main surfacing tools. That will let the users check the distance or continuity of the new surface during the life preview and adjust the settings if necessary.
Not only this will improve the workflow, but also save lots of time, especially where the new surfaces is built to match an existing geometry as close as possible. Check my video below to see a similar usage case where the target surface it not split initially. I was forced to build a test blend surface, then use it to make a fin surface, then use the latter to split the target surface, then delete the initial blend surface, then build a new blend surface using the split edge as a reference. Then I would be forced to untrim the target surface to its previous state. I spent much more time until the blend surface got close enough to the target surface, because I could not use an Active edge continuity tool.
A dynamic edge analysis tool that is able to detect the distance from the preview surface and somewhere in the middle of a target surface (not necessarily a target edge) would help achieve an even better result.
I never use refine option. Sometimes I try it but that always turns out to be a waste of time.
What I do is add (insert) the knots myself where I think they will be most useful and that always produces better results than letting Rhino add knots.
What would be useful is a option to interactively add knots similar to how you can do that with sweep2 command. Live feedback on the edge continuity would make this really useful.
Another thing about MatchSrf is that it matches the underlying surface rather than matching the edge curve. What that means is that after you run MatchSrf if you have to run Untrim on the edge that you just matched and then retrim with the surface edge that you just matched. This often results in a more accurate result so an option to retrim any trimmed edge that is being matched to would save the user some time.
I also prefer to add new control points or knots manually in the areas that I find most appropriate (or increasing the degree to keep the surface single-span), but the “Refine” option is still usable in certain situations. The added gazillion multi-spans is what makes it undesirable most of the time. In the example posted above Rhino added more than 30 spans in 1 mm distance of the surface.
I remember that VSR for Rhino 5 had a tool to rebuild a certain edge to the desired tolerance that worked much better than the default edge rebuilding of Rhino.
As has been pointed out for one or maybe even two decades, Rhino could benefit from a Control Panel that allows you to show/hide CVs, edit points, curvature combs, or change degree/spans of curves/surfaces on the fly. Also, in other software, the main surfacing tools have an interactive continuity check you can change to the settings you like, and also a continuity checking tool that is persistent and very configurable. Rhino has all the information under the hood, so to speak, so why not reveal them to the user in an interactive and easy to use fashion?
I’m aware of this new tool and I use it sometimes in Rhino 7. However, my proposal is about an active edge continuity tool (or a feature to be added to the existing “Global edge continuity” tool) that will be capable of reporting the deviation between a selected existing surface and the preview of a newly created surface while the latter is still not finished yet. That’s it, a preview surface that the user could adjust from the settings while examining the reported deviation (distance and continuity relative to the selected existing surface).
This is what I wanted to show in my video, except that I can’t add the aforementioned active edge continuity function since it’s not existing yet.
Here is an alternative proposal for Super Gumball, this time utilizing smart dragging that activates the currently set drag strength by simply dragging the mouse pointer away from the active Gumball handle.
It would be nice if the user is given the ability to adjust the settings for “Angle of activation” and “Distance of activation”. This way, the secondary dragging functionality could be activated according to the taste of the individual users. For example, a setting with 10 degrees for “Angle of activation” and 150 pixels for “Distance of activation” will ensure that the secondary drag strength mode will not be activated by accident by most users.
I already proposed that long time ago, but since we are closer to the release of Rhino 9 at some point, I thought that it would be nice to remind the developers about that and hopefully it will be taken into consideration before it’s too late.
The same “drag-away-from-the-handle” functionality could be implemented to other tools, such like the sliders for “Blend surface” (to enable ultra detailed fine adjustment with the mouse pointer), the new “Surface fillet” in Rhino 8, and so on. Currently, it’s extremely difficult or even impossible to use the sliders for fine adjustment, because the numerical amount there suddenly jumps from one rough number to another. The idea is to implement a variable drag strength for the sliders based on the distance of the mouse pointer (in a normal direction) from the active slider that’s dragged parallel to the latter.
No need to press the current individual buttons that heavily limit the range of slider adjustment.
P.S. A similar approach is used in most videos on YouTube, where you can hold the mouse pointer on the time slider, then drag it towards up, then it activates a fine adjustment of the time line and you can continue to move the mouse pointer sideways, parallel to the slider.
Rough time adjustment (sort of drag strength 100):
A major problem of the ! _QuadRemesh tool is that it shrinks the output SubD quite a lot, thus it no longer follows the intended shape and size. The reason is that it aims to snap the control points of the output SubD to the input geometry, which causes the shrinkage after the smoothing operation.
My proposal is to add an option to follow the input geometry by snapping the mid point of the SubD edges instead. However, one important exception should be made for the areas where the angle between the input faces is below a set value (default should be something like 50 degrees). That will allow replicating of shapes like water drop properly, ignoring the sharp corner at the top.
The 50-degrees angle threshold should prevent unnecessary bulging of objects that have a 45-degree chamfer (like most mechanical part designs). Of course, the user must be able to set any custom angle threshold in case that the default 50 degrees are not enough.
Manually optimized SubD to follow the target NURBS shape as close as possible. Note that the control polygon around the black dots 1, 2, 3 and 4 is outside the input geometry, with the middle of the control polygon being very close to the latter. The only exception is the bottom where the control polygons around black point #5 are shrunk inside, because the intent it to replicate a melted shape, thus the sharp corner of the input NURBS model is ignored.
In comparison, the current implementation of the “Interpolate SubD” option produces heavily distorted output shape, because it misses the ability to ignore sharp corners based on a user-set threshold.
“Quad remesh” with a rough polygonal preview before converting to SubD:
Yet another proposal for improving “! _Blend surface” and! _ChangeDegree.
A rational surface means that its control points have a variable point weight ratio. This causes lots of issues with the ! _Blend surface tool due to its reliance on identical point weight. The default point weight of free-form NURBS surfaces is 1 (identical for all control points), and Blend surface produces clean output geometry only with these.
“Loft surface”, on the other hand, ignores the point weight, thus it produces clean geometry even if the input surfaces have a rational (variable) control point weight. In many cases, “Loft surface” produces superior quality compared to ! _Blend surface.
! _ChangeDegree
Attached here is a sample 3dm file that clearly shows the urgent need to fix the aforementioned weakness of both, ! _Blend surface and ! _ChangeDegree. The 3dm file was originally made by @Slim1 in the topic linked below. I only added some markings for the Rhino developers to get a better idea what causes trouble with the “Blend surface”.
There are two shortcomings of the ! _Blend surface tool:
Degree 1 surfaces. Even though a basic plane is the simplest possible NURBS surface, a “Blend surface” that uses it as an input produces errors and is unable to maintain the expected low amount of control points. If you compare that with ! _Loft, you will notice that it performs properly, unlike ! _Blend surface. I already made a request to fix that bug in an earlier post here (the end of post #25), as well as in other very old topics since the Rhino 6 and Rhino 7 times, but it’s been years since then and unfortunately the bug is still not fixed… Rhino 7, for example, produces a “Blend surface” with 12 control points instead of 4 control points. How does Rhino 9 WIP perform here compared to Rhino 7? Is it any better?
For some reason, ! _Blend surface loses the ability to use “Interior shapes” if the input surface is degree 1 or rational (even if the amount of control points of both input surfaces is identical).
Rational input surfaces. As soon as the ! _ChangeDegree is applied to the bottom surface marked with #1 to change the degree in the V direction of from 1 to 3 (to match the same degree as the opposite surface #3), it produces a rational surface with random variable control point weight. In my opinion, this tool must be fixed to preserve the point weight to 1 once it detects that the original surface is totally non-rational (control point weight = 1).
And this is an alternative 3d file used by me in the video below that also shows how the ! _Blend surface fails due to the use of a rational surface as an input: Fix the Blend surface tool.3dm (5.9 MB)
I also captured a second video where I made a more detailed overview of the bug:
Once the large bottom surface is modified with the “Change degree” tool to match the same amount of control points (4 total) like the opposite surface, it becomes rational, which is causes lots of troubled with certain modeling tools, such like “Blend surface”. The solution is to either:
a. Set the control point weight back to 1;
b. Use the “Rebuild surface” tool. “Change degree” produces errors, so I recommend to be careful with it;
c. Use “Loft” with tangency option to both sides.
@Gijs@brian Request: Please, add the above conditions to the “Interior shapes” section of the Help topics for “Blend surface”, because the former are get disabled even if just one control point has a weight other than 1. Not having this particular condition well documented leaves lots of Rhino users guessing what’s wrong with their geometry…
This claim is incorrect. Loft does not ignore control point weights. If a rational curve, arc, etc is used as input to Loft, the result is a rational surface UNLESS the “Rebuild with” or “Refit within” option is selected.
It’s more appropriate to say that “Loft” ignores the bug that occurs with “Blend surface” when weighted control points are involved.
The “Change degree” tool definitely needs some polish to avoid the unwanted change the CP weight from 1 to random values like 0,99999999998 or 1,0000000003. These tiny deviations heavily affect the “Blend surface”.
What’s the current look of the panel? (Rhino 7 user here)
