Well the other risk is that if you end up having to manually qualify and safeguard what is risky & what isn't, you could just as well end up spending more time doing that than designing, or end up with design tools that are too restrictive/specific to be more useful than a "classic" IDE or game level editor...
I'm thinking that this approach can only blossom if all the hard, low-level aspects are taken care of already.
I'm not sure: if you're using this approach to design a shader f.i., you'll have a few sample scenes ready, and will want to preview/tweak the shader interactively.
At that point, either you're only tweaking the shader parameters (and doing no better than what already exists), or you're editing the shader code itself, and seeing the results interactively, but that assumes your hardware can handle buggy shaders without crashing or locking up.
Even without interactivity, there is nothing more annoying when you're trying to tweak a shader than having the driver fold up and having to reboot. That has happened to me for all 3D APIs at some point or another, and it's not just frustrating from a design POV, it's also frustrating from a deployment POV, because it makes you wonder "ok, if this shader can crash my PC, what will it do on users machines with their outdated drivers?"
Bookmarks