Gradient Editor for Grasshopper 2

Trying to make a kick-ass gradient editor for GH2. Improvements over gradients in GH1 so far; more and better standard presets, panning and zooming (one dimensional), window selection for grips (with correct window/crossing testing for selection boxes drawn left-to-right or right-to-left), different display of continuous (round) vs. discontinuous (diamond) grips, more interpolation modes including 'cubic' and 'cubic cyclical' which can result in more natural overall gradients, number line display.

Many things still do not work at all or as well as they should, the previews in the preset menu should be bigger, the floating buttons don't support icons yet, there's no mechanism yet to add, remove or recolour grips.

I hope to also include a second type of gradient, one that is controlled via equations for rgba channels rather than a sequence of grips. I'd also like the add the ability to import/export common gradient file formats as well as exporting gradients to custom resolution images.

26 members like this

Get Embed Code

Tags:

Latest Videos

Comment

You need to be a member of Grasshopper to add comments!

Comment by Guido R on June 21, 2017 at 9:48pm: loosely something like this but accurate?

Comment by Theodoros Galanos on June 21, 2017 at 9:40pm: I second Guido's proposal, might become a sort of tool to make all these data driven walls.

Although, I would add that it is already kind of possible to turn data, normalized for example from 0 to 255, as colours. That's how I'm doing most of the convolutional stuff atm.

Comment by Guido R on June 21, 2017 at 9:07pm: David,

This interface is super cool but do you think we could have a component to create gradients with data?

...and output a gradient as an actual datatype?

Comment by David Rutten on August 3, 2016 at 9:27am: @Martin,

It actually looks a bit as if it could be used through touch devices. Is it on purpose?

Not really on purpose, I'm trying to keep an open mind about stylus and finger input this time around, but I'm not actually testing any of that yet. I tried to, but my order with MS for a Surface Pro 4 fell through and anyway they seem to be crap devices so this approach has been shelved for the foreseeable future.

Comment by David Rutten on August 3, 2016 at 9:24am: @Tom

So does this mean I should switch over to use eto in a cross-platform framework in order to keep it convertible to gh2?

You'll have a hard time switching on Rhino5. Rhino6 ships with Eto and we're doing a lot of interface design ourselves using it, but until you're developing for Rhino6 and beyond there's no point. In general it is indeed a good idea to separate out as much as possible the core functionality from the UI, it will make switching out UI frameworks less work later on.

How will the custom component creation be in gh2?does it change completely or is it only an enhanced "gh_component"- class?

GH2 is a complete and total break from GH1 in SDK terms. Almost nothing works the same, although it will probably not be too difficult to translate pure components from one to the other. However as soon as a component features some non-standard stuff you're in trouble.

The reason for this is that it was very important to me that GH2 is well suited for multi-threading, which in turn really benefits from having immutable types. Also the GH1 SDK accreted a lot of cruft over the course of its development* and I'm trying very hard to get rid of that. However the good news is that almost all the standard features component developers typically use does not involve any UI framework specific code, it's all abstracted.

* The very first version could only ever store 1 value per parameter, then parameters could store arrays, then later again data trees, and that's just one example of some really fundamental changes.

Comment by Martin D. on August 3, 2016 at 6:26am: Looks nice!
It actually looks a bit as if it could be used through touch devices. Is it on purpose?
Would be interesting to have grasshopper on your tablet while watching Rhino viewport on desktop screen.

Comment by Theodoros Galanos on August 2, 2016 at 12:02pm: This is beautiful!

Can't wait to use this on my CFD visualizations.

Comment by David Rutten on August 2, 2016 at 11:11am: @Tom, neither. It's done using Eto.Drawing, which is the cross-platform framework we're using for Rhino6 Windows and Rhino for Mac. In this particular case it's running WPF behind the scenes, on Mac it would run CoreGraphics, I believe we're going to try to make it use DirectX on windows in the future.

Comment by David Rutten on August 2, 2016 at 7:59am: The idea is for that to be the Smoothing button. It only makes sense when at least one grip is selected so that's why it keeps coming and going. Also note that I'm using 'glacial' speed for all button animations because I want to see exactly how and when stuff starts to move. Eventually instead of the 2500 millisecond animation I'll switch to 'normal' which only takes 350 ms.

Comment by Andrew Heumann on August 2, 2016 at 7:17am: What's the button in the upper right that keeps appearing and disappearing? per-grip settings?