aschwo

I'm curious, on the Currying (Standard Library) slide, the author uses `attrgetter` from the `operator` module -- I've always used `getattr` to achieve the same thing. Am I missing something by not using `attrgetter`?

Having worked on node-graph UIs in the past and used software that relies on this metaphor, it's a dangerous thing to not build in undo/redo support. It's too easy to delete an edge, and spend a bunch of time trying to redo your work. That really pisses off users.

Also, not giving the edges of the graph a direction is a problem -- it's hard to quickly grasp what the 'result' node should be. Ditto for not using fixed-position plugs on the nodes: input plugs should be at the top, outputs at the bottom (or left and right).

In the end, I'm not sure who this is for: if you just want to click a button to deploy some services, it's doubtful that you'll want to muck around with wiring up nodes; and if you're putting these packages together, it'll probably be faster to just use a text editor.

This is seriously cool, but can't there be a better way to embed fragment shaders in javascript for WebGL? Check out this effect: https://github.com/brianchirls/Seriously.js/blob/develop/eff...

Or is there a tool that needs to be created that will compile a fragment shader for WebGL down to .js, kind of like CoffeeScript?

Now all you need is for someone to write an OpenEXR implementation in JS or WebKit and you'll have all you need to build a Nuke killer in the browser. Well, you'll still need the UI framework for the node graph.

This is a great development for decoding ProRes with non-OSX OSes. What are the legal implications? Will ffmpeg need to pay to license the ProRes codec from Apple? Does Apple even offer a license for the codec?

This is awesome! Are you able to implement the physically based specular term and still have acceptable performance?

You'll need the precomputed Beckmann distribution in a texture: http://developer.nvidia.com/node/171

The Foundry is absolutely kicking everyone else's ass with Nuke. They have an interesting business model as well: don't do much research in house, instead work with studios with big R&D budgets and license their tools when they're mature, bringing it to a wider audience.

They've done it with Digital Domain and Nuke (compositing), Weta and Mari (3d paint), and now Sony and Katana (lighting).

Exactly! If they had done this before killing off Shake, I bet we'd still have a half decent competitor to Nuke in the high end compositing space, instead of nothing.

Instead, Apple killed Shake and let big studios buy the source code from them so they could continue to use it.

http://en.wikipedia.org/wiki/Shake_(software)#History

I've known more than one colleague that has commuted from Portland to the Bay Area. In each case they were older men with wives and children that didn't want to (or couldn't) leave Portland. They rented small, cheap places during the week then spent the weekends at home with their families.

Ptex is awesome! Any chance Disney's hair tools will get open sourced?

Disney Animation also posts its papers online: http://www.disneyanimation.com/library/list.html

I can't find similar pages for PDI/Dreamworks or Blue Sky.

If this stuff interests you, check out the SIGGRAPH 2011 papers: http://kesen.realtimerendering.com/sig2011.html

Even when considering professional cameras, it's more about the size of the sensor than raw megapixel output:

"Bigger chips mean so many good things. Big chips mean shallower depth-of-field at equivalent settings. Big chips mean big pixels, which means more light hits each photosite. More light means less gain, less noise per pixel. Less noise means more dynamic range. Bigger chips mean better pictures."

http://prolost.blogspot.com/2008/07/panasonic-is-my-hero.htm...

http://rebelsguide.com/dl/sensorSizes_06_cheatSheet.png

Reminds me of this last.fm visualization by Lee Byron: http://megamu.com/lastfm/

A web-based interface for building and managing shaders for 3D apps and renderers. Features would include a node-based shader builder, plugins for the various 3D packages (Maya, Max, Houdini, XSI, etc), suppport for the various shading languages (RSL, VEX, mental ray, Cg, etc), and user groups and permissions. Think sourceforge for 3D artists, small studios without the ability to roll their own management solutions would like this.

Workflow is like this: user creates shader using node editor (think Maya's Hypershade, but Ajaxified...), then sets permissions for the shader. Any user with permission to use the shader can see it from the plugin for his app of choice on his machine and use it. The user sets the renderer that he wants to use, the shader is compiled on the server and sent down the pipe to the user. That way, source code is kept in the hands of the people who created it. Scene renders.

I would love to build something like this, but it requires a lot more CS knowledge than I have. So if you think it's cool, roll with it and invite me to the private beta.

21 + B.F.A. ... Would you like fries with that?