algorithmic modeling for Rhino

First working prototype of the Grasshopper2 equation editor/viewer. Gridline display is tied to the zoom-factor, equation grips can be shown and hidden per graph, panning and zooming fully supported.

It's not quite there yet but it's already a major improvement over the GH1 Graph editor which didn't allow for zooming or panning or multiple graphs.

Slight misalignment between graph curve and grips when zoomed in is a problem with the way WPF has been set up, should be fixable. Also the capture is a bit choppy, but the actual UI is fully responsive.

Views: 475


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

Join Grasshopper

Comment by Gregory Epps on August 10, 2015 at 8:44am

This is great - really looking forward to using this for setting acceleration curves for 6-axis industrial robots, where we need to limit them to a certain % acceleration/deceleration gradient. In this use case, we would want to use a function in GH to limit the acceleration gradient, but still allow for intuitive dragging of the rest of the curve.

This would ideally work with the Rhino curve input method option you mentioned, but preferably drawing directly in the GH component using an 'interpolate curve' function to keep things fluid.  I can imaging a more manual control as well, snapping three control points in alignment to keep a straight portion for the gradient + curve to blend into the following control point. 

We would be using this to control speed for a number of different Path components in the IO plugin which then get spliced together again in the Timeline, so we would want to simultaneously display a number of graphs in the same component or limit the zooming to match across all graphs for an intuitive sense of scale between graphs.

The graph editor is a familiar tool for animators, so we can see the new tools being really useful for the film industry etc who are used to this style of interface, plus it makes lots of sense generally for all those involved in time based projects.

Thanks again, Greg :)

Comment by Arthur Mamou-Mani on July 26, 2015 at 4:00pm

Great!!! David is it hard to make the handle of the graph controllable through X and Y coordinates input? Then we'll be able to link the Graph to Galapagos :)

Comment by Ángel Linares on July 25, 2015 at 5:30am
However graphs will be their own data type in GH2

Nice! :)

Comment by mark zirinsky on July 22, 2015 at 9:33am

I was attempting to think of a way to save coding all of the possible equations that someone can think of. let the user do it, perhaps by defining the equation (as already can be done in gh). Obviously the 2 dimensional cases (2 output variables) are easier than 3 dimensions or more (z, time, thickness, color, sub unit composition, normal orientation etc). anyway, great work. much easier to use GH for wave equations than coding from scratch (the jade piece n the photo on the on the left was wave equations coded from scratch in basic)

Comment by David Rutten on July 22, 2015 at 8:15am

Perhaps a tie in to the wolfram equation database, or the ability to import those? 

Wouldn't that also require the Wolfram engine to solve those equations?

And of course, when can we get our hands on it.

Ah, that'll be a good long while I'm afraid.

Comment by mark zirinsky on July 22, 2015 at 7:39am

great stuff. perhaps a tie in to the wolfram equation database, or the ability to import those? And of course, when can we get our hands on it. 

Comment by David Rutten on July 21, 2015 at 5:46am

And also an uvinterval as input to avoid reparametrize the data.

Not sure about that. I actually wanted to get rid of domain and co-domain options altogether. Just have the graphs exist wherever you want them in space. However graphs will be their own data type in GH2 so it'll be easy to make some components which take graphs as input and evaluate them with custom (co)domain modifiers.

Comment by David Rutten on July 21, 2015 at 5:43am

I haven't really thought this through, but I believe the ability to snap the grips on the grid nodes could be useful as well.

Indeed, I've been wondering myself whether and how to expose snapping. I can imagine the following snaps would be useful:

  • Grid.
  • Other points.
  • Directly above or below other points.
  • Directly to the left or the right of other points.
  • Near snap to graphs
  • Distance snap to graphs

I don't know when I'll get around to that though, but I need to come up with some sort of snapping engine as it is also needed for regular component positioning.

Comment by David Rutten on July 21, 2015 at 5:39am

Could you add an interpolated or a nurbs curve with several control points?

Yes I've got more equations set up already than visible here. It'll also be possible for plugins to provide more equation types. Equations currently working:

  • Constant        f(x) = c
  • Linear            f(x) = ax+b
  • Parabola        f(x) = a(x-h)² + k
  • Polynomial     f(x) = a + bx² + cx³ + ...
  • Hyperbola      f(x) = (ax + b) + (d/(x - c))
  • Reciprocal      f(x) = 1/((x - b)^p) + c
  • Logarithm      f(x) = log[base](x-b) + c
  • Cosine           f(x) = a*cos(f(x-b)) + c
  • Sinc              f(x) = a(sin(f(x-b))/x) + c
  • Gaussian
  • Block Wave
  • Sawtooth Wave
  • TriangleWave
  • Perlin Noise up to 8 octaves
  • Interpolation of N points using various interpolation schemes: {Nearest neighbour, Linear, Cubic, Akima, Bulirsch-Stoer, Equidistant polynomial, Floater-Hormann, Neville polynomial}
  • Rhino Curve (not quite sure yet how to expose control-points on this one)
  • Grasshopper Expression
  • Bezier spans, i.e. N sequential points and tangents (still working on this one actually).

I could add more types such as tan, arctan, hyperbolic trig functions, square-roots, etc. etc. but I've got enough for testing purposes now.

Comment by Daniel González Abalde on July 21, 2015 at 2:48am
Ah! And also
an uvinterval as input to avoid reparametrize the data?




© 2020   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service