We Keep Coding

Need help dissecting and recreating the perfect scroll easing based on PastryKit

With web i usually just use the native scroll mechanisms. They are fast, reliable and there is no coding involved.
But, while working more and more in Unity, i have discovered that the available plugins for scroll, even the big ones such as Unity.UI or NGUI are simply awful. I have asked around, and found out that it is like that in most platforms. The physics is plain bad.
I did a bunch of research and i have tried a few solutions, from NGUI scrollView, to web iScroll.js and so on. I have found no solution as perfect as the original Apple's PastryKit. Now, PastryKit is old, deprecated, has no API and as hard to read as hieroglyphs.
But what is important is that while making it, they have managed to exactly recreate the iOS kinetic scroll physics behavior.
I am not trying to implement PastryKit , i am trying to find out how it works. I am trying to understand and replicate.
I am trying to find out the easings/formulas they use and logical conditions they use them in. Apple has a crazy way of writing confusing JS, so even tho i am a full stack developer, i am having a hard time tracing everything down. And i figured few brains is better than one, so lets see, does anyone understand this file? :D
https://github.com/jimeh/PastryKit/blob/master/mobile/dist/PastryKit.js
IN SHORT (so there are no misunderstandings): I am trying to extract a set of physics rules from this file, which i can use as guidelines in order to write my own implementation of scroll on any platform i choose. :)
for example: 'normal' scroll is defined by {>300ms && >10px}, apple uses the following bezier curve when easing the animation of slowdown. cubic-bezier.com/#.25,.46,.1,.94
UPDATE: We solved this a while ago. We discovered how Apple does it's momentum.
https://medium.com/homullus/recreating-native-ios-scroll-and-momentum-2906d0d711ad

After many hours of dissecting the algorithm, we concluded that Apple is in fact using magic numbers. And the magic number is: (drumroll) momentum * 0.95.
Basically, while the touch lasts, apple lets you move the screen 1:1.
On touch end Apple would get momentum by dividing number of pixels that the user had swiped, and time that the user has swiped for. If the number of pixels was less than 10 or time was less than 0.5, momentum would be clamped to zero.
Anyways, once the momentum (speed) was known to us, they would multiply it by 0.95 in every frame, and then move the screen by that much.
So idiotically simple and elegant, that it hurts. :)

Do you draw the entire object?

Hi I'm working on learning 3d game development and I'm starting with JavaScript and the html5 canvas and I was wondering if I were to have a 3d model do I draw the entire model(front, back, etc) and let the web browser decide what to render or should I try to just draw the sides that are in view of the camera? I ask this because I can see how it would be faster to do the latter of the 2 but that can get very complex and I'll need to do quite a bit more research to find how to do that.
Thanks!!

It's up to you, but it depends at least in part whether it's more expensive to spend the time clipping the model or just to render the entire thing dumbly.
Modern GPUs are pretty fast at drawing tons of geometry, so you often won't optimize the geometry sent to the card. However, it sounds like you're using the 2D canvas and writing your own rasterizer, so it may well be faster for you to do some quick optimization. Profiling and experimenting will turn up the right answer for your particular project.
If you're just learning I wouldn't worry overly about performance at this point but instead making sure you get the fundamental ideas and math down.

JavaScript InfoVis Toolkit ability to handle high volume of data

Does anyone have experience displaying large set of data using JavaScript InfoVis Toolkit? Basically, I am doing research on how my project can provide visual representation of social network... and playing around with JavaScript InfoVis Toolkit I did not notice any performance degradation... meanwhile I saw this:
JavaScript InfoVis Toolkit - interaction seems a little slow, maybe that's on purpose in the demos from
javascript framework for relationship visualization
and
JsVIS is pretty nice, but a little slow with larger graphs. from
Graph visualization library in JavaScript
this makes me worry that under real data it might crack? So just asking..
plus i looked at Flare, it seems like another good alternative, but looking at their site it looks like it hasn't been updated in almost 2 years... is it totally outdated?

To answer my own question.... performance is not that great. I wrote a script to populate json object used in ForceDirected object with 100 nodes and it was terribly slow... will give www.graphviz.org a try.

It's quick enough if not using such things like gradient background and other processor consuming visualisation.
I made Sunburst with 3 levels and about 100 nodes. Quick enough.

OK, I'm totally biased here (disclaimer: I'm an author of it), but KeyLines can handle several hundred nodes just fine - it is commercially licensed.
In general terms - aside from the issue of what framework to choose - I've found that canvas performance depends strongly on whether the browser+device has hardware acceleration. For example, before iOS5, iPad performance for canvas in Safari really was dreadful, but since iOS5 it flies along. Android is more variable. Most desktop combinations of browser/OS are now fine for high performing canvas rendering.
Another consideration for graph layouts is whether long running layouts block the browser's rendering loop - we've had to develop around the issue of long running (i.e., more than a few seconds) tasks locking up the browser. Users like to see progress bars ticking along & that is possible provided you take the right steps in the layout code..

Is there a water physics engine for javascript?

I want to make a demo using javascript and <canvas>, I was thinking of doing a little moving creature, seen from the top and swimming in a water environment.
Concept "art" :
Is there something I can use to start this project, or do I need to create everything from scratch ?

Here's one demo
http://code.almeros.com/code-examples/water-effect-canvas/

http://rumpetroll.com/ is open source and has the kind of movement you could probably modify to do as you wanted

I'm not sure what exactly do you intend to simulate (or whether I got the conceptual art :) ), but this might be a direction:
processing.js is not a physics engine, but rather a graphics library port to javascript (utilizing canvas) - http://processingjs.org/ .
However, you might find something in their demos that is similiar to what you are trying to create.
One of the original processing library examples has a nice fluid simulation using a particle system, and it runssuccessfully on processing.js - http://processing.org/learning/topics/fluid.html , however the framerate is very poor. You can try it yourself at http://processingjs.org/learning/ide - just copy&paste the code from the example (and prepare for your computer to crawl to a halt).
You can try to adjust the particle numbers (pnum), to improve speed, and play around with other variables.

Sorry I don't know of a library, but I did see a water physics in canvas demo recently:
http://hakim.se/experiments/html5/wave/03/
Maybe you can get some inspiration there...you might be able to accomplish it with a normal JS physics library like Box2DJS.

Just an idea, but you could search for a Java engine and then use GWT to compile it to Javascript.

Fluid dynamic simulation, with obstacles

I'm trying to write a fluid dynamic simulator on the HTML5 canvas. I've found some real damn cool stuff on the internets that always look like a promising starting point, but they are all cell-based and use some crazy math.
I'd like to be able to add arbitrary obstacles (lines of any orientation, circles, etc) to make things more interesting, but I've no idea where do begin.
Does anyone know of some fairly simple equations for fluid simulation that include obstacles of any orientation? Alternatively, could anybody point me towards the math required to take one of the above examples and add obstacles?
I know that this question borders on something I should ask mathoverflow, but they seem more into the theory stuff. Apologies if I'm in the wrong area. I don't really know where to begin - if anyone's worked on fluid simulation with arbitrary obstacles before, I could use some pointers.
Accuracy takes a back seat to simplicity here.
Thanks!

Fluid dynamics isn't a simple topic. All that "theory" they like over at the other site is just the way this field works.
The simplest example of fluid flow is 2D, incompressible, irrotational, laminar flow. I'd start by looking into that.
But it's not an easy field. There's no "Teach Yourself Computational Fluid Dynamics In Ten Days" books out there.

The best book to read for introduction to graphics-oriented fluid simulation is "Fluid Simulation for Computer Graphics" by Robert Bridson (disclaimer: he was my PhD advisor).
http://www.cs.ubc.ca/~rbridson/fluidbook/
Ultimately, there is plenty of math involved, but there's also plenty of code examples to clarify things for the less math-inclined.
It covers mainly the cell-based approach you mentioned. The other main alternative is "Smoothed Particle Hydrodynamics" or SPH. Matthias Muller has some papers about this if you're looking to get started.

If you don't care about real accuracy but just want something swooshy and cool, I developed a very simple pressure-based simulation that delivers a very fast interactive interface in Javascript. You can see it here.

Here is a pretty decent list of everything You need to know about fluid dynamics and simulation:
http://www.dgp.toronto.edu/~stam/reality/Research/pub.html
Also you should check this site, where you can find the concrete source code written in Java and transported to Actionscript3. It's pretty documented, so shouldn't be a problem to transport to Javascript.

I have tried that and just to let you know there is an important part of Fluid simulation of any kind called Projection which is computationally extensive even on CPU it takes much and you might well know that Javascript is quite slow for many reasons.