For Rhino V6 wishlist


Thanks for posting this I would welcome something like these. I don’t think people are listening because we asked for such things in the past, instead McNeel gave us tabbed properties tab that slows down Rhino immensely, a what command etc, nothing in one place and convincing people who don’t understand how useful this even when the evidence is right in front of their face is rather depressing.
At least people could look at the videos you posted and respond.

It appears that some of building blocks are already there (not sure how easy this is to hook into under the hood): Edit > Select Objects > By Object Name/ etc. Having mapped the functions to hotkeys usage of the commands is still prone to error (i.e. a simple error forgetting to rename the object means it doesn’t show up in the list, so one has to close the window, hunt down the object in the viewport/ layers/ unhide/ and open the properties tab & rename - no time saved).

Almost everything under the Select Objects menu could be combined into one floating interactive window that doesn’t require objects/ groups, etc. to be renamed before showing up in the list. It’s similar to the selection window that pops up when one selects overlapping objects. Over the course of working on a complex model, the time spent hunting and pecking around in the viewports/ moving objects in layers/ hiding & unhiding adds up. It’s an unnecessary time sink.

Having been on the other side of software development, it’s a difficult line to walk. Resources are limited, there are always competing features/ priorities, and depending on how old the underlying architecture is it can be very difficult to implement something that seems apparently simple (sometimes the opposite is true as well). I’m sure someone has taken note but it would be nice to hear something back from someone at McNeel. A feature like this could be very deep, but even a basic implementation would go along way.

It would be fantastic to be able to associate layer states with saved views in a clean interface. This would be useful for exploring and presenting different design options quickly and efficiently.


I know this has been mentioned before, but I would greatly appreciate a separation of the mesh vertex OSnap and extrusion vertex OSnap.



Add simple text based Attributes to Objects; for example Specific Gravity, Material Name; for Example 6061 T6 AL, Length & Radius Fields, and the ability to export a list to Excel that includes the portions of Object Properties to generate a BOM from a model. Future functionality could easily be expanded to include Solidworks like functionality for BOM’s.
Best, Bill

1 Like

Hey there,
what’s about multi processor kernel for rhino 6?
Think thats one real important item.
See also this thread:

So it seems, that you guys at McNeel are working already hard on it?



Hi again,
what I also find very odd, is the fact that a curve copied from an untrimmed surface has more points than the surface edge.
I know it 's mathematic problem.
But VSR shows its possible to do it better, not perfect but better.

Also the rebuild curve/surface command:
It relocates the points in equal distances. It should calculate to optimized postion for each point to fit the original geometry with a defined amount of points.
Don’t know if that is possible.


Hi Andre- what do you mean, exactly? An isocurve? A projected curve? Can you post an example?



Hello Pascal,
no, I meant just copying the edge of an untrimmed surface.
Unfortunately I could find a model where this happened.
But it happend more than once.
I remember, that was an degree 2 surface with 2 by 3 points, but the copied curve had degree 3 and lots of points. Should be an arc.

If the curve rebuild command was improved, so that the points are not in regular distances animore, that would help a lot already.
What I don’t like on the VSR curve approximisation is, that there is no chance to get an curve with an defined amount of points.
As we all know, curves with equal amounts of points are the rule for good surfaces.


1 Like

I’m glad that André has commented on this, since it explains some problems I’ve also encountered, but did not understand. These related to watertight failures in polysurfaces when I sometimes needed to rebuild curves or surfaces.

The enclosed image shows a simple comparison of rebuilds for both a (Control Point) curve and an interpolated EP (Edit Point). Both were Degree 3 and the points and degree were kept the same. Both Edit Points and Control Points are shown for all.

I rarely rebuild with such simple shapes, so I was very surprised to see that the resulting CV curve was significantly different in shape after rebuilding, while the EP curve was still fairly similar. After this example, I’m a bit more reluctant to use rebuild than I have in the past since it seems to neither maintain the shape, nor does it uniformly distribute Edit Points. A bit confused here…

I’m not sure if my wish is the same as Andrés (and clearly there is some serious math creating these results), neither rebuild result created uniformly spaced Edit Points. Seems to me that an improved solution would offer some checkbox choices for Rebuild, such as: 1. Maintain shape, 2. Create Uniform Edit Points, 3. Keep Tolerance below X value, to imagine a few. Points and Degree might then be calculated results.

Hoping this makes some sense!


You might look into FitCrv. In theory it rebuilds a curve with denser knots in areas of higher curvature rather than evenly spaced knots. I don’t believe you can specify a number of knots, but you can play with the tolerance.

Right- the problem is, though - at least potentially a problem - is that the output is non-uniform, which will matter if it is to be point edited or combined with other curves in a loft or something.’


As Pascal is indicating, FitCrv will match the curve well, but introduces 4x as many CVs (which is not good for resulting surfaces). See bottom two images with FitCrv applied to original.


Pascal and @margaret,
The help file on FitCrv, aside from being a little too technical for me to fully comprehend, is silent on the Angle option. Could you explain how the value for Angle effects the output?

Hi All,
the target to me was to have far less points.
Often when I use curves from surface edges, these have for to many points to build a surface on.
As Dave already showed very clearly the fit curve command is not helpful, it increases the points.

@Pascal: The input curves are usually not uniform, why to make to output uniform?

I often have to reduce data sizes of models made by others, which don’t know about the problems of increasing points.
This shows an example of an boats hull, where I made some sections.

The surface already has far to many points, the sections even have more.
If soemone does not pay attention to this, the points will increase dramatically.
Second picture shows what the optimum would be:
Red is the original edge curve an the above surface with its points on.
Green is the rebuild curve with 5 points, evenly spaced, the deviation is really bad.
Blue is the same curve, edited by hand. It comes quite close to the red one and could be a lot better.

That would be my imagination of an perfect rebuild command.

To me the problem touches almost all rhino commands and if that could be improved, this would be really a huge plus.
Still rhino is the best program to work with. :slight_smile:


1 Like

Hi Mark- kinks in the input curve will be kinks in the output if the angle at the kink is greater than this number, otherwise it gets smoothed out. Help has been updated, I believe, but is not out there yet.


One nice thing about Rebuild is that it makes a uniform curve- these are nicer, better behaved, when point editing, and combine well with other uniform curves of the same structure in making surfaces like Loft. A series of refit curves will (generally) make a messier loft than a series of rebuilt curves (done together or at the same settings) So, making things uniform is part of the idea… however, there is RebuildCrvNonUniform, which helps match up curves’ points and does have a tolerance.


If you rebuilt to the same point count in each case, then the interpolated curves, on the right, will be closer to the inputs after rebuilding simply because they have more points, 7, vs. 5.


Would be kinda cool with some sort of parametric solution regarding wall height and wall depth. Would be cool if we check certain layers or objects as walls, then it will create a sort of baseline in the middle as default and we can change so the baseline perhaps is in the front or the back and so if we change the depth from 15cm to 30 cm it will expand either in 1 or 2 directions so it fits the shape we desire. The same kinda thing regarding wall height and ceiling/floors. It would be awesome if they could snap and follow each other or something like that.

@Pascal: This is a really interesting discussion. Both Rebuild and RebuildCrvNonUniform do their job, but there still seems to be a bit of a gap in desired behavior that would be very useful if it could be improved.

Take a simple—and very common—workflow: several curves need to become one curve, which then (ideally) would become one surface (not separate surfaces). As I understand it (and perhaps wrongly?) currently you Join the curves, then either Rebuild or RebuildCrvNonUniform, then for the result you ExtrudeCrv into a surface.

A few comments:

  1. JOIN: Minimum CVs (desired), Surface can be exploded (undesired)
  2. REBUILD: Uniform, but many many CVs needed to meet 0.01 tolerance (undesired—and this took a lot of point increases manually, clicking up arrow in rebuild box, to get tolerance as desired). Surface can be exploded (undesired).
  3. REBUILDCRVNONUNIFORM: Triple the CVs (possibly acceptable, but not desirable). One surface that can not be exploded (desired).
  4. DESIRED: Minimum CVs (like upper right). One surface that can not be exploded. (like lower right) If there was a way to achieve this result (as a Rebuild option, or a separate command), that would be truly fantastic.


Curves Rebuild and NonUniform.3dm (1.0 MB)