This morning I attended a session on procedural content generation for Far Cry 2. Very interesting case study about what is practical, how to manage risks, etc. No talk about algorithms. One interesting point, I though, was that they did not use any procedural geometry generation for their vegetation/flora system. Their artists custom built every model, and they used procedural techniques akin to particle systems to distribute flora on the terrain, based on artist/level-editor-directed style guides. This they did deliberately to ensure a unique look, which is harder to obtain when using tools such as SpeedTree that have either procedurally-generated geometry or standardized libraries of objects.
(Has anyone out there seen the CryEngine 2 physics demo video with teapots tumbling down a San Francisco street? Its a version of the Sony Bravia "Superballs" Superbowl ad. Its out on YouTube and other places. Anyway, perhaps you get the picture, thousands of tiny teapots just tumbling around, while the people in the streets look on, half hiding behind corners, wondering what is up.)
Later in the morning, I spent an hour or so with David Meara, CEO of Havok, and Chris Keogh, a senior engineer with Havok. We talked about Havok's business model of focusing on providing what their customers look ask for and need (rather than go off in wild directions then try to sell a hammer in search of nail---so to speak), and took a look at the latest release of Havok plus the new Destruction tool. Their destruction model looks awesome, and is not based on artist-directed prefracture, e.g., fracture is done at runtime. I should have a full article on this meeting next week or so.
This afternoon, headed to the experimental gameplay session then Pete Isensee's talk on C++. Pete always has some great insights into how to optimize C++ code and avoid problems.