After watching this excellent tutorial (https://vimeo.com/40389198) I thought "what ho, this is just what I was looking for, I can make random variations in mass-produced objects!" So I started trying to reproduce the technique in a simple blendfile. I got past Step One (expose the python rand functions to the driver code); I can verify that, say, the randf function exists in driver space and does work:
>>> bpy.app.driver_namespace['randf'] <function randf at 0x11ce3f158> >>> bpy.app.driver_namespace['randf'](1.0,1.5) 1.4099068216884594
so far so good. Step Two: try to make random variations in the Intensity of a Material (BI!). I assign a Material to the good ol' Default Cube, set the Diffuse Colour, then apply a Driver to the Intensity. Everything seems to work as described; the Intensity field turns purple, and in the Graph Editor I can see that the Material now has a Driver attached for Diffuse Intensity. I set the Driver Type to be Scripted Expression, enter my randf function, turn on Show Debug...
... so I experiment some more. I find I can drive Z Scale with my randf function; so why doesn't Intensity work? Headbanging eventually reveals that I omitted one essential step, and I am not sure why it is necessary in some cases but not in others. Diffuse Intensity requires a Driver Variable whereas Z Scale does not.
My question is therefore now Why do certain object attributes require a driver variable whereas others do not, and is there a list?
UPDATE: in light of comments below I tried again from scratch. Brand new blendfile, just a cube and a camera. Screenshot:
I think it shows all the relevant details: the property field is purpled, and I accessed it through the datablocks. If I hover over the purple prop field I get a popup confirming that its value should be randf(.1,.9). The randf function is valid and produces appropriate output. There is no red highlighting indicating a driver error. Everything looks good, to the best of my knowledge.
But when I hit Update Dependencies, nothing happens. I can create a var or not, it makes no difference. Something else... what? ... is determining whether the driver is evaluated when the Update button is pressed, and that something is either broken, or misunderstood by me. I no longer believe the initial premise of this Question, which is that creating the variable made it work. Something else I did made it work... but what?
Blendfile with non-working driver:
Finally some progress:
As a sanity check, I threw a randf driver at X Scale of the cube in the above blendfile. Scale randomising works perfectly, without any var, instantly. So I believe that I've done all the setup for a driver correctly, but there is something tricky about certain properties, including (but possibly not limited to) Material properties. My question is slowly getting more focused.
I also tried getting at the Material property 2 ways through the datablock tree: via the object (Cube) and via the Materials hierarchy. The property field was correctly highlighted either way. Neither way causes Update to work.
I also tried stepping a few frames forward and back to trigger animation events (there aren't any, but I thought it might goose the Update code somehow). No dice.
I deleted the Diffuse Intensity driver, leaving the X Scale driver in place. I then re-created the DI driver. It didn't work. I then added a var for it. And guess what: now it works. So my current version of the needed incantation is this: (1) create a geometry driver. (2) create the DI driver. (3) add the var. Then it should work, even if "path to property" in the Var pane is left blank.
And here it gets interesting: If I get rid of the X Scale driver, the DI driver stops working! If I restore the X Scale driver, the DI driver starts working again. If I keep the X Scale driver, but delete the variable for the working DI driver, it stops working. If I mute the X Scale driver, the DI driver continues to work.
I therefore conclude that (at least in my version of Blender, 2.78 Steam version for OSX) to make a driver work for Material properties such as Diffuse Intensity or RGB values, one must first create a driver for some other, more "ordinary" property such as object scale. This other driver can then be muted, but not deleted, if you want the Material driver to keep working. One must also create a var for the non-geometry driver.
It is as if there is some initialisation or event handler registration or similar, which is done correctly by a geometry (or perhaps some other "good" property) driver, but not by drivers attached to some (no idea how many) other "bad" properties. It's as if the updater code is simply not aware that there are any drivers in the list to be evaluated at scene update or on button press, unless at least one "good" driver is added. But once it is aware, the list is fully populated and gets evaluated correctly. It would be truly an Herculean labour to test every possible property for goodness or badness of this kind -- so I hope someone who knows the guts of Blender will have an Aha! moment at this point, and it will get fixed in a forthcoming release.