Grasshopper

algorithmic modeling for Rhino

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.

Views: 435

Comment

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

Join Grasshopper

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 Tom Jankowski on August 3, 2016 at 1:34am

 "...use eto in a cross-platform framework..."  of course i meant "...use the cross-platform framework  eto ..."

eto seems to have to have the same syntax anyway. so a conversion from winforms to etoforms seems to be done only by replacing the using statements and references.

well at least if I'm not using the designer, what i'm not doing here anyway.

Comment by Tom Jankowski on August 3, 2016 at 1:06am

okay, thank you.This is  very interesting.Currently I integrated some windows forms for an upcoming version of my plugin.  So does this mean I should switch over to use eto in a cross-platform framework in order to keep it convertible to gh2? How will the custom component creation be in gh2?does it change completely or is it only an enhanced "gh_component"- class?

I separated core functionality from gui anyway, but i found out that using  forms to setup a component has actually some really nice advantages.like f.e. I can explain functionality better or i can minimize input parameters.Now if I decide to use more forms, a conversion to gh2 could be more difficult later.

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.

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2019   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service