It's the video accompanying a paper that was presented at Siggraph 2016 last week (pity I couldn't be there... there were quite a few talks/production sessions I'd have liked to attend), describing a system they build for simulating how different types of fish swim. They also discuss how this method can be used for simulating schools of fish swimming and interacting to various forms of shaping controls (e.g. for art directing the results), including doing so interactively!
As long-time readers of this blog will know, I'm a big fan of fish (and watching tanks of them swim around), and even more so when these are animated ;) So, naturally, I do like this paper a lot!
Another big plus in my books for this paper is the fact that it's actually relatively clear and straightforward to read and understand. Even from my quick skim through the paper, it was really easy to quickly figure out what they were talking about, even when though some sections had clumps of math equations scattered throughout! In many ways, that is quite an achievement in and of itself, as far too many papers in CS have a tendency to really bask in overcomplicating the situation by making everything really damned hard to follow, and by muddying everything with "full derivations" of the math they're using (Urgh!) Maybe it's because the authors of those papers tended to be the kind of folk who "really grok" mathematics - i.e. the ones that end up double-majoring in the stuff, and really revel in pushing around tons of symbols complete with sigmas, integrals, greek, and funky repurposed notation (I'm with Erik on this one - traditional math notation needs to be put out to pasture), and yakking on and on about the elegance of their proof/derivation and how it relates to or comes from some <insert-obscure-abstract-name-here> theory. In reality though, this sort of obsession about dropping fancy names for things at every opportunity is IMO a bad habit. Better is to just be able to recognise and repurpose useful patterns, telling people in plain language what's happening.
As a recent case in point (no offense intended to the authors) of a paper that made things a lot harder than they had to be, I was reading the original Pose Space Deformations (PSD) paper a few weeks back, and it took a few re-reads to figure out what much of the methodology actually was - and this is as someone who knows the overall high level concept of what this is supposed to be doing. For example, AFAIK all that stuff about "Radial Basis Functions" is basically just talking about applying distance-based falloff curves. That is, stuff like the Proportional Editing Falloff, Brush Strength Curves, and stuff like that.
Getting back to this paper. Maybe it's just me, but when I look at the equations/math-notation in this paper, it all just seems to make sense because it feels like simulation code translated into math symbols, instead of being "native math". I know this very approach (and truth be told, prefer it) as I've done it before. Or put another way: the math in this paper isn't "scary" and "abstract" (and by extension, practically worthless from my perspective), but rather, it's written in such a way that you can easily translate it into working code. And perhaps that's my biggest reason for liking the way this paper has been written. :)
Of course, I also have to credit them with having some really nice diagrams, a clear and easy to follow concept, and having some really interesting subject matter (i.e. I love the whole 12 swimming styles thing :)
Seeing all this really makes me want to try hacking this up to play with (something I sadly can't say about many of the research papers in HCI... heck, if I'm really honest, I have to admit I have trouble finishing reading some of those). Unfortunately, I already have enough on my plate already, and adding one more project onto that list really won't help matters much :(
No comments:
Post a Comment