Archives for the month of: October, 2009

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

Bright and sunny

EF 50mm F1.4
Flare from 50mm F1.4

Flare from 50mm F1.4

Flare from 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.