You are looking at a flat plane consists of 2 triangles running in the Blender 2.5 Game Engine. There is no run-time subdivision, no geometry shader, using only a minimum pass-through vertex shader, all the magic is happening in the pixel shader. The terrain is completely 3D looking, you can fly around it, view it from different angles, there is lights, shadows, bumps, shiny lakes, and even a height-based fog. Below is a video of the technique in motion:
Isn’t Relief Mapping great?
Apart from all games that will inevitably take advantage of this technique, another application I can think of that will reap huge benefit from this is the loading and displaying of large-scale terrain visualization at virtually no CPU overhead. A 4096×4096 DEM texture can be easily displayed at 60fps. Whereas if the same data were to be converted to real geometry, most computers will die trying to render those 33million triangles.
The effect is achieved by a rather complex fragment shader (pixel shader) that effectively does ray-casting on each pixel to determine the location and visibility of each pixel. The shader requires at least 2 textures. A diffuse color texture; and a normal-height texture that contains the surface normal stored in the RGB channel and the height value stored in the Alpha channel. Supplied with a miminum of these two textures, the shader is able to reconstruct the 3D surface like you saw. (I also used a specular texture to control the specularity of the lakes, but this is optional)
Some people seems to be confused about this whole Blender 2.5 version naming scheme. This roadmap (stolen directly from blender.org) should clear things up a bit.
Blender 2.5 | 2.6 roadmap
Basically, 2.5 will be a series of transitional releases, the final stable release will be named 2.6 in all likelihood.
As with any transition, there is a bit of resistance to the new interface, long-time users are complaining that they can’t find what they are looking for (like SubDiv), others wonder why features (such as radiosity) are simply removed without justification. I am an early adopter of the BLender 2.5 series and personally I am very happy with the direction Blender 2.5 is going, it’s actually a lot faster to work in the new version, since the user interface is arranged much more logically. And thanks to multithreading, being able to render, animate, and model something at the same time is amazing.
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
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.
I recently got an iPhone 3GS, the camera that’s built into the phone is a pretty big disappointment for someone who shoots dSLR for the past year. Super-noisy at base ISO 100, no manual control, shutter lag… it’s a mess. Granted, big lenses and big cameras are super cool, and they take amazing pictures. But this post is about living with, and taking advantage of the tiny camera on a camera phone.
Lesson 1: Know the limit of your camera, and try to work around it.
Small cameras are known for their low dynamic range, so to get the most out of this sunset, I took two images at different exposure and merged them together with Pro HDR, right on the phone. This increased the dynamic range dramatically, making it equal to that of a dSLR. Then a bit of contrast and saturation boost completed the look.
Lesson 2: Post Processing
This picture came out very bland at first, but a few tweaks in Lightroom 3made it marginally passable. There are enough apps in the Apple Appstore to edit your photo into oblivion and back. Some of my favorite apps are Pro HDR, TiltShiftGen and Best Camera. Of course, for the most control, you’d have to use a desktop-based tool like Lightroom or Aperture.
Lesson 3: Color
What the tiny camera lacks in light-gathering ability, it makes up by upping the vibrancy and contrast. iPhone photos are usually a lot more vibrant and contrasty than what you get out of a high-end dSLR. Use this to your advantage to capture some eye popping pictures.
Lesson 4: Bokeh
You CAN throw the background out of focus even on a tiny sensor like the iPhone camera, but only if you are shooting in macro. Just be patient with the focus, it can take a while to get the razor sharp image that you wanted.
That’s all for now, I am still discovering the capability of the iPhone camera. Let me know if you have any tips regarding digital photography.
