Archives for posts with tag: blender

I have been writing a lot of Python codes lately, and have since grown increasingly fond of the language over its minimalist approach to programming.  For the newcomers here: Python is what Blender uses for its scripting interface, with Python linked to the Blender API, one can access and modify almost anything programmatically.  This scripting interface significantly extends what is possible with Blender.  Although to call Python a scripting language is perhaps a disservice to this supremely capable and elegant language.  Python’s simplicity means it can be used as a scripting language, but it also has the power to do so much more.

Around the Blender community, I have seen some people approach Python with certain skepticism.  (“It’s programming, it must be hard!”)  But Python is intuitive.  Writing Python code is the closest one can get to writing in an natural language.  Compare with other languages, there is no semicolons, no excessive symbols and punctuations, no long compilation process before one can test the code.  To make a program in Python is a think-type-run process.

Blender 2.49 Scripting

Perhaps due to my recently found enthusiasm, I was given a chance to take a sneak peak at Michel Anders’ upcoming book Blender 2.49 scripting.  Flipping through this ~300 page book, I realized this is exactly what I would have asked for as a beginner wanting to learn how to script in Blender.  This wonderfully comprehensive book covers everything from editing object to working with material to PyDrivers, Constraints, IPOs and shapekeys.  The only notable omission seems to be the game engine component.

Sure you can look at the Blender API documentation for help, but ingredient lists does not make a cookbook.  As there still isn’t a centralized repository for Blender scripts in the Blender community,Michel managed to bridge a rather large knowledge gap with this book that is filled with useful snippet of code.

Python is not as fast as C, or as ubiquitous as Javascript.  But one can accomplish a task in Python at a fraction of the code and mental power it takes in other languages.  Which makes it an ideal language to learn as a beginner.

Blender 2.49 Scripting is available from Packt Publishing.  I eagerly awaits a second edition of the book, no doubt slewed for Blender 2.5 and Python 3?

A long time ago I toyed with the idea of making an entire game by myself. Being a driving game, I spent a long time with the basics stuff like vehicle physics to make sure the driving part is stable, bug-free, and most importantly, fun.

I never finished it. But ever since I posted the above video, I have been getting a lot of inquiries as to how I did the vehicle physics system in Blender. So here is a quick guide followed by the sample file.

The key to stable driving dynamics is to use the built-in PhysicsConstraints module within Blender’s game engine. PhysicsConstraints is a python wrapper for the Bullet physics engine. No any homemade setup I’ve seen is as good as what’s already provided by Bullet Physics. So we’ll use that.  Because there isn’t a graphical interface for setting up the vehicle physics yet in Blender, we need to write a few lines of Python script.  The key component is the car body object, which is linked to the 4 wheels through a logic brick connection so that the script would recognize the linked objects as wheels. (As you can see, all the actual driving logic is all happening on the car body, the wheels have no real logic brick attached).

The entire setup is a bit complex, since there is a mix of logic brick and python. Take a look at the sample file if you are lost.  When one runs the game, the following happens:

0. World is initialized, but we don’t really care about that here.

1. The car body is initalized, scripts.carInit() is ran. In this script, it initializes the car as a “vehicle constraint”, aka constraint type11, and stores it as a Python object called vehicle.  The same script then looks for the 4 wheel by access a gamelogic actuator with specific names (in this case, wheel1, wheel3, etc), then the script attaches the wheels to the car body using the settings specified in the script. Variables such as RollInfluence, SuspensionStiffness, and TyreFriction can all be set on a per-tire basis once the vehicle object is created. The job of carInit() is now done.  Our car body is now considered to be a vehicle by the Blender game engine, and it will behave like one.

2. Every frame, scripts.carHandler() is ran. This script does the actual moving of the car, it applies engine force and steering to the vehicle object. But this script gets the user input (keyboard sensor inputs) from another source. (See #3 below)   Vehicle objects have methods such as applyBreaking(), applyEngineForce(), getWheelRotation(), getNumWheels, which you can all call.

3. Every time a key is pressed, script.keyHandler() is ran. It figures out which key is pressed and set the intermediate variable so that #2 (i.e. scripts.carHandler) would know how much throttle to apply, where to steer, etc.  This script is separated from scripts.carHandler() not because of technical limitations, but by design so that it’s easier to manage the code.

That’s all there is to it.  If the script layout is a bit confusing, it’s because it is.  I originally intended it to be a bigger project, thus everything is separated into nice neat functions.  Again, you can DOWNLOAD the whole setup for Blender 2.5 from here.

Controls:
Arrow Keys to move the car
Space bar for handbrake
R to reset car if it flips over
number row 1,2,3,4,5 to change camera

Hope that helped.

A while ago, I was invited to give a short talk at a small gathering of CG professionals in my hometown Vancouver, Canada. My 20-minutes presentation is suppose to be a show-and-tell that gives people an overview of Blender, a software that almost everyone in the room has heard of, but has no real experiences with. Most people downloaded it and ran it at one point, but admitted that they didn’t invest too much time on learning it.

As some of you might know, Vancouver is a pretty major hub for media and film production. It’s home to Electronic Arts, Ubisoft, Rainmaker, a whole slew of movie and TV VFX studios, and more recently, Pixar. The ~30 attendees all had very strong industry background, except me. (To my disappointment, no attendee has worked at Emeryville) But more importantly, it was apparent that they all consider Blender to be immature, with limited features, and see it as a toy more than a production-ready tool.

Blender: Just a toy

To be fair, this view on Blender is not surprising to me. But I was surprised by the overwhelming positive response after the talk, people were impressed with what Blender can do, they did not seem to expect a free software to be able to do so much, so fast. I demoed with a pre-release Blender 2.5, showcasing sculpting, compositing, rendering, the game engine, as well as some of my previous work. People were positively surprised to see what Blender can do, and few perhaps would even start to see Blender as an alternative to Autodesk’s offerings. Of course, no one in their right mind would change the production pipeline overnight from Maya/Max to Blender, but establishing Blender as more than a toy in the industry is good enough for now.

oooooooooo

What I realized from this presentation, and the point of this post, is that if we want to get more people to use try out Blender, we need to show them what it can do. Listing features, talking about code refactoring, or focusing on the open source advantages, is not going to sell the product. We need to inspire. Let’s show people what Blender is capable of through artwork and video demostrations.

Show. Don’t tell.

Wow, a project I actually finished!

Since I started working on this car project, I’ve been getting a lot of positive feedback which really helped me move the project forward. It’s only fair that I return the favor and share a bit of what I learned here. (The full scene file including model, lighting, material and texture is available at my site)

The entire scene is rendered with the internal renderer in Blender 2.5.  As an artist, I want precise control over each elements of the scene, and the internal renderer allows me to iterate through test renders extremely rapidly to get the look I wanted. A photon-tracer like LuxRender would be too slow for me, with little extra return in image quality in my opinion.

Supposedly, like eyes to a human, car headlights defines the character of a car.  There is really no shortcut to making a sparkly looking headlight, I just modeled everything as geometry and applied a lot of reflection/refraction to the material.  As long as the geometry is there, all the cool effects happen automatically once you hit render.  i also placed a lamp at where the light should be, to throw in a bit of extra lumen.


A lot of that ‘cinematic’ look is due to post-production color correction.  Here you can see my postprocessing nodes setup.

For the animation, I rendered out the entire video at 1280×720, as PNGs.  Because PNG is only 24bit, extra dynamic range is lost, which made all the post-processing and cross-fading look half-assed.  Next time I’ll definitely render to floating-point EXR formats, which should help when I start applying more aggressive processings.  I also realized that a single computer is NEVER fast enough;  The 40 second clip would have taken 83 days to render on a single core, but with the help of 24 cores spanning across 4 PCs, I managed to push out the video in less than 4 days.  Dropbox made file synchronization embarrassingly simple.

A lot of the technical issues with the video (bad driving dynamics; black pixels; flickering) only cropped up last minute in the final rendering, at which point I am just too annoyed to re-render it.  So hopefully I’ll fix these distractions later and release a better version soon.

That’s it for now.  Hope you like what I have so far.