Blender, the free and open source 3D modeling tool that’s also a real-time game engine, promises real-time visual performance possibilities, and is even a video editing tool, continues its march toward the long-promised, insanely powerful 2.5 milestone. (”Point five” doesn’t really begin to cover it.)

2.49 is now stable. And boy does it have a heck of a lot going on. There’s nodal texture editing, multiple streams of video playback in the Game Engine (making this especially appealing to visualists), 3D painting, real-time dome rendering in case you’ve got a planetarium gig, faster Game Engine performance, Bullet physics improvements for lots of physics-y goodness, real-time shape modification, and better game logic and Python control and included Python script extensions. And that’s just the start.

Blender 2.49

Basically, Blender has become a full-blown, real-time OpenGL video and graphics powerhouse inside an existing modeling tool. I’m still intrigued by dedicated game engines, but this means your modeling workflow and real-time workflow are one and the same.

And it’s capable, as a result, of some stunning visuals. The video above is from Martin Supitis, who describes it thusly on YouTube:

Few weeks of exploring the magic world of GLSL coding and few days of getting it all in this demo. Here is the result.
The thread in BlenderArtists forums that also contains download links and updates - here:
blenderartists.org/forum/showthread.php? t=152343

Made for company Twilight 22 where i take part of creating adventure action game Fire Wire District 22 as concept artist, modeler, now also learning graphic coding.

here is seen final composite of GLSL scene + SSAO, Depth of Field, Light Scattering and Chromatic Aberration filters, captured 30fps in 1680X1050 resolution; 8xAnisotropic filtering and 16xQ Antialiasing.

For live visuals, of course, modeling tools do way more than we might actually want or need. But if you can dive into Blender and find a way to simplify the work to the point you might like for a visual performance, I think it could be an immensely powerful tool.

And then there’s hardware control. Marco Rapino aka Akta has been controlling Blender with the accelerometer in his Nokia N95 phone, as in the video seen here. (Oh yes, I do need to port this to Android, especially as I already have the sensors working.)

N95 acceleremoter in Blender from aktathelegend on Vimeo.

Full details:
N95 accelerometer with Blender [ Akta's Way Blog, via BlenderNation ]

Of course, I’d like to see standardized OpenSoundControl for this sort of application. (Accordingly, OSC may soon lose the “Sound” officially in its title, given its more generalized purpose. Open Systems Control, perhaps? Open Stuff Control? Open Smurf Control?)

There’s been at least one paper on the topic of combining Blender with Pd for sound (”Blendnik”):
http://porcaro.org/blendnik.html

I’m not sure of the preferred way to implement OSC inside Python inside Blender, but I’ll have to give this a try myself.

A huge thanks to Giorgio Martini aka Tweaking Knobs for these links. Giorgio is working on his own live project. Here’s a glimpse of what that looks like, in progress:

Untitled from TweakingKnobs on Vimeo.

You can go grab Blender for basically any operating system you can imagine.

Shamus Young’s “Pixel City” feels like flying in a helicopter into the art from Ghost in the Shell, or discovering a metropolis inside your computer. The latest work from an undiscovered YouTube talent, the software itself will be released under an open source license. I don’t need to tell you this could inspire other experiments for urbanist visualists wanting to work with real-time landscapes.

It’s also interesting that the process itself becomes part of the artwork: it’s by understanding how each element is pieced together that you really connect to the meaning of the whole.

This is a demonstration of a program I wrote to generate and fly through a dynamically generated city. You can read the step-by-step of how it was made at my website:

http://www.shamusyoung.com/twentysidedtale/?p=2940

• The program was built on vanilla OpenGL, Windows, using MS DevStudio 6.0
• Building the city takes about 5 seconds.
• Took about 50 hours of coding time.
• Runs on older hardware. The goal was to have the program work on Windows machines less than 5 years old.
• To be released as a Windows screensaver.

The music is "Around" by Oursvince, used under the Creative Commons:
http://www.vincentbernay.com/

The link on his website also discusses other reflections on digital cityscapes, so well worth reading.

Wish granted!

Think 3D in the browser will never catch on? Think again. The folks at Google Labs have built an incredible-looking 3D API called O3D. It does just about everything you want, and then some:

• It’s multi-platform: Mac + Windows + Linux.
• It can render to both OpenGL and DirectX render pipelines.
• You can write your own vertex and pixel shaders. You have to use O3D’s own language for doing this, but that actually enhances compatibility, as frustrated shader coders may already know. (See the FAQ)
• It’s a scene graph, so managing complex 3D scenes isn’t a chore.
• It has powerful built-in functions like viewports and pickers (plus custom pickers), so you can actually get something up and running in a reasonable time.
• It has an import workflow with COLLADA, an open standard for 3D assets (and which, incidentally, has support in Google’s own SketchUp).
• You code in JavaScript, using the powerful V8 engine (developed for Chrome).
• Gears lets you run offline.

In case Quake creator John Carmack wasn’t already your hero, here’s a nice move: when EA wouldn’t green-light an iPhone version of the classic first-person shooter Wolfenstein 3D, Carnack had an answer: fine, just let me do it myself.

In an astonishingly open (though typically Carmackian) post on the subject, one of the world’s great game programmers weighs in on some important issues:

• How open source game code made the project more feasible – and allows an entire community to get in on the action
• How the innards of the iPhone compare as a mobile platform (the DS compares more favorably than you might think, but at the end of the day, it’s more about developers properly taking advantage of the device)
• How the architecture of the game had to be modified to work properly

If you have a passing interest in games or mobile, but especially if you’re getting into OpenGL programming, the article is a must-read. And, in fact, I think it illustrates that focusing on simpler game engines can be a great way to learn about development – the concepts are basic enough that even someone starting out with 3D could pick something up here.

Wolfenstein 3D: iPhone Development

There’s some real history here: Carmack gave us Wolfeinstein 3D, Wolfenstein gave us the first-person shooter, the first-person shooter drove the demand for real-time 3D on game cards, and now we’re using the whole thing to make live visuals as well as games. (And quite a few visualists I know go and hunt zombies in their spare time, thus keeping us sane to write more code / make more visuals…)

Add Max patch effects to DNA. from Livid Instruments on Vimeo.

Yesterday, we saw some splashy video distortion techniques applied to real-time video. You know what that means: it’s time to use these in live performance.

Liquidify Video, Live: Optical Flow GLSL Datamosh Technique

Here’s one start.Peter Nyboer, Max whiz and Livid developer, has run with the idea of squishing around video using optical flow analysis, and shows you how to add the effect to Livid’s Cell DNA VJ app. For Jitter users, this means you can rely on Cell for quick access to video taps and files, while adding unusual effects built in Jitter to get your custom processing on, not only with this example but any other patches you’ve created. One little detail of Cell DNA I missed – it requires Max 4 patches, not Max 5 patches. Peter has also posted a tutorial for working with that, after the jump.

And yes, if none of this is really making sense to you, you can go download the files and just try it out – no need to fully grasp all of the internals straight away.

Don’t want to use Jitter and/or Cell? The guts of Andrew Benson’s video datasplooshing technique is an OpenGL (GLSL) shader, so it doesn’t even rely on Jitter – Jitter can just be a convenient environment for playing around with such things. There’s word we may see a Quartz Composer wrapper around this shader, which would make it easy to use with software like VDMX.

Oh, by the way, I’m officially rescinding my editorial ban on the term “datamoshing.” Why? Because it means absolutely nothing, and therefore can be declared reasonably harmless. Also, unlike the term “glitch,” it comes without any baggage. We therefore have a nice, nonsense term for making video all mushy and unpredictable – a good thing.