Partial Developer Absence

Dear GH users,

over the next 3 weeks (till November 12th) I'll be in Seattle at McNeel headquarters discussing the road ahead for Grasshopper 2.0. I'll probably have very little time for support and discussions during this period.

The major topics discussed for GH2 during this period will be:

Documentation/Help
GHA/Cluster/VB/C# App-Store
Localization (i.e. languages other than English)
Constraint Engine implementation
Improved VB/C#/Python development tools
Multi-threading the solver
Building a Mac version

If you feel something important was left out, please let us know here. Note that incremental improvements and bug-fixes are not worth discussion as we'll try and get around to them no matter what. Topics on this list have to fit the "Are we going to try and do X?" format.

David Rutten

david@mcneel.com

Tirol, Austria

Replies to This Discussion

Permalink Reply by Benjamin Golder on October 14, 2013 at 6:56am

Documentation/Help
- Yes, more of this would be helpful. Often I see beginners open the help for a component and find no new information. It would be nice to include examples in the help wherever possible.
GHA/Cluster/VB/C# App-Store
- Different from Food4Rhino? All I really want is to be able to package my python scripts with modules and python packages.
Constraint Engine implementation
- YES please. This would be an amazing fantastic feature.
Improved VB/C#/Python development tools
- Please just make it easier to package dependencies. There are so many great code editors in the world.
- The GhPython environment is really buggy. variables stick around after deletion, external modules aren't reloaded. There's some good and bad effects of having all the components on a canvas share the same python execution environment (namespace pollution vs. code reuse), this could use some more thought.
Building a Mac version
- Grasshopper and Rhino are the only reason I use Windows. :) Rhino Mac still seems too buggy for me to depend on, but in the long run I would love to have Rhino and GH for Mac. I feel skeptical about the stability of Mono applications, and using IronPython through a .NET emulator on a Mac would feel so weird when there's a native python by default, like drinking coffee imported from England while living in Ethiopia.

Permalink Reply by David Rutten on October 14, 2013 at 10:07am

GHA/Cluster/VB/C# App-Store

It could well be based on Food4Rhino, that's something that needs to be decided this week. What I'm looking for in an AppStore is:

Has to run inside Grasshopper UI.
Automatic install/uninstall of plugins at runtime.
No login required to download plugins.
Plugins can be automatically downloaded + installed if you open a file which needs a component you don't have.
Plugins will be updated automatically.
The interface should give an overview as complete as possible of all the possible GH plugins. I.e. you'd have to be a fool to develop a GHA file and then not put it on the appstore. This means we need to provide all the tools and features needed by developers (which is sometimes problematic, especially when it comes to paid-for plugins).

David Rutten

david@mcneel.com

Seattle, WA

Permalink Reply by Ante Ljubas on October 14, 2013 at 9:21am

seamless integration of openNURBS into a scene graph implementation like openGL or directX for direct rendering... should speed up things a little according to this source: http://cg.cs.uni-bonn.de/de/publikationen/paper-details/balazs-2008...

Permalink Reply by Ante Ljubas on October 14, 2013 at 3:07pm

this is rather a suggestion for rhino but rhino urgently needs a printing option to hybridize vector and pixel material ... good cad in architecture business uses this option (e.g. vectorworks)

Permalink Reply by Michael Pryor on October 15, 2013 at 9:13am

Would be nice if there was way to link things like the gradient component or graph mappers, like control one changes all the linked one. Sometimes its just nice to have separate components for each data stream but with same color or graph settings settings.

Also, I think these components such as image sample and graph map need variable inputs similar to the gradient tool so we don't have to click in the menu or remap all the time.

Thanks for the hard work.

Permalink Reply by Thomas Perkov on October 15, 2013 at 9:26am

^^variable sliders..

Permalink Reply by Michael Pryor on October 15, 2013 at 10:18am

is that a request?

Permalink Reply by Thomas Perkov on October 15, 2013 at 12:18pm

yup

Permalink Reply by Michael Pryor on October 15, 2013 at 10:23am

To clarify I mean to unify the position of a color on the gradient tool or the curve of a graph on a graph tool across multiple instances of these components. Not its inputs which can be linked via sliders.

Permalink Reply by David Rutten on October 15, 2013 at 10:34am

Hi Michael,

I think I'll try and make gradients and graphs actual data types in GH2, so you should be able to create them through code. It will then also be easier to have them as inputs for many components.

Another idea which has been floating around for a long time is the idea of leeches. Little objects that you can attach to components etc. that modify some of the properties. For example Domain (useful for sliders and graph mappers), Preview Colour, Enabled/Disabled, etc. etc. etc. If these leeches can communicate via wires then you could modify properties en masse.

Would these two things solve your problems if I were to implement them?

David Rutten

david@mcneel.com

Seattle, WA

Permalink Reply by Michael Pryor on October 15, 2013 at 10:41am

Yes,

That sounds similar to what I am thinking, It sure would make editing these things easier.

Thanks.

Permalink Reply by Frane Zilic on October 15, 2013 at 8:43pm

Could this be solved by allowing multiple t inputs (t1,t2,t3) on the gradient component with ZUI? (and automatically an output is created for each one, like the sort list component)

With the same logic one should be able to set two domains on the graph tool and multiple inputs with ZUI.