This is something we (the Rhino core team and me) talked about last November while I was in Seattle. There’s two things we looked into with regards to the overlap between Grasshopper and Rhino History:
- Import Rhino History into Grasshopper as a functioning network
- Edit the Rhino History record using Grasshopper as the interface
There are a number of problems either way, some can be solved just by typing a lot of code, others require more thinking:
- Not all commands in Rhino that support History are usable from the SDK, and even if they are the logic might not be exactly the same. This is a fundamental problem in my opinion, all command algorithms should be available 1:1 in the SDK. We are trying to be better at this in the future, but we’re not there yet.
- Even assuming all commands could be replicated via the SDK, Grasshopper certainly doesn’t have all these components. And when it does have a component that mimics a command, it may not have the same inputs.
- There is no enforced standard for what a History Record looks like. Every command is allowed to store whatever data it needs in whatever form it wants. Although there are guidelines, these are not followed every time. Furthermore, history records are not part of the we-promise-not-to-break-this part of the SDK. They can be changed with impunity at the moment, which makes it very hard to build a bridge between History and some other application.
- A lot of commands and therefore a lot of history records store information about mouse picks. Trimming, lofting etc. all harvest data from where the user picked a certain object and in what viewport it was picked. Grasshopper doesn’t have this sort of functionality at all. Take lofting for example. It’s not just the order in which you pick the curves, but also near which end you pick the curves. Some curves have their directions reversed by picking them near the end-point. To replicate this in GH you’d have to peel apart the entire curve list, flip the correct ones and then merge the data again.
- Sometimes a history record is pretty complicated. Divide by Length for example generates a bunch of points based on a curve. If you deform the curve then the number of points may well change. If these points are used downstream in other history records things get pretty hairy pretty quick.
- Commands may have been poorly designed from an algorithmic point of view. Loft is again a prime example. The loft command has several options for type, one of which is developable. It has become clear over time that making a developable surface from curves is an entirely different process than lofting and it should have been a different command. These decisions are difficult to change once they’re made (because of legacy support) but they make certain commands and history records more convoluted than they should be.
Although it seems like a match made in theoretic heaven, History and Grasshopper are real products with real scraggy edges and rough patches. We decided that we’d try to see if we could make the Loft history record importable in Grasshopper, which is something we still intent to do, I’ve been busy with getting GH ready for inclusion with Rhino6 and Dale Lear has been busy with fixing other problems with Rhino6 (nobody wants to be the guy who delayed the release). I’m not sure when we’ll get around to this, but I’m quite interested myself to see how feasible this turns out to be.
–
David