First thought was cool, clean simple API. I like it better than d3 to do the equivalent. -- Then I read this:
"When someone interacts with the graphics, for example by trying to drag an element to a new position, g9 optimizes over the space of possible values for your data to find a set of values that comes closest to creating the change. "
That is some highly magical DOM jimmying. High science weirdness. The applications I can think of where you'd need to manipulate a chart to modify data are all pretty niche (except for fun, which is universal). When the use case does come around this is going to be a delight.
I wouldn't call that high science. Average the velocity and vector of a drag event over the first few frames, keep averaging with more frames, and start moving everything to the predicted end-point with a nice ease-in-out, you're most of the way to "optimizing over the space of possible values".
I don’t think so. It looks like it’s using gradient descent optimization which does not require quotation marks around it and requires college level stem math for most people at least to really understand.
You're right, it turns out to be a gradient descent function adapted from numeric.js. Seems like a long way to go to interpolate mouse events into a range of values. Still suffers from gimbal lock in the cube demo. I guess since it doesn't allow you to manage the draw routine, you couldn't use quaternion to Euler conversion. I'm not sure I see the purpose of it. But what do I know, I don't have a stem degree.
"When someone interacts with the graphics, for example by trying to drag an element to a new position, g9 optimizes over the space of possible values for your data to find a set of values that comes closest to creating the change. "
That is some highly magical DOM jimmying. High science weirdness. The applications I can think of where you'd need to manipulate a chart to modify data are all pretty niche (except for fun, which is universal). When the use case does come around this is going to be a delight.