As you probably heard by now, Blender 2.5 Alpha 0 is scheduled to be released sometime tomorrow. Meanwhile, there are already ‘unofficial’ builds popping up all over the place. My contribution towards this Blender 2.5 frenzy is a 64bit Windows Build of Blender 2.5 Alpha 0, made with Visual Studio 2008.
Introducing… a flat, boring porins protein, this is how most scientific vistualization would show it.
What’s wrong with the image? Well technically nothing, it’s scientifically accurate, each atom is color coded to represent an element, and it even rotates so that you can see the overall structure of protein. But can we do better? You bet!
Click here to see the exact same porins protein, but with a much advanced shading model, I think it’s clear why this one is superior. With ambient occlusion, in which the model is shaded based on how likely an area is occluded because of surrounding objects, the spatial structure of the protein is much easier to understand. And with today’s super fast GPUs, doing a screen-space ambient occlusion is virtually instant.
And if anyone is curious, the software I used to generate the graph is CuteMol, an
interactive, high quality molecular visualization system. QuteMol exploits the current GPU capabilites through OpenGL shaders to offers an array of innovative visual effects. QuteMol visualization techniques are aimed at improving clarity and an easier understanding of the 3D shape and structure of large molecules or complex proteins.
A while ago, I posted a simple demo I made in the Blender game engine that let’s 2 player interact with each other over the internet, all it is required is a really simple networking script and the IP address of the two players. Here is as youtube video of it in action, mouse-over the video to see some caption text.
The laptop on the left is physically separated from the desktop to the right, linked only by a wireless internet connection. And as you can see, input made to the desktop computer is sent across the network to the laptop, in realtime.
And here is the script, I’ll try to explain everything as best I can:
# Simple Python UDP networking demo Created by Mike Pan
# Todo: auto-self IP detection would be nice
# the following line loads the game module used by Python
# to access the Blender Game Engine API, and assigns it the alias G
import GameLogic as G
# load the network socket python module, we'll need it later
import socket
# define own IP address, and stores it as a property under GameLogic
# essentially making it accessible as a global variable
G.ownIP = "xxx.xxx.xxx.xxx"
# define peer IP address, stores it as a property under GameLogic
# again, essentially making it accessible as a global variable
G.peerIP = "xxx.xxx.xxx.xxx"
# define the port number (arbitrary), and the socket buffer size
# (4096 is a good starting point)
G.port = 4000
G.buffer = 4096
# create an IPV4 address with the pre-defined IP and the port number
addr = (G.peerIP, G.port)
# We'll add this line to all our communication, so when debugging,
# we won't get confused as to who send the packets.
signature = "Sent from " + G.ownIP
def init():
# create an UDP socket for **sending** datagram
G.sender = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# time out is 10ms, pretty short for realworld application,
#but enough for debugging over local network
G.sender.settimeout(0.01)
# this is important! by making this socket object a
# non-blocking operation, all network stuff is run on
# a separate thread, thus any network delay will not
# cause the game to slow down
G.sender.setblocking(0)
# creates UDP socket for **receiving** datagram
G.listener = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# same as above, time out is 10ms
G.listener.settimeout(0.01)
# same as above, we also need to make sure network operations
# will not slow down the main application
G.listener.setblocking(0)
# Win32 needs the socket binded:
try:
G.listener.bind((G.ownIP, G.port))
except:
print "Binding Listener failed"
def comm():
# get the object that is attached to this script
own = G.getCurrentController().owner
# receive from peer
try:
data, port = G.listener.recvfrom(G.buffer)
# data contains all the data that came through,
# it's a string, and we can do whatever we want
# like print it out
print data.split(',')
# if the receiving fails, print something to notify the user
except:
print "Receive failed"
# send to peer
# generate data to be sent here,
# send the position data across the network:
string = str(own.worldPosition)+ ',' + signature
# going to try to send the data
try:
G.sender.sendto(string, addr)
# if sending fails, notify with error message
except:
print "Send failed"
That’s it! To use this script, we simply need to call init() once at the start of the game, and then comm() everytime you wish to send/receive some data (perhaps every 1/30th of a second). As mentioned, here is no ’server’ involved, the two peers connect direction to each other via a UDP socket. All the user has to do is specify the two IP addresses.
Inspired by JJ Abram’s ridiculous liberal use of lens flare in Star Trek, I’ve been messing with flares on my own time. Using a basic dSLR and with various lenses at different aperture settings…
Canon EF 100mm F2 @ F22
EF 50mm F1.4
You’ll notice the shape of the flare is very different for different lenses, and also the aperture size(F-stop setting) plays a big part in defining the shape of the flare as well. In general, large f-number(F22) gives a more defined star-burst shape to the flare, while a small f-number (F1.4) gives a softer looking flare.
Anamorphic lens flares, which looks ‘cooler’ in my opinion, are harder to reproduce on a regular consumer camera because they require special anamorphic lenses.