For random fun, here's a little one-day-only (Halloween) splash screen that I had made for a Rift internal build back in 2009 -- before it was called Rift. Ironically, it ended up that there was no build that day! So it was never used.

As " Senior Technical Artist" on Rift, my tasks often involved the creation of specialized tool software; helping non-technical people within the art dept (usually) solve specific problems; interfacing between the art, management, and engineering groups... But the part of my job that’s been most-visible to game players is shading.

The funny thing is that while shading is visible everywhere -- every pixel you see is a shaded one -- shading is a hidden art, like photographic lighting. It rarely has much of a narrative representational thrust of its own. You can make a drawing without shading, just as you can make a photo without any effort or thought about lighting. Yet you'll be hard pressed to find an un-shaded painting (or drawing) in a gallery or museum, just as you'll rarely see photos without very deliberate lighting in those venues, or in portrait or advertising studios; or especially in films, where the creators of those media have long learned and understood the value of careful control over tone, grading, and color. Not just on one costume or in one shot, but across the whole of their dramatic/artistic enterprise.

In computer image creation, shading -- the assignment of colors to pixels at all levels of detail -- is usually accomplished by the use of micro-programs called "shaders." In the case of Rift, I wrote nearly every shader, re-wrote those I didn't initially create, or created the shader-writing software that generated the shaders.

The exact meaning of "shader" can be a bit squirrelly for some. Engineers may prefer to call them "streaming processor functions" because they may not be "shading" visible images at all (see Mark Harris's excellent GPGPU.org for some counter-examples). Most of the time, artists use the term "shader" and "material" interchangeably. The difference between a identically-colored materials that look like chalk, or ice, or plastic, or metal, or glowing ooze? The shader.

Shaders and interactions between shaders are also used to create lighting effects, glows, glints, shadows, depth buffers, and more. We'll talk about them as they come along in this series.

In the case of Rift, shaders for materials (and other purposes) not only had to look great for the best, high-end computers, they also had to be "heterofunctional": they needed to work on a wide variety of different PC's and in different environments. Some players had top-drawer computers with high-dollar GPU cards, while others had rather modest hand-me-down laptops. It was important to provide the best experience possible -- both pictorially and in terms of playable frame rate -- for all of these many thousands of players, across literally hundreds of material variations.

To complicate matters further, nearly all material shaders needed to have working analogues that run not only in the game as shipped, but also in our art-creation tools. This meant that each material needed its own OpenGL CgFX versions for use in Maya, custom preview modes for model building and animation, special DirectX versions for use in our modified Gamebryo 2.6 toolchain, some experiments with WebGL and Unity, and of course the various editions for player consumption at varying degrees of performance (at least two, sometimes up to five different versions).

As usual, the way to manage vast complexity is to bite off a little at a time and revise/polish as you go. I used to say (to steal a bit of a metaphor from.. Paul Graham? Not sure at this point, but we all steal from the best) that we started by jumping off a cliff and I built an airplane on the way down.

Four years ago I departed a good job at NVIDIA to join a start-up games company called Trion World Network -- Trion’s plan was to revolutionize online gaming in the US, and their stated goals were ones that I also shared: to create a new, innovative, more-immersive and immediate online-gaming experience.

I really believe that graphics matter. That great art is more than just simulating realism, and that it goes right to your emotions without waiting for rational analysis. That it’s those emotions that bring you back again and again to entertaining experiences, more than DPS and EXP and leveling-up to get the next BFG. Those are just background. Beautiful, vivid imagery -- even a beautiful image of an ugly subject -- goes right to the heart of an audience’s mind.

Among games, online ones had to that point been rather poor cousins in the graphics and art departments, with titles like Farmville and World of Warcraft. I’d had conversations with developers of other online games who declared “we don’t want to do anything more than Blizzard is doing” -- instead of seeing a future of ubiquitously-cheaper and more powerful machines for entertainment, they could only see that WoW had millions of subscribers & thought the only way to proceed was via a zero-sum  “WWWD?” -- “What Would WoW Do?” -- mindset.

Given the fact that game development cycles are now often longer than hardware-deployment cycles (a next generation of hardware may appear every year or so, while games to use that hardware take much longer), this vision gap was increasingly obvious. The future was being held back by a desire to simply repeat the successes of the past.

From my evangelist/consulting role at NVIDIA, it seemed like the shortest route to really show people what a beautiful online game experience might be like was not to advise the established developers, but to lead by doing: to simply go and create the future myself. And so I jumped, just hours before the stock market crash of 2008 got fully underway.

Two and a half years later, Rift: Planes of Telara opened to rave reviews; reviews that nearly always began with accolades about how great the game looked (Ten Ton Hammer: Graphics 95, “outstanding”; The Escapist: “One area where Rift definitely delivers is the graphics”; IGN: “an undeniably gorgeous game”; etc).

We continued to ramp it up for future revisions: so much so that previewers of  the first expansion set, Rift: Storm Legion, expressed their excitement about the “new renderer” (there was no new renderer, but I’d upgraded nearly all of the lighting and atmospherics code). When the expansion was released it received similar critical praise, such as this review from Gaming Trend: “[Storm Legion has] the best looking things in gaming, period, right now.”

Quest Completed! You are dead.

However, the executives at Trion had a very different view. In December 2012, just a very few weeks after the release of Storm Legion, despite the superlative reception, they laid off a big chunk (most?) of the remaining Rift-focused art team: forty people including myself. If I were to speculate, the company seems to be backing away from “Triple-A” content focus and moving toward licensing deals with other production companies along with a focus on smaller, faster-iterating projects. Less “vision of the future of entertainment” and more same-ol’ game publishing. That’s just speculation on my part, but they’ve certainly reduced their ability to create top-shelf experiences like Rift in the short term future. Speculation.

While I’m not happy with the choices of management, I hope Rift continues to find an audience -- the whole point was to make something worth showing and sharing, a better gaming experience than what had been offered by anyone before. The effort means nothing if no one gets to experience the world we’ve created.

I’ve also decided to write a series here on some of the challenges and solutions in my process of collaboratively creating and tweaking the artwork and graphics for the game. While most of the art department has already been publicizing their work, as in this Polycount Art Dump, we were specifically forbidden from revealing “technical details.” Which means that if your work is nearly all technical details, well... you’re not allowed to talk about your work! Now I can. Watch this space.

Last night I headed over to the Paypal/EBay offices to see a presentation by Douglas Crockford, titled Programming Styles and Your Brain

I'll admit that I was a little bit skeptical about coming away with much useful information (a general rule: be cautious around tech companies that have had near-zero evolution since, oh, 1995), but in fact the debugging bits were pretty illuminating. Here are some sketchy notes:

Your Brain

Crockford’s lecture had about five introductory minutes of broad speculation (he's earned the right!) mixed with notes cribbed from Daniel Kahneman…

• Computer programs are the most complicated things humans make
• Humans suck at making such things
• They make mistakes
• They confuse “hardly ever happens” with “never happens”
• They confuse reading two threads on a jquery forum with an education
• They write in C++ when the language is not C++ (or Java, HLSL, python, Mel, Fortran…)
• They mistake complex obscurantist “cool” with professional “clear” coding
• The human is almost always the limiting factor in software
• Being consistent in style is the easiest way to avoid common errors (especially forms that are difficult to distinguish rom errors, which in JS are many)
• Anyone can program, few can debug

JavaScript

This was the expected real bulk of the presentation, a longer not-veiled pitch for JSLint and his book “Javascript: the Good Parts” -- especially about how to avoid the bad parts:

• Auto-semicolon closure. This burns people so, so, much, and is one reason where it really does make a difference (for polyglot programmers) to get in the habit of putting the curly open-brace to the right of the if() clause on the same line, rather than on the line below – just like K&R intended.
• Stupid multi-line strings that use “\” at line breaks because the parsers don’t recognize trailing spaces and the editors don’t show them.
• Mistaking the scope of “var” to be block scope (like C, python, etc) – it’s function scope, so avoid declaration-inside-the-block constructions like for (var i=0;…) { … } because it won’t get declared where you think it is. I know I make this error a fair bit.
• Make global variables REALLY_OBVIOUS. Since there are no macros in JS, THIS_IN_ONE_WAY (clearer than, say, Hungarian). In general avoid globals, except that you can’t because that’s how modules link (no linker).
• If using immediate-invocation functions, put the final () inside the encapsulating () parens – e.g. (function() {…}()); not (function() { })(); – the latter wrong construction he called “dangling dog balls style.”
• Avoid “==” because it does type conversion and different interpreters convert differently! Is (‘’==0) true or false? Use “===” instead, for a direct comparison.
• Avoid the “switch” statement or at least be obsessively diligent about having break statement in every clause -- and having a default case.
• Avoid the “with” construct. Consider: with (o) { foo=koda; }
  does it mean:
  • foo=koda;
  • o.foo = koda;
  • foo = o.koda;
  • o.foo = o.koda;
  ??? Different interpreters DO give different results!
• var a = b = 0; in JS is the same as /*global */ b = 0; /*local */ var a = b; -- NOT like C.
• Not only are “var” declarations hoisted to the top of the function scope, so are function declarations. So beware dependencies that are not resolved! NO ERROR WILL PRINT. Better to just put the var and function declarations at the top of the enclosing function
• Avoid the “new” pseudo-class construct, not because it doesn’t work but because people often forget to write “new” and then they may accidentally trash that global class-like definition and you are hosed. Just use simple {objects}
• If you have constructor functions indicate them “LikeThis()” to distinguish them from “all_other_functions()”
• Avoid “++” which is a leftover from pointer arithmetic days. Just use “+=1” it’s just one more character to type, using “++” doesn’t make you more efficient, it makes you sloppy (especially when few people remember that i+=1; is not i++ -- it’s ++i;)

The Bad Parts?

So how does the Javascript on Botzilla stack up? Let's just say, it's an ongoing learning process!

In scanning the scripts here (and at Trion), there appear to really only be a couple of idoms that I need to stamp out from my code to make the analyzer happy. What's yet to be determined is if Javascript's scoping rules will ever really make sense...

Bike Friday Pocket Rocket + Burley Travoy + Samsonite

By that, I mean that if the site needs to work on all possible screen sizes, for future-friendly leanings, then: the pictures are just going to have to be small. And there's the rub for a photo site -- when the pictures are reduced to being upgraded versions of the thumbnails, not the other way 'round. This is tough, and frankly I won't give up without a fight for getting the best possible photographic presentation into place.

At the moment, I'm getting cozy with this little bit of CSS:

img { max-width: 100%; }

Which is a trick to ensure that images are resized downwards as their containers shrink.

The obstacle on a site like Botzilla is that most photo <IMG> tags have both WIDTH and HEIGHT properties specified, so that when displayed on a small screen, "max-width" alone doesn't get you very far -- the images don't scale uniformly down, but instead simply compress horizontally, untill they're long tall sticks.

JQuery to the Rescue!

Including this as the first line in my ready() function does the trick:

$("img").removeAttr("height");

That Isaac's choice of university is also near one of the best skate parks.

Hard to look at B&W photos these days without suspecting the hand of Nik Software behind the curtain.

And I like their "version" of the interactivity -- ONLY let the mouse have an effect when moving. Will have to check that out on a tablet.... of course, when they're creating a brand presence for a company with.. what, 30,000 employees? you would only expect that they'd take a little more time on polishing than my slice-of-a-Saturday attempt. Pat on the back, lads.

While not posting for a few days, I've been scraping at Botzilla's underlying CSS structure, so that I can rebuild it once more with CSS that will allow a fairly seamless multi-screen experience -- PC web or mobile phone/tablet. This has meant I've already had to update (internally) my use of jquery to use jquery-mobile, have started playing with Modernizr for those stodgy users who insist on running IE, and trying to make peace with myself over the idea that photos that I felt barely look okay 800+ pixels across will just have to be acceptable at mobile-phone sizes.

More to come as this gels.

One more for a Saturday -- see if you can push all the balls off-screen at once! (and no, it won't try to sell you car insurance)

Everything here, on the JS side, is set up using a shared array of initializer functions, just like the previous entry on that topic.

Next step might be to re-cast it as SVG... amazing that SVG seems really powerful, but compared to <canvas>, theres' almost no really good documentation...

Press for a larger view

The state publishes a PDF containing the 2012 California Dept of Transportation Bicycle-Related Roadway Standards. It contained, across several pages, all of the current standards for bicycle-related signage (and much more). I've collected the signs together here for easier web reference (fabric patterns, anyone?).

Note that the vague legacy "Share the Road" sign seems to be fading out, to be replaced by the much clearer "MAY USE FULL LANE." About time!

Following up on the previous post, here are the details on a simple way to add multiple dynamic scripts to a Moveable Type index page.

Like the previous post, try using your mouse on this one! Can you slow down the particles?

Basically, we just need to add an (initially empty) array of function references to the page templates, which we'll use to capture each blog entry's unique scripts (rather than letting them launch themselves), and then iterate on that array for the entire page, once it's loaded and ready.

I'm using jquery, so I declare the array and my $(document).ready() function like so:

var gRActions = new Array(); // initially empty array of functions...

$(document).ready(function() {
  for (var a=0; a<gRActions.length; a++) {
	gRActions[a]();
  }
});

Then in each blog entry, I write the same anonymous javascript function as I might write for $(document).ready(), but instead I just push it into gRActions:

gRActions.push(function() {
   draw_canv739();
   setInterval(draw_canv739,30);
});

Now the page, regardless of how many blog entries it might contain, will include all of them in its page initialization. Remember also to make sure that any "global" javascript values (including function names!) in this entry, and all HTML elements like <canvas>, have unique names so that they won't collide with other blog entries, should they for some reason both be presented on the same HTML index page someday.

Also, as we've learned from the previous post: put some human-readbale text into the post before the scripting portion of the post, otherwise Facebook becomes confused.