More links / Generative Art

I've blogged about generative art a while ago, and I've always followed it, since the early days as I see it somewhat as an evolution of the demoscene.

If you never saw anything about it, I'd suggest a visit to the CreativeApplication's website, or Robert Hodgin Flight404 blog.

I'm still very busy with work, photography and a bit of iPad tests (and trying to build an hackintosh...), so this will be another post full of links, but this time I want to provide an update of the best tools in this field. Some of those are also excellent for rapid prototyping of graphics solutions in general.

If you have more suggestions, please put those in the comments. I know that there are many more programming languages and tools, and I'm sure I've blogged about some of those already in various occasions, but I think I covered the best ones in this update.

- Digital Fabrication - examples

Grasshopper: a free extension for the (excellent) Rhino CAD.

Kangaroo: a physics system for Grasshopper...
Structure Synth: rule-based generative 3d shapes
Groboto: as made famous by the poster of the last Siggraph conference.
Houdini: commercial 3d DCC application, very strong in its procedural components. Free trial.
Softimage ICE: Softimage has a very powerful visual scripting language called ICE, which is extensively used to do generative art. Free trial.
Other companies in the the industrial design/architecture realm offer generative solutions. Some examples are Bentley's GenerativeComponents and ParaCould tools. This conference is pretty cool.
Realflow: commercial fluids and physics solution. A popular free alternative (that I hate due to its retarded interface) is Blender, with its physics and fluid systems.
TopMod: topological modeller, opensource

Shapeways: affordable 3d printing on a lot of different materials
RepRap, MakerBot, Fab@Home: cheap DIY 3d printers

- Procedural/Generative/Interactive Art Languages - examples

Proce55ing: from MIT aesthetic & computation group, it's a very popular java-like language, with lots of extension libraries. Very simple, I use this for prototyping a lot. There are also "ports" in other languages, one of the coolest if the Clojure one (because Clojure is ubercool).
vvvv: visual programming, you connect blocks. Graphics oriented, DX-only and fairly cool. A similar tool but newer and as of now, less popular, is Derivative's TouchDesigner. Someone more demoscenically inclined may want to use werkkzeug too, even if it's quite old now.
Field: very cool python and java mix, realtime programming environment. A bit young but I hope it will become stronger and stronger. OSX only.
Scriptographer: a scripting plugin for adobe Illustrator. It's also the software that drives Hektor, by the same author, which it fairly cool.

- Libraries

Cinder: a library developed by the excellent Barbarian group. Claims to be "professional grade". Works on iOs platforms as well. Abstracts the usual stuff, graphics, IO and so on.
openFrameworks: very similar to Cinder, very popular as well, a bit older. Also works on the various iOs platforms.
CGAL: computational geometry. Not made for generative art, but surely handy, there is also a toolbox that integrates it into scilab. Very comprehensive. Other nice ones are OpenMesh, MeshLab, VCGLib, GeometricTools and GTS.
Physic simulation libraries are also commonly used, but really the possibilities are endless.
OpenCV: the standard Computer Vision library, very popular, there are wrappers for a lot of different languages and tools.

Offline renderers are also among the tools of the trade. There are so many out there, but probably the most interesting for this trading are either the photorealistic path tracers like luxRender that have the virtue of letting you focus on the shapes you're emitting, or the programmable ones, renderman clones like Aqsis and Pixie or raytracers like SunFlow. All those that I listed are opensource too, an added virtue for the generative artist.

- Electronics - examples

I don't know too much about electronics, and if you're like me then you'll love the Arduino platform, and you'll probably need this book and a circuit simulator to play with. You'll also want to scavenge some surplus stores...

- Data banks - examples

Data visualization can be an art, can be profitable, and can even try to tell some truths. But free data access is not so common as you might think. Some useful resources are: WorldBank, Data.gov, Google Public Data, UNData, GapMinder.

Wolfram Mathematica, not only is a very nice CAS with a lisp-like language, but it also comes with access to a wealth of different data sources.

Some links...

No time to work on the blog lately. Just posting some links.

Agenda Cycling Forth - Another masterpiece by Fairlight & Carillon & Cyberiad

Every Program There Is - A 9-part exploration into computational linguistics.

OpenCL Studio - nice OpenCL IDE

Believe it or Not! Multi-core CPUs Can Match GPU Performance for FLOP-intensive Application!

Practical Examples in Data Oriented Design - again shows why the scenetree is a retarded idea, but it's more that just that

Be nice to your cache

A Dynamic Component Architecture for High Performance Gameplay

LibC++ - an alternative to libstc++

Fast and slow if statements: branch prediction in modern processors - you should already know that...

Clojure Protocols - nice insights on language design

RSA Animate Drive: the surprising truth about what motivates us - must see if you're in a leadership position

I won't post the link here, but I feel relieved that finally Intel killed Larrabee. Even if it could have been a cool toy for some kids, I think it they succeeded to put it into a gaming console (the only way in my point of view, it could have survived commercially on a consumer-level. I doubt on PC-DirectX it could have ever made much sense) it would have been for the industry only a chore, worse than what ps3 turned out to be.

Poll results

Poll: Which means of live-editing does your game/project use? Answers: 75

16%: None. 

We like to cause pain and waste money. We are too rich or too stupid or both. We live in the continuous pain of having to relaunch the game every time we change a texture or a shader. We can't solve bugs. We can't optimize performances. We're doomed.

41%: File hot-swapping. 

We can switch textures and meshes. Probably even shaders. It was relatively simple, just make sure that the file-system does all the resource creation for a given file, and that files are always accessed via handles, and not directly storing pointers to the loaded resources.

Everything works nicely, as long as you don't want to actually... code stuff. Every code change brings back the pain. Rendering engineers love working on shaders, and would kill themselves every time the have to fall back to C++ stuff. 

Can't easily navigate the scene, can't select stuff, tweak parameters, tweak materials, display debugging stuff, live-edit... Memory on the platform is limited, the game crashes after some reloads due to fragmentation.

41%: Script hot-swapping. 

Like above, but we have a scripting system, probably Lua. We can swap those files too.

29%: Tools, partially replicating game functions. (i.e. Shader editor, Animation editor etc). Tool saves the changes.

Iterations on the consoles is painful. Build times are slow. Memory is limited. Input devices are awkward. Reload times are bad. So? Well, let's build tools for faster iteration! Tools where you can edit things quickly.

In theory it's a nice idea, but instead of solving the original problem, you create a new framework that works well, but it's not the game. Still, every time you have to iterate on the game, you fall back to the ugly slow and painful workflow. Also, now you have to write everything twice, once for the tool and once in game. And you force most people to work in their tool, thus not reviewing and iteration on the final, in game, on platform result.

21%: Tool manages and serializes data, but can send RPC to live-update the game.

Same as above, but now we can see changes in game. At least for some stuff, after some time.

18%: The game/engine is embedded in a tool by static linking/DLLs. The game serializes the changes.

We're smarter than the group above. The game is a module with a small "loader" for the console and a platform specific implementation of basic system services (i.e. filesystem).  The tool is a PC environment that loads the same module (i.e. compiled as a DLL) but has a windowing and input system and adds debug functionality and reflection to the various services. The editing functionality is done via components in the editor that can access both to the tool functionalities (windowing) and to the game interfaces.

Great! But still we are not viewing and editing on the target platform. Also if we're not shipping for the PC, we have to maintain an extra platform (the game and the engine have to compile). Also, coding is still slow. C++ is still painful.

9%: Tool, using reflection/RPC/... it communicates with the game. The game serializes the changes.

Everything is done in game! Finally, few members in this group, the elite. The editor has windowing services, and a system to reflect game features, and send message to the game to change its components. 

The editor is written in a cool language, like C#, or uses scripting, or both. It's easy to create new editors. Direct manipulation, picking, editing is done by communicating the mouse input to the console, to have mouse support on the console screen. On the PC screen we display only windows with editing widgets and debugging stuff. C++ = pain.

10%: Purely in-game on-platform editing. Game can build with GUI/editing functionality built in. Game serializes.

Everything is done in game! As above, but on-platform only. On consoles, the limited memory is a big problem. C++ = pain.

9%: Code hot-swapping.

We care about ourselves too! Not only game designers and artists. We care about our work! We don't want to suffer. We are the best, fuck the rest. If you have code hot-swapping, everything else does not matter. Because now you can code fast! You can do whatever. Even code all the above in the time they will take to ship a single game. Enjoy.

Live-editing poll

You'll find the poll in the widgets on the right. Please vote!

p.s. the item descriptions are too long, they are wrapped when voting but now when visualizing the results. If you want to view the results the numbers will be hidden. I'll post the results and an analysis here, but if you want, copying the window and pasting it works...

PIX is great but...

...sometimes using colors on the screen is actually better. The trick is all in the iteration time. PIX gives you accurate numbers and step-by-step execution of a shader. But if you can easily change/compile/reload shaders and quicky arrange dedicated views on screen of some render passes, then you might actually find your bugs better, even if all you have are colors.

I just finished debugging a very nasty bug involving coordinates in different spaces and decoding of the z-buffer. I worked a lot in PIX but I managed to find the problem only when I abandoned it and started comparing the data I recovered z-buffer view with the ground truth I had from the main rendering pass.

I quickly arranged a debug view of the data I recovered from the Z-buffer, by displaying it on a corner of the screen. Then I changed the main shaders to output the data I needed. A few changes later, I fixed the problem.

That was only possible thanks to the fact that our rendering is scripted (so it's easy to add such debug-views and stuff like that) and that I can modify the shaders and they get automatically updated in game.

I guess that's not surprising to anyone that worked with scripting languages as well. Most of the times if you can live-edit your code, you end up not using the debugger but just inserting print statements to see "live" what's happening.

The next step, for shader debugging would be for me to create some more live debugging visualization stuff. At the moment I can easily just render things, it would be cool if I could place on the rendered images some "color pickers" that also display an accurate numeric reading, or that are capable of interpreting colors as normals and so on... Visual debugging is great!