I know it was mentioned earlier but I think it´s worth to raise this debate again.
I heavilly use history in Rhino 5 and I suggest it to all people when teaching Rhino. It´s really great tool for conceptual design, of course you must be aware of it´s limitations. I especially enjoy chaining more history enabled commands together, which results in very intelligent and almost parametric objects.
But I really miss one thing - being able to change command parameters, not only input geometry. When I show people array commands with history, I am usually changing input objects (rebuilding them, deforming using CV´s etc) and all array instances change accordingly. Everybody say: “Hmm, this is nice, and now change the number of objects”. They can´t believe this is not possible.
I don´t ask for parametrical tree like in CAD programs. What i am asking is some more robust history. When I click to some object with history, I should see all commands that were used to build it and I want to be able to change it´s parameters. In my wildest dreams I can even imagine that this would be accomplished by some extra-light version of Grasshopper. Clicking on some object would rise some Grasshopper-like object/command tree, something like on this image (simple loft with 3 curves):
From what I understand, you ask for something, that translates a history stack into a Grasshopper definition in order to expose the numeric parameters of each command involved?
What’s the big difference to building a GH definition from the beginning?
in fact don´t want to translate Rhino history into Grasshopper definition, I only want to show Rhino history tree in some nice form and GH just seems to be an interesting tool for it. Rhino history infrastrucutre is already here but without any visual hint. Clicking on object created with history should give you instant overview on child/parent object relations with possibility to change command parameters. It´s a pitty that history is so underestimated features. Even long time Rhino users were so surprised when I showed them Rhino history!
Grasshopper is great but it´s not for everybody. I think that extending current history possibilities would be just logical step without having to learn a new logic behind GH…
You might like the simplicity of the History. But that simplicity comes with a lack of functionality. You want to expand that. But why stop at exposing the numerical parameters and draw a visual representation. You might want to edit the stack, add mathematical relations to some of the parameters. You might want to have more commands to be history enabled…
Maybe you are aware, that in the beginning Grasshopper was called “Explicit History” and its sole purpose was to extend the History functionality and give it a nice visual representation. I’ll admit it has grown a lot since the early days and may have become a bit frightening to beginners. But if you ignore everything beyond the current possibilities of History, it is all there.
Right now most default Grasshopper do nothing more than hand down the input to the internal representations of the Rhino Commands.
With Grasshopper getting more integrated in V6, I would even expect History to be replaced.
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.
Thanks for being this open and transparent in your views about these type of issues.
Sharing information like this, is invaluable for understanding the intentions of you as a
client. Much like I (we) are your clients; you are our client as well. Having a feel of a mutual
understanding is IMO the best basis for a healthy and constructive relationship.
I’m happy to find this post, because this is something I’ve been thinking about for some time.
From my point of view, Grasshopper at the moment seems like an incredible interactive tools creator. Apparently if you are familiar with scripts creation or any kind of math code, this visual interface brings you a friendly arsenal to create new tools like a stairs creator with dimensions controled by sliders or any other super complex organic structures. But this is not the case of the regular or new users.
What I always want to find in new softwares are tools that make complex things easy to the user, and then if you want to make something more specific you enter to and advance mode. GH starts in advanced mode, where you feel a bit lost.
I realy trust in the developers criteria to bring new solutions for the users requests, I don’t want RMA to copy solutions from other programs, but at the moment I agree that it need a better integration.
I agree, its very very powerfull but idd it starts in advanced mode, i started learning it a couple of months ago, now months later i have to start over again because i pretty much forgot everything,…
But that’s a problem any flexible tool faces sooner or later. The more flexible, the steeper the learning curve. In my experience, simplicity always comes with a lack of functionality.
I really have a hard time imagining Grasshopper to have a “simpler” interface without heavily cutting back on functionality. Maybe you have some ideas how that would work. Maybe some examples of other applications that work for you in a simple way?
Well for instance, i use world machine also, which is also node based but its alot more easier, one thing i found to be quite hard was that i couldnt understand the errors, maybe it was just me, could also be the language barrier.
I did quite some tutorials on YouTube by Nick Senske or something (sorry if i get the name incorrect) after doing over 10 tutorial i still didnt get anything,…I really dont have a clue to make this program easier, i just wish i got it :(…
Ok, I see. just watched a few videos on world machine on YouTube.
Well WM is node based but hides a load of complexity in just one container. Each container is pretty specialized in what does and how it modifies a very small set of inputs. In Grasshopper terms, Lunchbox might be a good example of something similar. I believe Bee is another project aimed at packaging common tasks into premade clusters that hide the more complex stuff of GH.
Regarding error messages: there is always room for improvement here. The basic problem here is that error messages are written by the programmer in a way to best identify the problem. There sure are better ways to say “parameter x failed to collect data”. “You need to connect something to the x input. That something needs to contain data and that data needs to be able to somehow translate to what data I would actually expect at that input” for instance may be more readable to non-programmers but is also pretty long and probably not more helpful.
Hi Halo I agree with you about the flexibility and learning curve, and I think I may not have the best answer but just some ideas as an old rhino user.
I remember one examples that may help.
In Dreamweaver you have the option to see the code or work visually, or you can start from a template that has some complex code that makes specific things. A code that a regular user will never understand, but and advanced can use as a good start and edit it.
Could we create rhino plugins with GH? plugins controlled by a tab like the first post picture?
GH plugins could work like a template, or visual interactive script, anyone who knows about GH can then adjust it to his own taste.
Can we integrate progressively some tools that make sense in rhino?, and replace originals with a nodal advanced mode option?
I can imagine array on surface could have some sliders to define distance and nodes to replace the objects involved. Also a couple of functions for non orthographic distribution.
We could have a nodal material editor.
A project curve version with a node that defines a criteria for rebuild, like number of control points or tolerance.
One issue with Rhino and GH is that they are extremely open, they are not marketed as Class-A surfacing for Cars, or the best for Organic Architecture or Jewelry sculpting… And we know that with the tools you have, and a good knowledge about Nurbs and Sub-D (with T-Splines or Clayoo) you can create whatever you want. But we don’t have many interactive tools for specific tasks of an industry.
GH seems like a great opportunity to let people create specific and flexible tools.
This is the kind of stuff I was talking about in 2014, there shoud be a simpler way to integrate complex GH tools in rhino for regular users that prefer to focus on design and don’t want to learn how to code, like me. I understand what’s possible and how it works, the same way I understand what can be done with a 5 axis CNC or other tools, but there are people that loves coding may want to develop this kind of tools like super power scripts.
Look how they are also creating this nodal history
