This is a great find! Also worth checking out what he says later at 28:00:
This relates in a bit to what I was describing with artists' turnaround time. If I didn't have the sliders and all I could do was change shader logic in order to see changes made to the shader then it takes about a minute to turn that around. If I have a very short shader it might compile in a span of a few seconds but even if the shader compiles in a few seconds the number of varieties of that shader that I can see is constrained by that shader compiler time. With the slider, I can see hundreds of variations of the shader. Particularly if I change the sampling patterns, I don't have to guess what happens if I drop the number of samples to zero, I see what happens here. And I can see maybe how many samples it is before the shadow is satisfactory, and how many samples I need when the shadow is much more accurate. And so I can also extract those values and maybe use them as different graphical presets. All those things become possible now and I can explore them very quickly by having those variables that are predefined and mapping them into something that I can change in real time.
He continues with a point that could serve as a metaphor for the value of improving the scientific research process:
We have so much computational power now that we could put all of that just into making the game prettier. But you get diminishing returns on that, and if you think about spending 20% of the performance horsepower of the machine you're running the game on on making it more real time and having more hooks in with the tools that might be difficult to optimize, but if they're in the game during its development and it increases an artist workflow from several minutes into several seconds. That's a couple orders of magnitude of faster workflow to an artist. So it's well worth spending the 20% performance hit that you might get from that. You might sacrifice your polygon count or some of the extra complexity of the shaders. If you put that into the tools instead, you're gonna get a drastically better game.
I've also been thinking about diversifying our input controls. A few months ago, I picked up some arduino-ready slide potentiometers (~$2.50 each) to get a feel for them.
It might be a fun exercise to build a recognizer to estimate the slider position via the camera, and compare that to the electronic output.
I love the idea of a standard-issue midi controller to accompany the keyboard and knob-dials.
There's a whole universe of commercial controllers available, many of them are surprisingly expensive.
For example, the Midimaker lineup has a simple, clean design but you're looking at $100–$175 each.
Several crowdfunded controller systems have nifty submodules that snap together magnetically:
To get wireless connectivity for devices with actual midi connectors, we might use midi-to-bluetooth adapters. For controllers with usb output, we might find or build little battery-powered wireless usb hubs. I haven't found any ideal product, but maybe something like this. We may want these anyway for other input devices, such as joysticks or giant knobs. (If we're building, I vote to use 2.4ghz rf receivers like our keyboards; pairing bluetooth devices often makes me question my sanity). Finally, I recall Omar experimented with RaspberryPis as dedicated USB-to-wifi adapters — maybe pi zero gum pack-sized hubs could work.