Inventing on Principle

[Mirage]

The video is a nice demonstration of an extremely good implementation of data driven approach. Where the data is the code.
When I worked on particle effects for one of my games, the particles were driven by a script and I was able to change the behaviour in real time modifying the script within the game editor. This way I got very nice effects in very short time.
This is the reason why I think that a game engine should be built with a data-driven architecture an should have an editor with WYSIWYG capabilities.

[WILL]

Hey great proof of concept Eric!

I'm still wondering however if this can be applied to an OpenGL or DirectX environment. Mistakes, as you've mentioned in the post on your site, can happen and with an environment such as 3D/2D graphics processing could cause your system to suddenly slow to a crawl. Especially if it's an older or lower spec system.

I still like where this is going and would love to se more pick-up of the idea. Maybe a serious game engine or design tool of some kind?

[Eric]

Mistakes, as you've mentioned in the post on your site, can happen and with an environment such as 3D/2D graphics processing could cause your system to suddenly slow to a crawl. Especially if it's an older or lower spec system.

Indeed, all parts of the application you're testing have to be fault-tolerant (not to mention capable of getting restored from a known state in a quick and reliable fashion).

DirectX & OpenGL are not very tolerant indeed, if you mess up you can quickly end up in a crawl, using all memory or cause a system crash.

On the other end, this is an issue that is currently being worked on for the web-based 3D standards, because well, that's the main issue of WebGL (do a shader wrong, and the system will crawl/crash). So I guess it's only a matter of times before things evolve, there is a massive push in that direction from Apple & Google, and they arguably got a portion of 3D acceleration stable enough to be used in browser compositing (and the basic 3D stuff through CSS 3D).

The most problematic stuff is the lack in DirectX/OpenGL of constraints, such as memory limits, fill-rate limits or shader execution time limits, but that's something that could technically be introduced in drivers.

Another option could be a revival of fixed-functionality pipelines, but much richer than before, and where you would have all the common lighting and rendering techniques exposed.

That's somewhat the direction taken by CSS, and it has merit as it shoves the low-level hardware-specific complexity back in the hands of the drivers and composition engines, which is certainly more future-proof than all of the existing shader approaches (a bump mapped phong lighting will always be a bump-mapped phong lighting, rather than the optimized-for-special-cases-of-bump-mapped-phong shaders you see these days, that f.i. don't scale with an arbitrary number of lights, handle only point lights or parallel lights, etc.).

[WILL]

I was thinking that perhaps if there was a way to omit executing the potentially crashing/dangerous code and maybe highlight it in red or something until it meets up with a safe set of parameters. How restrictive those would need to be and what to restrict and what is safe could be a cause for debate.

I think in terms of OpenGL vs. DirectX some functions work well for this concept and some are more tricky to execute code in real-time. Perhaps for those tricky bits having some kind of special code block that won't execute until you close it would come in handy? This would prevent major mayhem when tweaking code that if done improperly or executed on the fly as you type would normally cause a ton of memory errors, etc...

But perhaps we are taking the Inventing on Principle concept too literally by going right down to API level...

[Eric]

How restrictive those would need to be and what to restrict and what is safe could be a cause for debate.

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.

But perhaps we are taking the Inventing on Principle concept too literally by going right down to API level...

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?"

[WILL]

Well you could write a middle-layer for graphics that kept you from messing with breakable API code. Then just stick to that layer and you won't crash during development. You'd lose some low level control, but you do gain that added feel towards the creative hands in your code real-time effect that is what you are going for. I personally think that that's the only way. Until the hardware starts putting in safeties that will prevent hurting the drivers.

[Eric]

Well you could write a middle-layer for graphics that kept you from messing with breakable API code.

Well, that's what ANGLE is trying to achieve (http://code.google.com/p/angleproject/ and http://blog.chromium.org/2010/03/int...e-project.html), but they're not quite there just yet, and they still have to exclude a variety of graphics cards and hardware drivers for stability reasons.

I don't remember if FireFox also uses ANGLE, but I've read that both Chrome & FireFox perform extra checks on the shaders to try and detect errors the HLSL compiler and drivers don't handle very well (like http://www.gamedev.net/topic/579554-...-crash-in-dx9/).

But anyway, I'm hoping the push for stable 3D graphics in web apps will ensure that stability will happen, from the hardware vendors down, ANGLE & other middle-layers will (and already) have trouble keeping up with all the new hardware and driver revisions.

Would you please share the shader code that managed to crash your PC? What operating system and API did you use?

It was definitely nVidia, and crashing with either Cg & HLSL, I don't have the code available anymore, but it might have been a similar issue to the DX9 one I linked above, ie. an error in the shader code that wasn't reported correctly.

[LP]

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?"

Would you please share the shader code that managed to crash your PC? What operating system and API did you use?