Hi all,
just to understand the difference between GH2 and GH, I would like to ask this simple question: by design, will there be something that you cannot do with GH, and you’ll be able to do with GH2?
Thanks
Hi all,
just to understand the difference between GH2 and GH, I would like to ask this simple question: by design, will there be something that you cannot do with GH, and you’ll be able to do with GH2?
Thanks
I’d like to think it would be reading a comprehensive user manual, but I fear history is against me…
Regards
Jeremy
I’m most excited about being able to attach meta data to the geometry workflow. The ability to know/sort geometry thanks to being able to custom identify it should open up huge scope for more powerful scripts.
Cheers
DK
The main difference is the major version number
We will see, but from what I have observed, Grasshopper 2 will improve in many aspects but it won’t be something completely new.
So conceptually you won’t see a revolution but you will see many great improvements in UI, Workflow, Performance, Scripting etc .
Depending on what you do, the major criticism is that you cannot completely access Rhino as you would do with direct modelling.This is not really the fault of Grasshopper but of the RhinoCommon Api.
In any case, a tool which supports plugin development and scripting is potentially a tool which can do anything you want. Of course with a decent knowledge of coding, math and lots of time to waste, you can customize it to your needs. But this is a “feature” since the early days of GH1…
One thing I want to point out is that Grasshopper is also an educational tool, and if it manages to even more simplify visual scripting, then its a great way to get people into coding
That probably depends on what “do” means and whether you’re allowed to include plugins and scripting components.
By the former I meant whether your referring to the output of a grasshopper file (i.e. can you make data with gh2 you couldn’t with gh1) or the contents of that file (i.e. can you make data in a specific way).
I’m hoping that certain GH1 plug-ins will be obsolete and everything that was done with the plug-in I’m GH1 is done with native GH2 features… for example Elefront
My question is to be intended in both senses because from the first sight at GH2 I see a major UX improvement leading to slightly different workflow logics which I guess will optimize some practices, but I still don’t understand wether this is done to empower the previous version or to open up whole new possibilities and different outputs.
What I want to say is that when for the first time I saw Explicit History I found the answer to many questions that I had…while in this case I see the answer but I still have to understand the question.
I suspect that it’s almost impossible for GH2 to do something that GH1 couldn’t, because Grasshopper is ultimately a programming platform, so you can do whatever you want. What is absolutely clear is that for the time being you can do a lot less with Grasshopper 2.
There were certain things which were very cumbersome to do in GH1, even if they were possible, and it’s those areas I mostly focused on, and will be focusing on. So if in about a year from now you find that you can do all the things you used to do in GH1 but it’s just less of a hassle, then I’ll count it as a success.
If at some point in the future Grasshopper can do loops and blocks in a good way that would already be a great win for me. That includes having some ways to ensure execution order, because that is usually where you end up pulling your hair out with both.
Other than that it would be nice if it was a bit easier for Grasshopper to talk/listen to the “outside world” a bit better, like having a native way to get some asynchronous stuff from the web, ie. APIs.
Also, I would appreciate the possibility to bake/compile self executable pieces of code (for example to solve geometric tasks out of rhino, or to run multimedia installations without having rhino + gh opened).
Hi! For now I did a basic implementation for sorting, evaluating expressions and dispatching objects based on their keys: Inkbeagle Data | Food4Rhino
Might still be buggy or lacking features, but think the base is okay for most of what I need in daily practice. Let me know what you think.
I’m not sure if this is the right question; it’s more like:
Will there be any performance improvements or architectural changes that will enable work to occur that was previously computationally, time, or functionally prohibitive in previous version?
For instance; enabling Cpython nodes would be quite impactful, and having more multicore integration would also allow for much more computationally intensive tasks to be taken on.
I think there is misconception about what Grasshopper is.
Grasshopper is “just” a (visual) scripting editor for Rhino. Of course, it comes with many extras, but under the hood, it is a ‘User Interface’ for automating Rhino. If you speak of performance, a true integration of CPython etc., then this is foremost a subject of the Rhino ecosystem. There are efforts in integrating CPython and of course the Rhino Kernel is improved in terms of performance, but thinking of parallelizing anything will improve performance is a ‘naive’ view on programming.
The key of performance improvements is to decrease algorithmic complexity. Sure, on all layers there are many possibilities, but all boils down to code things as direct as possible with as few calls as possible. And this contradicts a bit with the concept of Grasshopper. Grasshopper allows you to write code without writing any line of text. You compose logic out of pre-written generalized(!) code-pieces (“components”) on a whole extra code layer, which is already a drastic trade-off.
Apart from this, there is again a chicken-egg problem. More performance means more garbage to produce. So there will always a lack of performance…
So again, I personally think that GH2 will improve the User experience greatly, but I doubt you see game-changing things!