pyppet project

Progressive Baking

2012-02-01T19:22:00.000-08:00

Texture maps are progressively downloaded from the Blender integrated server. Baking happens on demand and is fully automated. Client side javascript code adapts the texture request to best fit the given shader. Supported texture layers: diffuse, AO, specular intensity and displacement.

Hardware Displacement Mapping

The base mesh (without subdivision) is sent to the client. The client then applies subdivision and recalculates the tangents. The displacement map is progressively downloaded starting at 64x64 and stopping at 512x512 resolution. The displacement happens in hardware using GLSL shader model 3.0. Code recycled from the Three.js examples.

Pyppet - WebGL Streaming

2012-01-24T02:46:00.000-08:00

This blog post was supposed to be about streaming data from Blender into the Unity Flash-based web-client. I gave Unity a try under Wine-1.2.2 only to find that Unity is not fully compatible with Wine, making it unusable. Why are the Unity developers not testing their software with Wine, or doing the smart thing and offering native builds for Linux? The case was closed on Unity when I read that Adobe is in fact stupid enough to not support hardware 3D in the new Flash player on Linux. Bad move Unity!

Moving on, I gave GLGE a try, but quickly gave up, becoming disappointed by the API and not easily finding a way to dynamically set bone transforms and vertex positions. For a split micro-second I thought maybe I should install MS Windows and give Unity another try. Then I remembered another WebGL engine called Three.js.

Just going through the examples of Three.js should blow you away, the API is so simple yet so powerful, and the library is a tiny 380KB. No wonder the Three.js community is so active.

Streaming

For streaming the data the only real option is Websockets, and the best Python3 library for Websockets I could find is Websockify by Joel Martin. I was a bit confused at first by the code in Websockify, because it includes some extra scripts for running TCP proxies and rebinding ports (written in C). However, the only file required from Websockify is "websocket.py" which is pure python and requires no compiled modules. To get Websockify working inside Blender I only had to overload the start_server method not to use Multiprocessing.

Mission1 - Support Blender Modifiers

Three.js supports skeleton and vertex morph animation; and while this is great, it sucks not having Blender's mesh deform modifiers like: Cast, Curve, Displace, Hook, Lattice, MeshDeform, ShrinkWrap, SimpleDeform, Smooth, Warp, and Wave. These modifiers are highly useful for animation, and not easy to reproduce with only bones.

A workaround for not having these modifiers client-side, is to stream mesh data from Blender using Websockets into Three.js and dynamically update the WebGL mesh at 30fps. To make the streaming optimal only the base mesh (subdivision level 0) is streamed, and then on the client side the Catmull-Clark subdivision surface is regenerated each frame. The vertex positions are also rounded up to 3, cutting the byte stream almost in half. The result is that in order to stream the default monkey head (500 vertices) to the web-client creates a load of 350KB per second. This is still using ASCII Json for transport, so hopefully in the future a binary stream or other packing method could cut this down even more.

Pyppet2 - Audio Analysis

2012-01-05T20:29:00.000-08:00

Prototype for real-time musical performance at live events, concerts. TODO: OSC integration to support pro music hardware, sample mixer integrated with physics system (collisions trigger sounds), particles, multiple full screen windows and camera switching driver input.

Blenderartists thread

pyppet 1.9.3b source code

Update

linux install guide

feature requests approved:

"assign multiple movement and rotation controls to one OSC input"

"adjust scale, and attack/release function" (callbacks)

Pyppet2 - Biped Solver - Part2

2012-01-05T02:23:00.000-08:00


 def update(self, context):
  AbstractArmature.update(self,context)

  step_left = step_right = False

  if not self.left_foot_loc:
   self.left_foot_loc = self.left_foot.shadow_parent.location
   step_left = True
  if not self.right_foot_loc:
   self.right_foot_loc = self.right_foot.shadow_parent.location
   step_right = True

  x,y,z = self.chest.get_velocity_local()

  sideways = None
  sideways_rate = abs( x )
  if x < -2: sideways = 'RIGHT'
  elif x > 2: sideways = 'LEFT'

  moving = None
  motion_rate = abs( y )
  if y < -0.5: moving = 'FORWARD'
  elif y > 0.5: moving = 'BACKWARD'

  loc,rot,scl = self.pelvis.shadow.matrix_world.decompose()
  euler = rot.to_euler()
  tilt = sum( [abs(math.degrees(euler.x)), abs(math.degrees(euler.y))] ) / 2.0  # 0-45


  x,y,z = self.pelvis.get_location()
  current_pelvis_height = z
  falling = current_pelvis_height < self.pelvis.rest_height * (1.0-self.standing_height_threshold)

  hx,hy,hz = self.head.get_location()
  x = (x+hx)/2.0
  y = (y+hy)/2.0
  ob = self.pelvis.shadow
  ob.location = (x,y,-0.5)
  loc,rot,scale = ob.matrix_world.decompose()
  euler = rot.to_euler()

  heading = math.degrees( euler.z )
  spin = self.prev_heading - heading
  self.prev_heading = heading
  turning = None
  turning_rate =  abs(spin) #/ 360.0
  if abs(spin) < 300: # ignore euler flip
   if spin < -1.0: turning = 'LEFT'
   elif spin > 1.0: turning = 'RIGHT'


  if turning == 'LEFT':
   if moving == 'BACKWARD':
    self.left_foot.shadow.location.x = -(motion_rate * 0.25)
    self.right_foot.shadow.location.x = -0.5

   elif moving == 'FORWARD':
    self.left_foot.shadow.location.x = 0.1
    self.right_foot.shadow.location.x = 0.2
    if motion_rate > 2:
     if random() > 0.8:
      step_right = True
      self.left_foot.shadow.location.x = -(motion_rate * 0.25)
     self.right_foot.shadow.location.x = motion_rate * 0.25

   if not step_right and random() > 0.2:
    if random() > 0.1: step_left = True
    else: step_right = True

  elif turning == 'RIGHT':
   if moving == 'BACKWARD':
    self.right_foot.shadow.location.x = -(motion_rate * 0.25)
    self.left_foot.shadow.location.x = -0.5

   elif moving == 'FORWARD':
    self.right_foot.shadow.location.x = 0.1
    self.left_foot.shadow.location.x = 0.2
    if motion_rate > 2:
     if random() > 0.8:
      step_left = True
      self.right_foot.shadow.location.x = -(motion_rate * 0.25)
     self.left_foot.shadow.location.x = motion_rate * 0.25

   if not step_left and random() > 0.2:
    if random() > 0.1: step_right = True
    else: step_left = True


  hand_swing_targets = []
  v = self.left_hand.biped_solver['swing-target'].location
  hand_swing_targets.append( v )
  v.x = -( self.left_foot.biped_solver['target'].location.x )

  v = self.right_hand.biped_solver['swing-target'].location
  hand_swing_targets.append( v )
  v.x = -( self.right_foot.biped_solver['target'].location.x )

  v = self.left_foot.biped_solver['target'].location
  if v.x < 0:  # if foot moving backward only pull on heel/foot
   self.left_toe.biped_solver['TARGET'].weight = 0.0
  elif v.x > 0: # if foot moving forward only pull on toe
   self.left_foot.biped_solver['TARGET'].weight = 0.0

  v = self.right_foot.biped_solver['target'].location
  if v.x < 0:  # if foot moving backward only pull on heel/foot
   self.right_toe.biped_solver['TARGET'].weight = 0.0
  elif v.x > 0: # if foot moving forward only pull on toe
   self.right_foot.biped_solver['TARGET'].weight = 0.0


  if moving == 'BACKWARD': # hands forward if moving backwards
   for v in hand_swing_targets: v.x += 0.1

  if step_left:
   rad = euler.z - math.radians(90+self.primary_heading)
   cx = math.sin( -rad )
   cy = math.cos( -rad )
   v = self.left_foot.shadow_parent.location
   v.x = x+cx
   v.y = y+cy
   v.z = .0
   self.left_foot_loc = v
  if step_right:
   rad = euler.z + math.radians(90+self.primary_heading)
   cx = math.sin( -rad )
   cy = math.cos( -rad )
   v = self.right_foot.shadow_parent.location
   v.x = x+cx
   v.y = y+cy
   v.z = .0
   self.right_foot_loc = v


  #################### falling ####################
  if falling:

   if current_pelvis_height < 0.2:
    for foot in (self.left_foot, self.right_foot):
     target = foot.biped_solver[ 'TARGET:pelvis' ]
     if target.weight < 50: target.weight += 1.0

     foot.add_local_torque( -30, 0, 0 )

   else:
    for foot in (self.left_foot, self.right_foot):
     target = foot.biped_solver[ 'TARGET:pelvis' ]
     target.weight *= 0.9


   for target in self.foot_solver_targets: # reduce foot step force
    target.weight *= 0.9

   #for target in self.hand_solver_targets: # increase hand plant force
   # if target.weight < self.when_falling_hand_target_goal_weight:
   #  target.weight += 1

   for hand in (self.left_hand, self.right_hand):
    self.head.add_local_torque( -self.when_falling_head_curl, 0, 0 )
    u = self.when_falling_pull_hands_down_by_tilt_factor * tilt
    hand.add_force( 0,0, -u )

    x,y,z = hand.get_location()
    if z < 0.1:
     self.head.add_force( 
      0,
      0, 
      tilt * self.when_falling_and_hands_down_lift_head_by_tilt_factor
     )
     hand.add_local_force( 0, -10, 0 )
    else:
     hand.add_local_force( 0, 3, 0 )

  else: # standing

   for foot in (self.left_foot, self.right_foot):
    target = foot.biped_solver[ 'TARGET:pelvis' ]
    target.weight *= 0.9


   for target in self.foot_solver_targets:
    if target.weight < self.when_standing_foot_target_goal_weight:
     target.weight += 1

   #for target in self.hand_solver_targets: # reduce hand plant force
   # target.weight *= 0.9


   head_lift = self.when_standing_head_lift
   for toe in ( self.left_toe, self.right_toe ):
    x,y,z = toe.get_location()
    if z < 0.1:
     self.head.add_force( 0,0, head_lift*0.5 )

   ## lift feet ##
   foot = self.left_foot
   v1 = foot.get_location().copy()
   if v1.z < 0.1: self.head.add_force( 0,0, head_lift*0.5 )

   v2 = self.left_foot_loc.copy()
   v1.z = .0; v2.z = .0
   dist = (v1 - v2).length
   if dist > 0.5:
    foot.add_force( 0, 0, self.when_standing_foot_step_far_lift)
   elif dist < 0.25:
    foot.add_force( 0, 0, -self.when_standing_foot_step_near_pull)

   foot = self.right_foot
   v1 = foot.get_location().copy()
   if v1.z < 0.1: self.head.add_force( 0,0, head_lift*0.5 )

   v2 = self.right_foot_loc.copy()
   v1.z = .0; v2.z = .0
   dist = (v1 - v2).length
   if dist > 0.5:
    foot.add_force( 0, 0, self.when_standing_foot_step_far_lift)
   elif dist < 0.25:
    foot.add_force( 0, 0, -self.when_standing_foot_step_near_pull)

Pyppet2 - Biped Solver - Part1

2011-12-16T16:59:00.000-08:00

http://pyppet.googlecode.com/files/pyppet-1.9.2f.tar.bz2


 def update(self, context):
  Ragdoll.update(self,context)

  loc,rot,scl = self.pelvis.shadow.matrix_world.decompose()
  euler = rot.to_euler()
  tilt = sum([abs(math.degrees(euler.x)),abs(math.degrees(euler.y))])/2.0

  x1,y1,z1 = self.pelvis.get_location()
  current_pelvis_height = z1
  x2,y2,z2 = self.head.get_location()
  x = (x1+x2)/2.0
  y = (y1+y2)/2.0
  ob = self.pelvis.shadow
  ob.location = (x,y,0)
  loc,rot,scale = ob.matrix_world.decompose()
  euler = rot.to_euler()

  rad = euler.z - math.radians(90)
  cx = math.sin( -rad )
  cy = math.cos( -rad )
  if not self.left_foot_loc or random() > 0.9:
   v = self.left_foot.shadow.location
   v.x = x+cx
   v.y = y+cy
   v.z = .0
   self.left_foot_loc = v

  rad = euler.z + math.radians(90)
  cx = math.sin( -rad )
  cy = math.cos( -rad )
  if not self.right_foot_loc or random() > 0.9:
   v = self.right_foot.shadow.location
   v.x = x+cx
   v.y = y+cy
   v.z = .0
   self.right_foot_loc = v

Updates foot targets, and measures tilt of head/pelvis offset.



  ## falling ##
  if current_pelvis_height < self.pelvis.rest_height * (1.0-self.standing_height_threshold):

   for target in self.foot_solver_targets: # reduce foot step force
    target.weight *= 0.9

   for target in self.hand_solver_targets: # increase hand plant force
    if target.weight < self.when_falling_hand_target_goal_weight:
     target.weight += 1


   for hand in (self.left_hand, self.right_hand):

    self.head.add_local_torque( -self.when_falling_head_curl, 0, 0 )

    u = self.when_falling_pull_hands_down_by_tilt_factor * tilt
    hand.add_force( 0,0, -u )

    x,y,z = hand.get_location()
    if z < 0.1:
     self.head.add_force( 
      0,
      0, 
      tilt * self.when_falling_and_hands_down_lift_head_by_tilt_factor
     )
     hand.add_local_force( 0, -10, 0 )
    else:
     hand.add_local_force( 0, 3, 0 )

If falling pull hands down to break fall, then try to sit up.



  else: # standing
   for target in self.foot_solver_targets:
    if target.weight < self.when_standing_foot_target_goal_weight:
     target.weight += 1

   for target in self.hand_solver_targets: # reduce hand plant force
    target.weight *= 0.9


   ## lift feet ##
   head_lift = self.when_standing_head_lift

   foot = self.left_foot
   v1 = foot.get_location().copy()
   if v1.z < 0.1: self.head.add_force( 0,0, head_lift )
   v2 = self.left_foot_loc.copy()
   v1.z = .0; v2.z = .0
   dist = (v1 - v2).length
   if dist > 0.5:
    foot.add_force( 0, 0, self.when_standing_foot_step_far_lift)
    #self.pelvis.add_force( 0,0, -head_lift*0.25 )
   elif dist < 0.25:
    foot.add_force( 0, 0, -self.when_standing_foot_step_near_pull)
    #self.head.add_force( 0,0, head_lift )

   foot = self.right_foot
   v1 = foot.get_location().copy()
   if v1.z < 0.1: self.head.add_force( 0,0, head_lift )
   v2 = self.right_foot_loc.copy()
   v1.z = .0; v2.z = .0
   dist = (v1 - v2).length
   if dist > 0.5:
    foot.add_force( 0, 0, self.when_standing_foot_step_far_lift)
    #self.pelvis.add_force( 0,0, -head_lift*0.25 )
   elif dist < 0.25:
    foot.add_force( 0, 0, -self.when_standing_foot_step_near_pull)
    #self.head.add_force( 0,0, head_lift )

If standing take step to next foot target, and lift head if foot is touching the ground.

pyppet2 - breakable ragdoll

2011-12-10T02:34:00.000-08:00

Using ODE joint feedback the stress of each joint can be measured, if over the user set threshold Pyppet will break the joint. TODO: add options to weaken/damage joints by reducing their ERP.

This video also shows a Stretch-to generated rig. (not selecting the stretch-to option creates a normal IK based rig)

Joint Damage

This morning I experimented with joint damage, reducing the ERP and raising the CFM on a joint when it is under stress. This can produce some interesting effects like a weakening joint. Another effect is to add a constant pull downwards when a joint is near breaking.

RPythonic 0.4.4

2011-12-06T03:37:00.000-08:00

Rpythonic has reached another major milestone and is now able to generate PyPy compatible ctypes bindings to C libraries. The two screen shots show OpenCV, Gtk3, and libfreenect running under PyPy 1.7.
The Rpythonic download contains pre-generated wrappers for the following libraries:

OpenAL

OpenCV

Emokit

Fluidsynth

GTK3

libfreenect

OpenGL

OpenJPEG

Wiiuse

Pyppet2

2011-12-05T05:53:00.000-08:00

Changes from Pyppet1 to Pyppet2:

ported from Blender2.49 to Blender2.6

WMD replaced with R.Pavlik's enhanced Wiiuse

Pygame replaced with ctypes-SDL

PyGTK2 replaced with ctypes-GTK3

PyODE replaced with ctypes-ODE

New in Pyppet2:

Kinect streaming using libfreenect

Web-camera streaming using OpenCV

Drag'n'Drop device config

Multi-threaded

ODE Joint Physics

http://pyppet.googlecode.com/files/pyppet-1.9.0.tar.bz2

Pyppet2 Update

2011-12-01T01:51:00.000-08:00

Mission1: Integrate Blender and GTK3

The first requirement of this project was to integrate Blender and GTK3 without any compiled Python modules, or modifications to the Blender C source code. To acheive this, only Python and ctypes are used. The GTK3 ctypes wrappers were generated by Rpythonic. GObject Introspection is not used or required.
Rpythonic is also used to generate wrappers to the Blender C API. This allows us to control the Blender main-loop from Python and integrate it with our own custom main-loop.

XEmbed:

The XEmbed protocol is used to embed Blender's window into a GtkSocket. The Blender window is placed on a GtkFixed canvas as the bottom layer. Gtk widgets can be drawn over-top of the Blender window by wrapping them in a GtkEventBox. The Properties sub-window is replaced with a Gtk widget by checking the location and size of the Area->Region object each main loop iteration. Bpy provides the width and height of this struct, but not its location in window-space. The ctypes wrapper to Blender (libblender) is used to get the location:


 # the pointer of any bpy object can be read with "as_pointer()" #
 addr = reg.as_pointer()
 ptr = ctypes.POINTER(ctypes.c_void_p).from_address( addr )
 creg = libblender.ARegion( pointer=ctypes.pointer(ptr), cast=True )
 rect = creg.winrct # blender window space
 print( rect.xmin, rect.xmax, rect.ymin, rect.ymax )

Mission2: Integrate Blender and Webcamera Streaming

OpenCV provides interesting effects and an interface for reading data from a web-camera using the highgui.QueryFrame function. QueryFrame is slow and blocks until the next frame is ready, not something that we can allow to slow down the main loop. Python multi-threading works very well when combined with ctypes, where the blocking call will release the GIL and allow other threads to continue. We only need to lock and release around the call that writes the final image data to a pixel buffer that Gtk displays.
To display the webcam buffer as a texture in the Blender viewport, OpenGL is used directly. I first tried BGL, but it seems that the call to glTexImage2D requires a BGL.Buffer object which wraps a python list. Converting the raw image data to a python list would be another speed hit. Instead, I used a pure ctypes wrapper to OpenGL where raw data pointers can be used directly. In order to get OpenGL over ctypes to work in Blender I found that the library can not be loaded from an external DLL, the magic trick is to call ctypes.CDLL("") with an empty string which forces ctypes to load the library from the current process.
The main loop checks the 'webcam' bpy Image each frame to see if its OpenGL "bindcode" is active, meaning that Blender has cached the image to be displayed in the view. Using the bindcode the texture can be updated dynamically.


  img = bpy.data.images['webcam']
  if img.bindcode:
   bind = img.bindcode
   glBindTexture(GL_TEXTURE_2D, bind)
   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR)
   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR)
   glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE)
   ptr = self.webcam.preview_image.imageData
   glTexImage2D(
    GL_TEXTURE_2D, 0, GL_RGB, 320, 240, 0, 
    GL_RGB, GL_UNSIGNED_BYTE, ptr
   )

http://pyppet.googlecode.com/files/pyppet-dec2-2011.tar.bz2

bpyengine

2011-11-18T22:43:00.000-08:00

http://code.google.com/p/bpyengine/

thread on blenderartists.org

SplineIK Face-Rig Template V1

2011-11-14T23:26:00.000-08:00

download

blender2ogre 0.5.x

2011-09-18T22:51:00.001-07:00

Craneo by Daniel FR Gordillo

http://blender2ogre.googlecode.com/files/blender2ogre-0.5.5.zip

Getting Started Tutorial Blender2Ogre-0.5.5 and RealXtend Tundra

Basic Mesh Export Tutorial - by OpenSpace3D.com

C++ Wrapper Generator - Part1

2011-07-06T08:18:00.001-07:00

There are several ways to wrap C++ and integrate it with Python, have a look on stackoverflow. Many wrapper generators rely on GccXML, but the project has been dead for years and has trouble parsing some newer C++. Another option is Swig, still active, but appears to require hand written wrapper code, and lacks support for things like nested classes. Clang was yet another option, it was able to output its parse tree as XML, but this feature was recently broken. So after much searching I finally found CppHeaderParser by Jashua Cloutier on SourceForge, the source code is all contained in a single file and very easy to understand. Since then (back in March), in my free time, I have been hacking away on CppHeaderParser; adding support for parsing more complex C++, resolving typedef's, nested classes, etc. For anyone else interesting in building a wrapper generator on top of it, you will be happy to hear it remains less than 2,000 lines of code, and very easy to modify to fit your particular needs. It is already being used successfully by the Emscripten project to generate a C wrapper and Javascript bindings, kripken's blog.

RPythonic-0.3.8 uses CppHeaderParser-2.0 as a backend to parse the C++ code and generate a C wrapper and Python-ctypes bindings. There is going to be a speed hit calling C++ through a C API over ctypes. Future work will solve the speed problem by generation of RPython (RFFI) bindings so that RPython can call into C++ code.

Work on both CppHeaderParser and the wrapper generator will continue, and should stablize in the next few releases. Basic features that are working now include: operators (==, +=, -=, etc.), enums, typedefs, classes and nested classes, class properties, structs, arrays, doxygen, and C compatible types. The major missing feature is wrapping of templates.

download all wrapper generator samples here

C Wrapper Sample - OgrePaged Method Call


/* Forests::TreeLoader3D.addTree */
/** \brief Adds an entity to the scene with the specified location, rotation, and scale.
 \param entity The entity to be added to the scene.
 \param position The desired position of the tree
 \param yaw The desired rotation around the vertical axis in degrees
 \param scale The desired scale of the entity

 While TreeLoader3D allows you to provide full 3-dimensional x/y/z coordinates,
 you are restricted to only yaw rotation, and only uniform scale. 
 
 \warning By default, scale values may not exceed 2.0. If you need to use higher scale
 values than 2.0, use setMaximumScale() to reconfigure the maximum. */
/*void addTree ( Ogre : : Entity * entity , __const__ Ogre : : Vector3 & position , Ogre : : Degree yaw = Ogre : : Degree ( 0 ) , Ogre : : Real scale = 1 0f , void * userData = __null ) ;
 returns_fundamental: True
 returns_pointer: 0
 returns_reference: False
 returns: void
 returns_class: False
*/
void  TreeLoader3D_addTree( void* object, void* arg0, void* arg1, void* arg2 )  {
 ((Forests::TreeLoader3D*)object)->addTree(
  //type: Ogre::Entity *, raw_type: Ogre::Entity, pointer: 1, ,
  (Ogre::Entity*)arg0,
  //type: const Ogre::Vector3 &, raw_type: Ogre::Vector3, constant: 1, reference: 1, ,
  (Ogre::Vector3&)arg1,
  //type: Ogre::Degree, raw_type: Ogre::Degree, default: Ogre : : Degree ( 0, ,
  (Ogre::Degree&)arg2 );
}

C Wrapper Sample - BulletPhysics - Set Property


/* --------------- class btVector3 --------------- */
/*  */
/**@brief btVector3 can be used to represent 3D points and vectors.
* It has an un-used w component to suit 16-byte alignment when btVector3 is stored in containers. This extra component can be used by derived classes (Quaternion?) or by user
* Ideally, this class should be replaced by a platform optimized SIMD version that keeps the data in registers
*/
/* ---------properties--------- */
//type: btScalar, raw_type: btScalar, typedefs: 1, fundamental: True, array: 4, ctypes_type: ctypes.c_float, 
void btVector3_m_floats__property_set__( void* object,btScalar  arg[4] ) { 
 ((btVector3*)object)->m_floats[ 0 ] = arg[ 0 ]; 
 ((btVector3*)object)->m_floats[ 1 ] = arg[ 1 ]; 
 ((btVector3*)object)->m_floats[ 2 ] = arg[ 2 ]; 
 ((btVector3*)object)->m_floats[ 3 ] = arg[ 3 ];  }

C Wrapper Sample - BulletPhysics - Operator Overloading


/**@brief Scale the vector
* @param s Scale factor */
/*} inline btVector3 & operator * = ( __const__ btScalar & s ) {
 returns_fundamental: False
 returns_pointer: 0
 returns_reference: True
 returns: btVector3
 returns_class: True
*/
void*  btVector3___operator____imult__( void* object, const btScalar & arg0 )  {
 return (void*)(& (((btVector3&)object)*=(arg0)) );
}

Pass1: Generate C Wrapper

flatten all method calls to functions

the instance is passed as the first argument

all instances are passed as void pointers

C compatible types are passed directly

objects returned are cast to void pointers

create wrapper functions for operators

create wrapper functions for get/set properties

Pass2: Generate Python-ctypes Wrapper

create a Python class for each C++ class

__init__ calls the constructor C wrapper

each method calls the C wrapper function

methods that return instances are passed to the matching python class

__del__ calls the destructor

operators overload: __mult__, __add__, etc..

__getattr__, __setattr__ call the get/set wrapper functions

Pycon 2011 Singapore

2011-06-10T03:15:00.000-07:00

Thanks to Maurice Ling and PyCon APAC I was able to attend today and give my talk about RPython and using it for creating games for Android. The latest source code for RPythonic can be downloaded here, this is the version I used in the demo. I was surprised to see almost a quarter of the audience was familiar with RPython, and of course everyone knew about Cython. The screen recording was not working, so there is no webcast of my talk, but for those who could not attend, the slides are attached in this post.

ODE-ctypes in Blender

2011-05-19T06:07:00.000-07:00

http://rpythonic.googlecode.com/files/Active-Physics-Blender-release1.zip

I never understood why the Bullet physics API is not exposed in the main Blender Python API, and instead its use is restricted to the BGE. Most users wanting to use physics are either doing digital puppetry, or prototyping game play to export to some other game engine. In either case we need something more flexible than the BGE for good results. Luckly with ctypes and ODE, realtime physics can run within the main Blender Python API (bpy) and give us greater flexablity.

This addon is still an experiment, the primary goal is to test the new object-oriented ctypes ODE wrappers and make sure they work well. I plan to come back to the addon later on and improve it, and hopefully adding interfaces to cool devices like Kinect, and support for ragdoll rigging.

The ctypes-ODE wrappers are now much easier to use being object-oriented, rather than previous versions which were mostly flat wrappers around the C API of ODE. This is done by three methods: 1. assuming that any function where the first argument is a pointer to a structure is a method on that struct, 2. allowing dynamic lookup of functions on structs via __getattr__, 3. and allowing RPythonic to insert portions of manually written wrapper code into the generated wrapper. The result is a wrapper that is almost fully compatible with the original hand-written PyODE. The difference is this wrapper is much easier to install because ctypes dynamically loads the shared library, and therefore we can run within Blender's embeded Python without any need for a local installation of Python on the end users machine.

Kinect Blender Addon

2011-05-12T04:44:00.000-07:00

source code

This addon is just a first test, more to come soon...

Requires libfreenect and opencv shared libraries are on your PATH (copy them to blender's root directory). So for Windows this would be: libfreenect_sync.dll, libcv.dll, libhighgui.dll. Linux users can just apt-get the packages as normal.

Kinect Hand Tracking

2011-05-10T06:42:00.000-07:00

The OpenCV-ctypes bindings may have a high overhead per-call because of the thick broiler-plate hiding ctypes, and ctypes itself using calling via libffi. However, given that quad-core CPU's are now standard; ctypes escaping the GIL can more than make up for the overhead, and gain higher performance than the official compiled OpenCV bindings.

The first Kinect/OpenCV test is dual threaded, with libfreenect and OpenCV each running in their own threads. In the graph to the right we can see the CPU usage, the blue and green cores are doing most of the work, and are out of phase - meanwhile the red and orange cores are not being used much. The main Python thread runs 70million operations in 30 seconds, and the frame rate display is low, with only about 100 updates.

Much of the work OpenCV is doing can be done in two passes, so it becomes easy to split the code into two threads. The tripple-threaded version seen to the right showed much better CPU usage. Blue and green cores are now running in-phase, without the blue core spiking. The red and orange cores now do much more work, and are only slightly out of phase. The main Python thread runs 50million operations in 30 seconds, lower than the dual threaded version, but the result is a four times faster display update - with 400 updates.

Hand Detection

HAAR wavelets are by far the most popular way of detecting hands or other features, the problem is speed, the Haar cascade can easily take a single core to 100% usage, and this is not suitable if we plan to run this hand detector within another program like Blender or RealXtend and maintain good performance.

Another method that is faster is to check for convexity defects of contours, this blog by Andol has a good overview of the techniques. Using the heuristic 4 or more defects is hand, and simply checking for defects among the many contour passes will yield false-positives from noise. The first trick is to filter out this noise on the contour with extreme polygon reduction, using the function cv.ApproxPoly with a factor of 20-30.0 or more. This reduces the head to a few triangles, while keeping the star-shape of the hand.

Kinect and OpenCV

2011-05-07T23:35:00.000-07:00

This research project was made possible by Adminotech. Kinect and OpenCV make a great combination, and now getting started is even easier with this pure-ctypes versions of both Libfreenect and OpenCV2. Python bindings already existed for both Libfreenect and OpenCV, but these must be compiled and linked to a given Python version. This is a pain for developers who need to support multiple platforms and multiple Python versions. Using pure ctypes bindings, only the shared library is needed per-platform, which can even be found pre-compiled. The other benefit of ctypes is threading and escaping the GIL, both Freenect and OpenCV can each run in their own threads.

The current aim of this research is to track the hands with as little CPU resources as possible, and to maintain 30fps read rate from the Kinect device. Streaming both video and depth from the Kinect can have serious effects on performance, so we will need a technique that can work with just the depth buffer. OpenCV is fast enough to sweep through about 12 passes of the depth buffer with increasing thresholds and hold 30fps. This is a good starting point since the contour of the hand is still clearly visible in at least one of the sweeps.

RPythonic Smart Wrappers

Another goal of the project was to make it easy for Python developers who are already familiar with the PyOpenCV API to migrate to the ctypes API. RPythonic now generates much smarter ctypes bindings which hide almost all of the ctypes-broiler-plate so that migration is simply a matter of changing the import header. Callback functions can now be directly passed to wrapped C function, and they will automatically be converted to a PyCFuncPtrType. Also lists and tuples are now valid arguments to wrapped C functions, if the argument type expects an array the tuple or list will be automatically converted. Or, if the argument expects some Structure, the list or tuple is used to initialze the Structure.

There are still some differences with the hand-made PyOpenCV and this automatically generated ctypes version. These mainly concern C functions that are passed a pointer that is then filled with some result, instead of returning a pointer to the result. The hand-made PyOpenCV wrappers deal with this properly and return a pointer without the user having to create it first and pass it to the function.

sample on pastebin

RPython and iOS

2011-05-04T01:49:00.000-07:00

RPythonic 0.3.3 now can wrap the standard C libraries of iOS, the following RFFI wrappers are included for:

OpenGLES

OpenAL

QuartzCore

CoreFoundation

CoreGraphics

Compiling RPython on iOS remains untested while I do not have an iPhone, but in theory it is not a problem because RPython is translated into standard ANSI C.

The Android wrappers have also been updated, and numerous bugs were fixed with ctypes wrapper generation. Most of the ctypes examples have not yet been updated to using the new RPythonic-API, only the simple-gtk demo, and the Kinect demo seen below.

RPython to Javascript

2011-04-30T19:32:00.000-07:00

RPythonic 0.3.1 now integrates with the fantastic Emscripten project to allow conversion of RPython into Javascript. PyPy itself had an experimental backend for Javascript, but this was recently removed because no one was maintaining it. Emscripten is more useful in any case because it will allow for the translation of C libraries used within RPython/RFFI. The PyPy backend would have been limited to only translating RPython code.

Translation begins with passing the RPython entry-point to rpy.compile(). Compile will then take care of translating to C, passing to Emmaken and LLVM, disassemble the LLVM binary, optimize with Emscripten's remove-dead-functions, pass that to emscripten.py to generate the javascript, and finally optimize the javascript with Closure. The result is 6,000 lines of javascript, most of which is RPython's reference counting garbage collector.

To make RPythonic easy to install several things are now included:

prebuilt d8 (google v8 javascript interpreter)

Emscripten configured for Ubuntu 11.04

Closure

PyCparser

CppHeaderParser

Stackless Compiled Modules

2011-04-25T00:29:00.000-07:00

RPythonic 0.3.0 now includes an example of using stackless in RPython loaded into Python over ctypes. The stackless mainloop can be called from a Python thread, the GIL is released so it is non-blocking. Values from a shared-object can be read in a thread-safe manner. The next step is to allow setting values from Python in a thread-safe way using locks.

stackless test1

RPython Shared Objects

2011-04-22T23:25:00.000-07:00

RPythonic 0.2.9 contains initial support for sharing object instances between Python and a RPython compiled module. Attributes are read only, so for now you must define setter functions for class attributes you need to set from Python. An interesting side-effect of having read only attributes is thread-safety. It appears that it is safe to read attributes from the main thread even when the same object is having its attributes updated from another thread calling RPython functions.


rpy = rpythonic.RPython()

@rpy.object
class MyRpyObject(object):
 def __init__(self, x=.0, y=.0, z=.0):
  self.x = x; self.y = y; self.z = z
 def add( self, x=.0,y=.0,z=.0 ): self.x += x; self.y += y; self.z += z
 def sum( self ): return self.x + self.y + self.z
 def show( self ): print '<%s %s %s>' %(self.x, self.y, self.z)

rpy.cache('test2', refresh=0) 

o = MyRpyObject()
print o.x
o.add( 1,2,3 )
print o.x
o.show()

GO = True
def ctypes_thread():
 print( 'thread start' )
 while GO:
  o.add( 0.1, 0.2, 0.3 )
 print( 'thread exit' )

import thread, time
thread.start_new_thread( ctypes_thread, () )

for i in range(1000*10):
 print o.x, o.y, o.z   # getting values from _pointer.contents is thread safe?  seems like it!
 #o.show()      # not thread safe

GO = False
print('test exit')

RPython modules for CPython

2011-04-18T04:28:00.000-07:00

It is now possible to use RPythonic to write CPython extension modules in RPython, RPythonic will work as the front-end that uses the PyPy translation toolchain to generate C code, compile it with GCC, package it in a cache directory with generated ctypes wrappers, and finally replace the decorated functions in-place in CPython.

RPythonic 0.2.8

RPython CPython Module API

import os, sys
sys.path.append('..')
import rpythonic
rpythonic.set_cache( '../cache' )
rpythonic.set_pypy_root( '../../pypy' )
################################
rpy = rpythonic.RPython()
@rpy.bind() # declare arg types is optional if,
def add( a=1, b=1000 ): # keyword defaults are given
return a+b
@rpy.bind(a=float, b=float)
def sub( a, b ):
return a-b
rpy.cache('test1') # only compiles if cache is dirty
########### now functions are using compiled version ###########
print add( 99, 88 )

Module Compiling and Caching

pyvnc realxtend addon

2011-02-10T23:28:00.000-08:00

The old Python-VNC-Viewer project went to great effort to gain the best performance, even optimizing the image bit-depth, direct buffer copies into SDL surfaces, and grouped blitting - but it still remains unuseably slow. The readme file even contains this: "What is it good for? Nothing ;-) Use the original VNC viewer for better performance." This got me thinking, maybe I should give up, sounds like Python can't handle this problem?

At first I considered using twistedmatrix and leveraging the work already done by Python-VNC-Viewer. I knew that using ctypes and going direct to libvncserver would have much better performance; but not as much as I expected - at least at first. It turns out twisted is infact pretty fast, even compared to a compiled C library. Testing single threaded ctypes-libvnc vs single threaded twisted-vnc, I found that ctypes-libvnc is only modestly faster - not many times faster. The bottleneck is in reading bytes from the server, the VNC (rfb) protocol sends lots of data despite being jpeg compressed and chunked. The slowness comes from single-threading, and having to block when reading these bytes. Thats the end of the story for twisted, since its threads are under the GIL.

The GIL and Ctypes (our Friends):

I often read people bashing the Python and the GIL (global interpreter lock), and that Python lacks true support for threads. In fact Python does have threads, its just that they lock every time you touch a variable, at first this sounds like bad news. However, what is not being point out more often, is that ctypes automatically releases the GIL when calling into C. The GIL now becomes our friend because it reduces the work needed to make things thread-safe. Making PyVNC thread-safe was trivial. The final results show that dual-threaded ctypes-vnc is many times faster than single-threaded twisted-vnc.


Test Machine 2ghz pent4
 python-vnc-viewer single threaded (twistedmatrix)
  average refresh 0.6 seconds
 pyvnc dual threaded (ctypes libvnc)
  average refresh 0.07 seconds

Naali (Tundra) Addon:

1. get this addon script and save it as addon-installer.py
2. download addon xml file and save it some where
3. run: 'python addon-installer.py pyvnc.addon /path/to/naali/bin/pymodules'

The script will then take care of downloading the modules required for your platform, now when you start Tundra the vnc-server and vnc-client windows should appear. If the addon script does not work for you for some reason, you can get the latest source for pyvnc on google code here. Note you can run pyvnc standalone, use the addon script just give a different path to save it, then run it by: 'python pyvnc.py' (as server), 'python pyvnc.py --client' (as client).

Special thanks to Adminotech LTD who sponsored this project, and everybody in IRC #realxtend-dev who helped me in understanding Naali and Qt.

ctypeslibs and rffilibs

2011-01-29T00:55:00.000-08:00

RPythonic-0.2.2 now includes several pre-generated wrappers, see the list of libraries below. The wrappers come in both formats: ctypes and rffi. The main issue in using RPython to write complex standalone programs is it can not connect with external libraries like Python can. This problem is now in the process of going away using generated bindings. There are still problems with the wrapper generation, so this is still a work in progress.
. OpenGL
. GTK
. libpng
. ODE (Open Dynamics Engine)
. SDL
. audiofile
. openjpeg
. tiffio

Once wrapper generation is effective for binding to both C and C++, the last hurdle to make RPython easier to use is to lift some of the restrictions below. Some of these restrictions will never go away, afterall it is Restricted-Python.

RPython is more or less defined as:

RPython rule1: All rules can be broken if you can meta-program your way around them
( example: using function decorators to rewrite functions to comply with the rules below )

RPython rule2: All globals and class-level attributes are constants.
. PyPy considers globals to always be constant, including class-
level attributes. Instead use singleton instances to store global changeable state.

RPython rule3: Tuples may contain mixed types, but it should be avoided.
. PyPy can not use a loop to iterate over mixed tuples
( because to iterate over a tuple it must be cast to a list - ie. for x in list(mytuple) )

RPython rule4: Dicts and lists must contain compatible types (homogeneous).
. ShedSkin and PyPy common rule

RPython rule5: No reflection (getattr, hasattr, etc..)
. PyPy allows for limited getattr, hasattr.., but only if the string is 'concrete.'

RPython rule6: No runtime evaluation.
. Neither ShedSkin or PyPy support eval or exec

RPython rule7: No **keywordargs
. Neither ShedSkin or PyPy support **kw

RPython rule 8: Within a scope, a variable must not change type; however,
`None` can be used as a place holder and intermixed with any type, but NOT with ints or floats.

RPython rule 9: For instances to be of a compatible type, they must inherit from a common base class.
. ShedSkin and PyPy requirement

RPython rule 10: For compatible instances stored in the same list, but
of different subclasses, to call methods with incompatible signatures
or access attributes unique to the subclass, the type must be asserted
first:
assert isinstance(a,MySubClass)

RPython rule 11: The *assert isinstance* statement acts like a cast in
C/C++, turning `SomeObject` into the real subclass instance. This
solves problems like in rule10, and in other cases where an instance
of uncertian type must be passed to a function that expects a certian
type.

RPython rule 12: No overloading, except for __init__ and __del__.

RPython rule 13: Attribute variables should be of consistent type in
all subclasses. Do not create a subclass that redefines the type of
an attribute.

RPython rule 14: The calling and return signature of a function must
not change. The types of function arguments must always be the same
for each function call. Only `None` can be intermixed but not with ints or floats.
Function returns must always have the same type.

RPython rule 15: Its not recommended to define subclasses with like-
named functions that have different signatures. Casting by `assert
isinstance` is the work around that allows this rule to be bent.
In addition when doing this you may need to follow rule16 below.

RPython rule 16: The root base class should define dummy functions,
if multiple subclasses will overload them those functions with
incompatible signatures.
. Prevents method `demotion` error in PyPy

RPython Extra Quirks:


 1. a string of multiple characters is not the same as a string of a single character,
 some functions will only accept a single character string; Examples:
  this is valid:
   a = 'hello world'
   a.split(' ')
   a.split('x')
  this is invalid:
   a = 'hello world'
   a.split()
   a.split('world')

 2. some builtin functions require an argument where normally they do not, Example:
  this is valid:
   a = ['x','y','z']
   a.pop( len(a)-1 ) # pop by index, pop the last item
  this is invalid:
   a = ['x','y','z']
   a.pop() # pop requires an index so this fails

Wrapping The Android NDK

2011-01-22T00:58:00.000-08:00

The latest RPythonic, here, can generate rffi bindings for almost the entire Android NDK. Using these bindings compiled RPython can call C functions, like OpenGLES display functions. The randroid-compile.py script is updated to call ant and automatically build the .apk file for you in debug mode (unsigned). Some issues remain like native-app-glue integration, and parsing errors from pycparser that prevent some of the NDK from being wrapped. The following are wrapped:

. android/api_level
. android/bitmap
. android/input
. android/keycodes
. android/looper
. android/native_activity
. android/native_window
. android/native_window_jni
. android/obb
. android/rect
. android/storage_manager
. EGL/egl
. EGL/eglplatform
. GLES/gl
. GLES/glplatform
. GLES2/gl2
. GLES2/gl2platform
. SLES/OpenSLES
. SLES/OpenSLES_AndroidConfiguration
. SLES/OpenSLES_Platform

Android and RPython

2011-01-18T02:25:00.000-08:00

Wrapping the ndk-build tool and auto generating the Android.mk file is the simplest way to get RPython code to compile using the Android NDK. Note this only works on 32bit linux at the moment.

The PyPy translation toolchain dumps several C source and header files when calling translation.source_c(), and these are not returned by the function; instead they must be collected from translation.driver.cbuilder.targetdir and ..cbuilder.extrafiles. These files are then copied to a new project, in a 'jni' subdirectory, and the Android.mk make-file is generated. All C files except for testing_1.c should be built as static libraries. Android.mk builds each one using "include $(BUILD_STATIC_LIBRARY)". Finally the shared library setup to include all the static libraries using "LOCAL_STATIC_LIBRARIES := structimpl nonfuncnodes implement etc..."

To jump in a try out translating and compiling some RPython code:
1. download and setup the Android SDK and NDK,
2. get the PyPy source code,
3. get randroid-compile.py from the latest RPythonic, follow the README file for where to place the PyPy source code and Android SDK/NDK,
4. modify PyPy's source code - small changes see below*
5. run randroid-compile.py my_rpython_script.py

*4. The PyPy C backend contains some handwritten C code, found under pypy/translator/c/src. This will have to be changed just slightly to allow for minor differences between Android-Linux and GNU/Linux.


    1. " && !defined(ANDROID)"
    (add to the end of line 49 in debug_print.h)

    2. "# ifdef ANDROID
  decimal_point = ".";
  decimal_point_len = 1;
        # else
  locale_data = localeconv();
  decimal_point = locale_data->decimal_point;
  decimal_point_len = strlen(decimal_point);
        # endif
    (replace lines 43, and 112 of ll_strtod.h)

or you can download these patched versions [1] [2] and overwrite them in pypy/translator/c/src/

5. run "python rpy-android.py"

ctypes-pygtk in blender25

2011-01-06T01:37:00.000-08:00

addon source code

The latest RPythonic can generate ctypes bindings for GTK that are also Python3 and Blender compatible. Currently Blender lacks a way to call a python function at a timed interval, this would be a show stopper for the old PyGTK bindings where gtk_main is a blocking function. Luckily ctypes releases the GIL when a C function is called, as detailed by Christopher Swenson, here, if the call is wrapped in a python thread, then gtk_main can run in its own non-blocking thread while Blender continues to update smoothly.

Blender Ogre Collision Panel

2010-12-15T22:30:00.000-08:00

Triangle count may not be much of an issue for rendering, but it still remains a bottle neck when doing collisions even with fast libraries like Bullet. The exporter uses blender-game-engine (BGE) collision primitive types; or a second proxy-mesh can be parented underneath the display mesh, and then the proxy is substituted as the triangle mesh for collision. Collision primitives are of course the fastest option. By default Blender does not display the bounding type when a BGE collision primitive is choosen, so the collision panel seen here will do the extra work and display the correct bounding type so that the user can get visual feedback of their changes. If the collision type 'Triangle Mesh' is chosen, the object is set to show wire-frame over shaded. (note there is a bug in blender 'Capsule' type may not show)

Setting a proxy-mesh for triangle collision can be done manually by the user, but this is error prone, so the interface automates this process by doing the following: copies object, parents, locks translation, renames to 'collision', and then applies a decimate modifier. The decimate modifier is then controlled from the parents panel.

Ogre Texture and Material Panels

2010-12-10T19:42:00.000-08:00

When dealing with a hijacked interface, often the user will get confused which options are supported by the exporter, and which ones are not. To solve this problem two custom panels have been added to the Material and Texture tabs under Properties that restrict the UI to only what is supported. These extra panels also streamline the workflow for the user, and provides some additional error checking to make sure they have entered valid options.

Ogre Texture Units have very nice options for texture animation. Only the most basic options are exposed here: scrolling and rotate. Another animation option Wave-xform allows for any combination of cyclic animation to position, rotation or scaling. Unfortunately, Wave-xform can not be included because, at this time, Blender does not support 'Custom-Properties' for texture-slot objects. If your an Ogre/Blender user, and want Wave-xform texture support, you can lobby for it in "blendercoders" on IRC freenode by talking directly with the Blender developers there. Custom-Property support for texture-slots requires a change at the C-level of Blender, and it can not be done from this addon script alone.

OgreDotScene + BGE

2010-12-09T01:36:00.000-08:00

Blender contains a fully functional game engine (BGE) that is highly useful for learning the concepts of game programming by breaking it down into three simple parts: Sensor, Controller, and Actuator. An Ogre based game engine will likely have similar concepts in its internal API and game logic scripting. Without a custom interface to define game logic, very often game designers may have to resort to having programmers implement their ideas in purely handwritten script. This is prone to breakage because object names then end up being hard-coded. Not only does this lead to non-reusable code, its also a slow process. Why should we have to resort to this when Blender already contains a very rich interface for game logic? By hijacking a subset of the BGE interface we can make this workflow between game designer and game programmer much better.

The OgreDocScene format can easily be extened to include extra game logic data. While the BGE contains some features that can not be easily mapped to other game engines, there are many are highly useful generic features we can exploit, including many of the Sensors and Actuators. Blender uses the paradigm of: 1. Sensor -> 2. Controller -> 3. Actuator. In pseudo-code, this can be thought of as: 1. on-event -> 2. conditional logic -> 3. do-action. The designer is most often concerned with the on-events (the Sensors), and the do-actions (the Actuators); and the BGE interface provides a clear way for defining and editing those. Its a harder task to provide a good interface for the conditional logic (Controller), that is flexible enough to fit everyones different Ogre engine and requirements, so that is outside the scope of this exporter at this time. A programmer will still be required to fill the gap between Sensor and Actuator, but hopefully his work is greatly reduced and can write more generic/reuseable code.

The rules for which Sensors trigger which Actuators is left undefined, as explained above we are hijacking the BGE interface not trying to export and reimplement everything. BGE Controllers and all links are ignored by the exporter, so whats the best way to define Sensor/Actuator relationships? One convention that seems logical is to group Sensors and Actuators by name. More complex syntax could be used in Sensor/Actuators names, or they could be completely ignored and instead all the mapping is done by the game programmer using other rules. This issue is not easily solved so designers and the engine programmers will have to decide upon their own conventions, there is no one size fits all solution.

example xml

Ogre Shaders and Blender Library Linking

2010-11-24T00:42:00.000-08:00

Ogre offers some very advanced and complex ways to implement shaders. This must be carefully considered by an experienced programmer who is dealing with the high-level shading code. One particular issue is shadows and deforming mesh requires a shader that can easily be broken by an artist who changes the wrong options, or adds options that invalidate the shader. These issues can mostly be solved by using Blender's library linking, because linked data beomes read-only - it in effect provides a layer of control by the shader-programmer over the artist. Done in the right way, these restrictions will not hinder the artist either from experimenting and extending the shader's usefullness. In addition, library linking allows automatic-push of updates downstream to artists; so whenever the shader-programmer updates their shader code and updates his own master .blend with new shader options, the change is propagated to all .blends linking to it.

more info on the wiki

ogre forum topic

Ogre Shader Nodes

2010-11-20T01:29:00.000-08:00

Continuing my work with Evocativi on RealXtend and the Ogre exporter, at last I have reached the final milestone - supporting all of Ogre-Dot-Material options from within Blender. This was the hardest of all milestones because of the extensive number of features that Ogre-Dot-Material contains. Another tricky part was digging into the shader nodes RNA in Blender, which is still developing. You can get the latest source on google code, here.

Blender Python Operator API

2010-11-14T22:51:00.000-08:00

I recently started working for Evocativi to help migrate the existing python tools to blender25, and develop new tools for game development and integration of blender with RealXtend. RealXtend is a scaleable Ogre-rendering based game engine for making online virtual worlds. My work begins with porting the Ogre exporter by Michael Reimpel from blender24 to blender25. This has turned out to be harder than I first expected, partly because of the new operator API in blender25 and its unique design.

Getting Started

The first thing to be confused by is that the __init__ function is not used when defining a custom operator. Instead you will define class-level attributes using the types in bpy.props: BoolProperty, StringProperty, FloatProperty, IntProperty, etc. The second thing to be confused by is that the value returned by bpy.props.*Property is always a tuple with the first item a pointer to the property function just called, and the second item a dictionary that contains the arguments you passed to the property function. Only when the operator is invoked or executed is the class-level attribute changed from a tuple into the expected type. This appears not to be clearly documented in the Blender wiki on operators, found here.

bpy.types

Another point of confusion is that each and every widget and operator that is defined (including addons) dynamically appear in the bpy.types listing. Care must be taken to give your operator a unique class name, and a unique 'bl_idname'. By not giving a unique name you can override blender's default behavior or interface. For example lets override the INFO menu with some more useful buttons and features that a game designer user will likely always want to have quick access to.


class INFO_HT_header(bpy.types.Header):

    bl_space_type = 'INFO'

    def draw(self, context):

        layout = self.layout

        wm = context.window_manager

        window = context.window

        scene = context.scene

        rd = scene.render

        layout.operator("wm.window_fullscreen_toggle", icon='FULLSCREEN_ENTER', text="")

        #layout.operator("ogre_export", text="Ogre")

        row = layout.row(align=True)

        sub = row.row(align=True)

        sub.menu("INFO_MT_instances")

        sub.menu("INFO_MT_groups")

        sub.menu("INFO_MT_actors")

        sub.menu("INFO_MT_dynamics")



        if True: #context.area.show_menus:

            sub.menu("INFO_MT_file")

            sub.menu("INFO_MT_add")

            if rd.use_game_engine: sub.menu("INFO_MT_game")

            else: sub.menu("INFO_MT_render")

        layout.separator()

        if window.screen.show_fullscreen:

            layout.operator("screen.back_to_previous", icon='SCREEN_BACK', text="Back to Previous")

            layout.separator()

        else:

            layout.template_ID(context.window, "screen", new="screen.new", unlink="screen.delete")



        layout.separator()

        layout.template_running_jobs()

        layout.template_reports_banner()



        layout.separator()

        if rd.has_multiple_engines:

            layout.prop(rd, "engine", text="")

        layout.template_header()

        if context.area.show_menus:

            layout.template_ID(context.screen, "scene", new="scene.new", unlink="scene.delete")

            layout.label(text=scene.statistics())

            layout.menu( "INFO_MT_help" )

        else:

            screen = context.screen

            row = layout.row(align=True)

            row.operator("screen.frame_jump", text="", icon='REW').end = False

            row.operator("screen.keyframe_jump", text="", icon='PREV_KEYFRAME').next = False

            if not screen.is_animation_playing:

                row.operator("screen.animation_play", text="", icon='PLAY_REVERSE').reverse = True

                row.operator("screen.animation_play", text="", icon='PLAY')

            else:

                sub = row.row()

                sub.scale_x = 2.0

                sub.operator("screen.animation_play", text="", icon='PAUSE')

            row.operator("screen.keyframe_jump", text="", icon='NEXT_KEYFRAME').next = True

            row.operator("screen.frame_jump", text="", icon='FF').end = True



            row = layout.row(align=True)

            if not scene.use_preview_range:

                row.prop(scene, "frame_start", text="Start")

                row.prop(scene, "frame_end", text="End")

            else:

                row.prop(scene, "frame_preview_start", text="Start")

                row.prop(scene, "frame_preview_end", text="End")



            layout.prop(scene, "frame_current", text="")





def gather_instances():

 instances = {}

 for ob in bpy.data.objects:

  if ob.data and ob.data.users > 1:

   if ob.data not in instances: instances[ ob.data ] = []

   instances[ ob.data ].append( ob )

 return instances



def select_instances( context, name ):

 for ob in bpy.data.objects: ob.select = False

 ob = bpy.data.objects[ name ]

 if ob.data:

  inst = gather_instances()

  for ob in inst[ ob.data ]: ob.select = True

  bpy.context.scene.objects.active = ob



def select_group( context, name, options={} ):

 for ob in bpy.data.objects: ob.select = False

 for grp in bpy.data.groups:

  if grp.name == name:

   bpy.context.scene.objects.active = grp.objects[0]

   for ob in grp.objects: ob.select = True



class INFO_MT_instances(bpy.types.Menu):

 bl_label = "Instances"

 def draw(self, context):

  layout = self.layout

  inst = gather_instances()

  for data in inst:

   ob = inst[data][0]

   op = layout.operator("select_instances", text=ob.name) # operator has no variable for button name?

   op.mystring = ob.name

  layout.separator()



class INFO_MT_instance(bpy.types.Operator):                

 '''select instance group'''                                                     

 bl_idname = "select_instances"                                             

 bl_label = "Select Instance Group"                        

 bl_options = {'REGISTER', 'UNDO'}     

 mystring= StringProperty(name="MyString", description="...", maxlen=1024, default="my string")

 @classmethod

 def poll(cls, context): return True

 def invoke(self, context, event):

  print( 'invoke select_instances op', event )

  select_instances( context, self.mystring )

  return {'FINISHED'}



class INFO_MT_groups(bpy.types.Menu):

 bl_label = "Groups"

 def draw(self, context):

  layout = self.layout

  for group in bpy.data.groups:

   op = layout.operator("select_group", text=group.name) # operator no variable for button name?

   op.mystring = group.name

  layout.separator()



class INFO_MT_group(bpy.types.Operator):                  

 '''select group'''       

 bl_idname = "select_group"                                      

 bl_label = "Select Group"        

 bl_options = {'REGISTER', 'UNDO'}   

 mystring= StringProperty(name="MyString", description="...", maxlen=1024, default="my string")

 @classmethod                                                      

 def poll(cls, context): return True

 def invoke(self, context, event):

  select_group( context, self.mystring )

  return {'FINISHED'}



class INFO_MT_actors(bpy.types.Menu):

 bl_label = "Actors"

 def draw(self, context):

  layout = self.layout

  for ob in bpy.data.objects:

   if ob.game.use_actor:

    op = layout.operator("select_actor", text=ob.name)

    op.mystring = ob.name

  layout.separator()



class INFO_MT_actor(bpy.types.Operator):                

 '''select actor'''                                                     

 bl_idname = "select_actor"                                             

 bl_label = "Select Actor"                                             

 bl_options = {'REGISTER', 'UNDO'}                              # Options for this panel type

 mystring= StringProperty(name="MyString", description="...", maxlen=1024, default="my string")

 @classmethod

 def poll(cls, context): return True

 def invoke(self, context, event):

  bpy.data.objects[self.mystring].select = True

  return {'FINISHED'}



class INFO_MT_dynamics(bpy.types.Menu):

 bl_label = "Dynamics"

 def draw(self, context):

  layout = self.layout

  for ob in bpy.data.objects:

   if ob.game.physics_type in 'DYNAMIC SOFT_BODY RIGID_BODY'.split():

    op = layout.operator("select_dynamic", text=ob.name)

    op.mystring = ob.name

  layout.separator()



class INFO_MT_dynamic(bpy.types.Operator):                

 '''select dynamic'''                                                     

 bl_idname = "select_dynamic"                                             

 bl_label = "Select Dynamic"                                             

 bl_options = {'REGISTER', 'UNDO'}                              # Options for this panel type

 mystring= StringProperty(name="MyString", description="...", maxlen=1024, default="my string")

 @classmethod

 def poll(cls, context): return True

 def invoke(self, context, event):

  bpy.data.objects[self.mystring].select = True

  return {'FINISHED'}

Inside The Blender C API - Part2

2010-10-04T19:04:00.000-07:00

A good high level overview of Blender's window and event management is on the official wiki, here. Digging deeper into the source code, the main function of creator.c the function call WM_keymap_init(C) setups basic mouse and keyboard handling. Looking inside this function the first call is to CTX_wm_manager(C) which returns a pointer to the wmWindowManager struct contained by C (the context struct). Inside WM_keymap_init, a new wmKeyConfig struct is created by WM_keyconfig_new, this is then passed to: wm_window_keymap, ED_spacetypes_keymap, and WM_keyconfig_userdef. Finally the wmKeyConfig is assigned to the wmWindowManager struct as `defaultconf`.

The recent recoding overhaul of Blender25 has removed much of the use of muteable globals to store changeable state, and has been replaced by a better system of a single context struct (C) that is passed around as a function argument. It is well documented, here. The context struct C, is of the type bContext and defined in:
blender/source/blender/blenkernel/BKE_context.h
blender/source/blender/blenkernel/intern/context.c

C has a very simple top-level structure, it contains: a thread index, window manager struct, data context struct, and eval struct. The window manager struct contains: a manager, window, screen, area, region, menu, and store. The data context struct contains the scene and python context.

blenkernel note:

Many functions defined in blender/source/blender/blendkernel are prefixed with BKE, but not all. CTX_create and CTX_wm_manager are two examples of blendkernel functions that do not start with BKE.

DNA_windowmanager_types.h

The wmWindowManager struct and wmKeyConfig are defined in blender/source/blender/makesdna/DNA_windowmanager_types.h. Other important window manager related structs also define here are: wmWindow and wmOperator. The wmWindow struct contains a pointer to a wmEvent struct named `eventstate`, and a list named `queue` that contains all events. Two other event lists inside wmWindow are: `handlers` and `modalhandlers`.

WM_types.h and wm_event_types.h

Both of these headers are in: blender/source/blender/windowmanager/. wmEvent and other window event related things are defined here, the structs are in WM_types.h and the enums are in wm_event_types.h. Below is the definition of wmEvent:


/* each event should have full modifier state */
/* event comes from eventmanager and from keymap */
typedef struct wmEvent {
 struct wmEvent *next, *prev;
 short type;   /* event code itself (short, is also in keymap) */
 short val;   /* press, release, scrollvalue */
 short x, y;   /* mouse pointer position, screen coord */
 short mval[2];  /* region mouse position, name convention pre 2.5 :) */
 short unicode;  /* future, ghost? */
 char ascii;   /* from ghost */
 char pad;
 /* previous state */
 short prevtype;
 short prevval;
 short prevx, prevy;
 double prevclicktime;
 short prevclickx, prevclicky;
 /* modifier states */
 short shift, ctrl, alt, oskey; /* oskey is apple or windowskey, value denotes order of pressed */
 short keymodifier;    /* rawkey modifier */
 short pad1;
 /* keymap item, set by handler (weak?) */
 const char *keymap_idname;
 /* custom data */
 short custom;  /* custom data type, stylus, 6dof, see wm_event_types.h */
 short customdatafree;
 int pad2;
 void *customdata; /* ascii, unicode, mouse coords, angles, vectors, dragdrop info */
} wmEvent;

Inside Blender

2010-10-04T01:12:00.000-07:00

After so many years of Blender being open source, it is rather shocking to see the Blender C API still remains mostly undocumented. The official wiki has some documents which provide a good high level overview, but very few get into the details of the source code. Blender is a large project, certainly difficult to document, it consists of: 839 C files (.c), 1398 C header files (.h), 618 C++ files (.cpp), and 38 C++ header files (.hpp). Total lines of code is 1,253,126. Blender includes source from other external projects (like bulletphysics), so after substracting them the total lines of code is 1,097,349.

Looking at the recent svn commit activity, Blender is being developed by a relatively small number of developers for such a high profile project. Only nine developers have recent checkins of twenty or more files. With most of the load carried by Campbell Barton.

SVN Check-Ins: (snapshot of source files, not total commits this year)
campbellbarton 1081
nexyon 156
blendix 75
gsrb3d 47
jesterking 31
broken 24
nazgul 20
dfelinto 20
aligorith 20

What is shying away new developers? Documentation must be a major factor, it is very hard to jump into a code base of one million lines of code with only high level documentation. Another factor stems from Blender's odd opposition to using a standardized GUI toolkit, and instead opting for its own internal GUI system written in OpenGL with an event system that interfaces directly with the OS. Developers familiar with common place GUI toolkits like GTK or QT will find it hard to adapt to Blender's GUI system.

Recently with the major advancement of Blender2.5, the GUI system was given a major overhaul, and now much of it exists in Python. However, this Python API has its limitations (not exposing the Tree/List-View for example), and not compatible with anything else like PyGTK or PyQT. Blender has taken the approach of `embed not extend`, which is counter to the Python mantra of `extend not embed`; and this has led to a Blender Python API that is very hard to integrate with the rest of the greater Python eco-system.

Inside The Blender C API: - Part 1

Diving into the source code you will find that the `main` function is in: blender/source/creator/creator.c
This mostly sets things up and calls the mainloop, which is actually WM_main found in: blender/source/blender/windowmanager/intern/wm.c
Blender uses the directory convention: `intern` and `extern`, which apparently defines which part of a library should be hidden or exposed to other libraries. Another convention (not always followed) is functions that begin with capital letters are exposed to other libraries.
WM_main only calls four functions in its while loop:
/* get events from ghost, handle window events, add to window queues */
wm_window_process_events(C);
/* per window, all events to the window, screen, area and region handlers */
wm_event_do_handlers(C);
/* events have left notes about changes, we handle and cache it */
wm_event_do_notifiers(C);
/* execute cached changes draw */
wm_draw_update(C);

These functions are defined in:
blender/source/blender/windowmanager/WM_types.h
blender/source/blender/windowmanager/wm_window.h
blender/source/blender/windowmanager/wm_event_system.h
blender/source/blender/windowmanager/wm_draw.h

Libblender - Getting Started:

Before trying the ctypes wrapper for libblender, you will need to compile blender as a shared library - on Windows this is a 'dll' file, and on Linux this is a 'so' file. First modify 'blender/CMakeLists.txt' and turn off both the game engine and python. Then edit 'blender/source/creator/CMakeLists.txt' and change:
ADD_EXECUTABLE(blender ${EXETYPE} ${EXESRC})
to:
ADD_LIBRARY(blender SHARED ${EXETYPE} ${EXESRC})
Finally, run cmake. If you have never used cmake to build blender, you need to create a new build directory outside of the blender source tree. On linux you would then run:
cmake -G "Unix Makefiles" ../blender
make

The lastest ctypes wrapper for libblender exposes enough of the C API to control the main loop. Converting the `main` and `WM_main` into ctypes looks like following:


import os, sys, time
from ctypes_libblender import *
from ctypes import *

def main():
 _argv = ''
 for arg in sys.argv: _argv += arg + ' '
 argc = len(sys.argv)
 argv = ctypes.pointer(ctypes.c_char_p(_argv))
 C = CTX_create()  # bContext pointer
 BLI_threadapi_init()
 RNA_init()
 RE_engines_init()
 pluginapi_force_ref();
 init_nodesystem();
 initglobals()
 IMB_init()
 syshandle = SYS_GetSystem()
 GEN_init_messaging_system()
 ba = BLI_argsInit(argc, argv)
 setupArguments(C, ba, syshandle);
 BLI_argsParse(ba, 1, None, None);  # required, segfaults without this
 sound_init_once(); 
 init_def_material();
 print ('WM_init...'); time.sleep(1)
 WM_init(C, argc, argv);       # some less random crash happening here
 BLI_where_is_temp( c_char_p('/tmp'), 1 )
 CTX_py_init_set(C, 1);
 WM_keymap_init(C);  # (this segfaults if BLI_where_is_temp is not called above)
 time.sleep(1) # can segfault if we don't wait for the window to appear?
 while True:
  wm_window_process_events(C); 
  wm_event_do_handlers(C);
  wm_event_do_notifiers(C);
  wm_draw_update(C);

ctypes libblender

2010-10-03T00:48:00.000-07:00

Get the first working version of the ctypes version of libblender.py precompiled for 64bit ubuntu, here. A large chunk of the blender C API is exposed, over 7,000 lines of generated ctypes code.

Testing RPythonic on Blender25

2010-09-30T02:57:00.000-07:00

The main entry point into the Blender C API is `creator.c`. This file after CPP has processed it and included all the imports, is about 5,000 lines long. Running RPythonic on it generates: about 1,000 lines of ctypes wrapper code, and the same for rffi. Pointers are not working well yet, so the generated code is not functional. The approach is working well so far, and it should be possible to wrap the entire Blender C API this way. How much can be translated to RPython remains to be seen. Work in progress:
generated rffi
generated ctypes
generated rpython

RPythonic

2010-09-28T18:43:00.000-07:00

RPythonic takes in C code and outputs three different formats: 1. pure RPython code, 2. ctypes wrappers, and 3. rffi wrappers. Using the PyPy translation toolchain the pure RPython code can be translated back to C, or C# and Java (allowing your C code to be executed by .Net or Java runtimes). The generated ctypes wrapper can be used from CPython. The rffi wrappers allow you to use C code from RPython. RPythonic is built using PycParser, a powerful C parser written by Eli Bendersky written in Python.

Why not Pygccxml?
Pygccxml is made up of about 50 files and several thousands of lines of code, totalling about 1MB of code; and relies on the external program Gccxml. Gccxml is old and development has stalled. Another automatic binding generator Pybindgen uses Pygccxml, and the interface between Pybindgen and Pygccxml alone is over two thousands lines of code, not pretty!

PycParser is super clean, 10 files, less than 150KB of code; is pure Python and relies on no external programs. While Pygccxml can parse C/C++ code, it can not parse the function bodies. On the other hand, PycParser can fully parse C and function bodies, but not C++. For RPython and ctypes wrappers we are only interested in C; and because PycParser can fully parse C, translation of C to RPython is also possible at the same time the bindings are generated.

RPythonic on google code

OpenCV connected to Blender25

2010-09-18T02:36:00.000-07:00

source code

Multiprocessing

2010-09-16T18:12:00.000-07:00

OpenCV is multithreaded, and you can set the number of threads it uses by cvSetNumThreads(N). The haar cascades used for face and other feature detection will fully utilize all the threads you give it. Using glib.timeout_add( miliseconds, self.loop ) even with 4 threads you will still get unacceptable lag doing haar detection on a 320x240 image; the GUI will become unresponsive because glib will not update its own events if the timeout is always fully loaded.

The solution is spliting the process in two so that pygtk can have its own core and update without being blocked by the OpenCV/Pygame process. One approach for this is to use the subprocess module, and serialize data from the GUI to the OpenCV/Pygame process over a pipe - but this is rather slow. The fastest approach available in Python is the multiprocessing module that uses ctypes wrapped sharedmemory. If sharedmemory is only read from the OpenCV/Pygame process then there will be no data copy overhead, giving us the maximum possible speed. (copy-on-write is implemented in hardware and supported by modern Linux kernels.)

Ctypes restricts what types can be shared, so its not possible to share a dictionary or instance. Luckly ctypes has a simple interface for using C-level structs, and all the data from the GUI can easily be reformatted from using a dictionary to using structs in an array.


_cfg_ubytes =  'active alpha blur athresh_block_size thresh_min thresh_max'.split()
_cfg_ubytes += 'FXstencil FXblur FXsobel FXathresh FXthresh FXdetect'.split()
class LayerConfig( ctypes.Structure ):
 _fields_ = [ ('colorspace',ctypes.c_int) ]
 for tag in _cfg_ubytes: _fields_.append( (tag, ctypes.c_ubyte) )
 del tag
mysharedmemory = multiprocessing.sharedctypes.Array( LayerConfig, [ (cv.CV_BGR2RGB,) ], lock=False )

source code

RPython FFTW

2010-08-28T23:19:00.000-07:00

Numpy fast fourier transforms use FFTPack (written in Fortran) with optimized C glue code to Python. FFTPack standalone has been benched marked against FFTW, and FFTW wins by far. FFTW is even faster than GPU accelerated CUDA FFT for realtime sample sizes up to 16K. PyFFTW by Schroeder and Peterson is a ctypes binding to FFTW; in the case of small sample sizes typical for realtime analysis (1024), PyFFTW does not offer any speed up over Numpy's native fft, infact is appears to be 3x slower. Note that if dealing with much larger sample sizes PyFFTW would then beat Numpy FFTPack, especially since sample sizes over one million can then benifit from FFTW threading.

This RPython binding to FFTW is faster than both, about 8x faster than Numpy, and 24x faster than ctypes PyFFTW. Get the code here

iTaSC Pole Vector Free Rigging

2010-08-22T19:28:00.000-07:00

Blender now has a very powerful set of IK solvers: Spline IK, and simulation based IK (iTaSC). When iTaSC is used in `Simulation` mode it becomes very difficult to make an IK chain flip. This could greatly simplify the rigging and animation process if we can remove the need for a pole-vector object to control knee/elbow tilt. One of the problems in using a pole-vector is that it imposes a non-ideal flipping point, an arm or leg will have a large range of possible motion, flipping then becomes unavoidable past 180 degrees. Animators may have to resort to scripting to control the pole-vector or bone roll directly, but these hacks complicate animation blending in NLA or are cumbersome to use and setup.

Using iTaSC no hacks are required to reach almost 360 degrees of rotation. Simply by using two IK constraints, one for position and the other for rotation, is all that is needed for full elbow or knee tilt while keeping the optimal flipping point at 360 degrees. The interface may not lead us directly to this simple solution, the old pole-vector option remains available even though its not very useful combined with iTaSC. The correct steps are as follows:
1. From the Armature panel -> iTaSC options -> select `Simulation` mode (keep all the default options)
2. Go into pose-mode, create a position IK for the ankle, do not assign a pole-vector target
3. Pick the thigh bone, create another IK constraint, pick the ankle IK handle as the target
4. Set the constraint to use rotation, and only in the Y, and turn off position.
5. If your model faces -Y (the default in Blender) your leg will have flipped, rotate the IK handle 180 on the Y.
6. Test the leg by moving the handle, you should see it flip when moving forward and back,
this is because the X rotation of the handle will define where the monopole is located that iTaSC will flip around,
by relocating the monopole to 180 degrees from the leg's natural rest position,
we gain almost 360 degrees of flip-free movement.
7. Adjust the rotation of the handle in X to minimize the flipping,
some where between 45 to 90 degrees should give the best results.
8. After you have found the optimal rotation in X of the handle, go back to the constraint options and set the weight to 0.5,
this helps keep the response of the IK chain smooth when nearing 360 degrees.

Torso and Shoulder Setup:
Shoulder rigging and weighting is another area where many techniques have been tried, but most of these hacks are hard to setup, so it becomes a serious bottleneck for creating digital characters. The interaction of all the ribs, muscles, clavicle and shoulder-blades is far too complex to be modeled by a simple single chain spine with arms branching directly from it. The following approach instead uses IK to model the shoulder blades and stretch-to constraints to model the shoulders and chest. This setup can only work with bone-to-bone constraints because of the way Blender computes its DAG node graph, in other words you will get cyclic dependency errors trying to use bone-to-empty constraints.

Notes:
. Even if bone tips are perfectly snapped to the heads of their stretch-to targets, they will still move slightly when the constraint is applied.
. IK bone stretch scales opposite of stretch-to constraint. IK stretch gets larger as distance grows, while stretch-to maintains volume and thins.
. Stretch-to constraint when using a bone target allows for slider control between head and tail. IK lacks this option.
. iTaSC treats bone stiffness slightly different from legacy IK, stiffness of 0.99 is considered absolute and locked.
. iTaSC bone stretch is disabled if two IK constraints have overlapping bone influence.
. iTaSC not as compatible with other constraints as the legacy IK was. (locked-track was compatible with legacy IK)
. iTaSC has its own set of internal IK types: copy-pose and limit distance, with more comming in the future!
. Too many bones in an IK chain with stiffness of 0.99 can lead to jerking and unstable response.
. Bone shake due to overlapping IK is usally solved by lowering the constraint weights, good ranges are from 0.5 - 1.0

RPython callbacks from C

2010-08-15T23:00:00.000-07:00

It is possible to define an RPython function that is passed to a C function as a callback argument. The RPython function will then be invoked from C whenever an event causes it to trigger. Pyaudio never implemented the PortAudio async API, because it requires callback functionality and that may take a great amount of effort from the Python C API. From RPython is rather easy once we know the steps:
1. import llhelper from pypy.rpython.annlowlevel
2. define the function signature (argument types, return type) using lltype.FuncType
3. create a pointer to the signature lltype.Ptr( mysignature )
4. pass the pointer as an argument to rffi.llexternal when defining the wrapper
5. within the entrypoint use llhelper:
mycallback = llhelper(lltype.Ptr( mysignature ), my_rpython_function )
6. pass mycallback as an argument to the external C function

This excerpt is from RpyPortAudio 0.3:


mult16bits = 2**15
def stream_callback( ibuf, obuf, frameCount, info, flags, user ):
 t = time.time()
 for i in range(512):
  raw = ibuf[i]
  x=rffi.cast(lltype.Signed, raw)
  samp = math.sin( t + (float(i)/512.0) ) * mult16bits
  samp = int(samp) + x
  obuf[i] = rffi.cast(rffi.INT, samp)
 return rffi.cast(rffi.INT, 0)  # 0=continue, 1=complete, 2=abort

StreamCallbackTimeInfoPtr.TO.become( StreamCallbackTimeInfo )
stream_cb_signature = lltype.FuncType([RBufferPtr, RBufferPtr, rffi.INT, StreamCallbackTimeInfoPtr, rffi.INT, rffi.VOIDP], rffi.INT)
stream_callback_ptr = lltype.Ptr( stream_cb_signature )

OpenDefaultStream = rffi.llexternal( 'Pa_OpenDefaultStream', 
 [
  StreamRefPtr,      # PaStream** 
  rffi.INT,          # numInputChannels
  rffi.INT,          # numOutputChannels
  rffi.INT,          # sampleFormat
  rffi.DOUBLE,        # double sampleRate
  rffi.INT,          # unsigned long framesPerBuffer
  stream_callback_ptr,     #PaStreamCallback *streamCallback
  rffi.VOIDP,        #void *userData
 ], 
 rffi.INT,          # return
 compilation_info=eci,
)

def entrypoint():
 streamptr = lltype.malloc(StreamRefPtr.TO, 1,  flavor='raw')  # must have length 1
 userdata = lltype.nullptr(rffi.VOIDP.TO)
 callback = llhelper(lltype.Ptr( stream_cb_signature ), stream_callback)
 ok = OpenDefaultStream( streamptr, 2, 2, Int16, 22050.0, 512, callback, userdata )
 stream = streamptr[0]
 startok = StartStream( stream )
 time.sleep(10.0)

RPython FluidSynth Bindings

2010-08-15T17:58:00.000-07:00

PyFluidSynth by Nathan Whitehead and Bart Spaans is a ctypes binding to FluidSynth, a software synthesizer that can read SoundFont2 files and generate music in real-time. In terms of lines of code, this RPython binding using rffi is not much larger than the ctypes wrapper, less than 100 extra lines. However, in terms of performance the RPython binding is about 10x faster than the ctypes binding. FluidSynth v1.1.1 is required, the version that is in the Ubuntu Karmic repos is out of date and contains a bug, so you will need to download and compile the latest FluidSynth. RPyFluidSynth on google code.

One issue that came up creating this wrapper, if a struct is only declared in the header and not defined (or perhaps empty), then rffi_platform.Struct is not used. Instead the pointer is told to become a lltype.Struct directly.
_ptr = lltype.Ptr(lltype.ForwardReference())
_ptr.TO.become( lltype.Struct(name) )

RPython PortAudio Bindings

2010-08-13T05:51:00.000-07:00

The PyAudio package for Python2.x written by Hubert Pham, wraps PortAudio directly using the Python C API, this method is extremely verbose but gives much better performance than a ctypes based wrapper, and for audio performance is a big factor. Hubert's wrapper is no less than 2,500 lines of hand written C, and about 500 lines of Python code that provides a nice pythonic interface ontop of the C API. How does RPython compare? Nearly the entire PortAudio library can be wrapped in RPython in under 200 lines of code, the only thing missing here are: error codes, a few device options, and a nice pythonic API. As far as speed, my guess it is as good or better. Using rffi and lltypes is very low level so it might take more lines of code to encapsulate the binding into a higher level pythonic API, but this extra work is more than offset by not having to write any C. You can get rpyportaudio on google code here.

Interfacing RPython with C

2010-08-11T20:04:00.000-07:00

The documentation on how to interface RPython with C is rather limited, the extending doc mentions that `MixedModules` using rffi is the most advanced method available. The rffi document only provides a quick glance at how to use rffi.llexternal. The best place to get started is looking at the source code in rlib/rsdl/RSDL.py which binds RPython to SDL. What should be clear after reading RSDL.py is that PyPy provides a very direct and easy to understand interface for C; that should also provide the highest possible performance.

The source code in rffi_platform.py (found in pypy/rpython/tool) is very interesting, it generates dynamic C code that it compiles to get information about the C code we are trying to wrap, for example if you had used the wrong name in a struct it will generate an error. Using rffi_platform different C types can be defined, such as structs, constant integers; these are then put into a special container class called CConfig, which is then parsed by rffi_platform.configure(CConfig) and wrappers returned. After we have the wrappers we must tell any pointers we had previously used in the CConfig that they `become` those objects, MyPointer.TO.become(MyStruct).

RSDL that is included in PyPy is incomplete and lacks wrappers for Joystick, the code below wraps SDL Joystick. Full source code is available here.



eci = get_rsdl_compilation_info()
## wrapper for rffi.llexternal just to shorten the call
def external(name, args, result): return rffi.llexternal(name, args, result, compilation_info=eci)

JoystickPtr = lltype.Ptr(lltype.ForwardReference())
JoyAxisEventPtr = lltype.Ptr(lltype.ForwardReference())
JoyBallEventPtr = lltype.Ptr(lltype.ForwardReference())
JoyButtonEventPtr = lltype.Ptr(lltype.ForwardReference())
JoyHatEventPtr = lltype.Ptr(lltype.ForwardReference())


class CConfig:
 _compilation_info_ = eci
 Joystick = platform.Struct('SDL_JoyAxisEvent', [])  # just and ID, struct contains nothing
 # rsdl/constants.py already defines SDL_JOYAXISMOTION, SDL_JOYBALLMOTION, etc..
 JoyAxisEvent = platform.Struct('SDL_JoyAxisEvent',
   [('type', rffi.INT),
   ('which', rffi.INT),
   ('axis', rffi.INT),
   ('value', rffi.INT)])


CONSTS = 'INIT_JOYSTICK QUERY ENABLE IGNORE PRESSED RELEASED'
for name in CONSTS.split():
 name = name.strip()
 if name:
  ci = platform.ConstantInteger('SDL_%s' %name)
  setattr( CConfig, name, ci )
globals().update(platform.configure(CConfig))

JoystickPtr.TO.become(Joystick)
JoyAxisEventPtr.TO.become(JoyAxisEvent)

JoystickUpdate = external('SDL_JoystickUpdate', [], lltype.Void)
NumJoysticks = external('SDL_NumJoysticks', [], rffi.INT)
## CCHARP seems to stand for C char pointer ##
JoystickName = external('SDL_JoystickName', [rffi.INT], rffi.CCHARP)
JoystickOpen = external('SDL_JoystickOpen', [rffi.INT], JoystickPtr)
JoystickOpened = external('SDL_JoystickOpened', [rffi.INT], rffi.INT)

JoystickEventState = external('SDL_JoystickEventState', [rffi.INT], rffi.INT)

def handle_event( etype, event ):
 if etype == RSDL.JOYAXISMOTION:
  p = rffi.cast( JoyAxisEventPtr, event )
  axis = rffi.getintfield(p, 'c_axis')
  value = rffi.getintfield(p, 'c_value')
  print 'axis: %s value: %s' %(axis, value)



def poll(loops=1000):
 event = lltype.malloc(RSDL.Event, flavor='raw')
 try:
  i = 1
  while i < ok =" RSDL.PollEvent(event);" ok =" rffi.cast(lltype.Signed,">= 0
   if ok > 0: c_type = rffi.getintfield(event, 'c_type'); handle_event( c_type, event )
   time.sleep(0.01)
   i += 1
 finally: lltype.free(event, flavor='raw')

def test():
 assert RSDL.Init(INIT_JOYSTICK | RSDL.INIT_VIDEO ) >= 0
 num = NumJoysticks(); print 'number of joysticks/gamepads: %s' %num
 JoystickEventState( RSDL.ENABLE )
 if num:
  joy = JoystickOpen( 0 )
  numaxes = JoystickNumAxes( joy ); print 'number of axes: %s' %numaxes
  numbut = JoystickNumButtons( joy ); print 'number of buttons: %s' %numbut
  poll()

if __name__ == '__main__':
 from pypy.translator.interactive import Translation
 t = Translation( test )
 t.annotate(); t.rtype()
 entrypoint = t.compile_c()
 entrypoint()

RPython Open Sound Control

2010-08-10T18:10:00.000-07:00

RPython OSC is now on google code here. In an idealized test (without socket read/write) it performs about 10x faster than the pure python version of OSC by V2Labs. PyOSC is fast because it uses CPython's struct module which is written in C, but still there is about a 10x cost in calling a C function from Python, which is eliminated by RPython. RpyOSC uses the same API as PyOSC where it can, the differences are noted in the source code.

RPython Struct

2010-08-10T17:59:00.000-07:00

There is no drop in replacement for the struct module in RPython. In Rlib there is a "rstruct" folder, but only "unpack" is implemented with a warning in the header that it is incomplete; what it aparently lacks is proper endian support. There was never any pure RPython example made for how to implement "pack", there is however one example how to implement pack/unpack for the interpreter level. Looking at those examples it is clear we need to use the FormatIterator found in rlib/rstruct. The runpack example uses meta-programming to generate tuples for returning different types, but this seems like overkill, at least it is in the case of OSC where we know excatly what types we are dealing with. The two classes below (RStructUnpacker and RStructPacker) are simple and restricted RPython replacements for the struct module. They can not be used as drop in replacements; the Packer expects to be packing the same type, and the Unpacker does not return what it has unpacked and instead sorts it into lists by type.


class RStructUnpacker( pypy.rlib.rstruct.formatiterator.FormatIterator):
 def __init__( self, fmt, data ):
  self.strings = []
  self.ints = []
  self.floats = []
  self.longs = []
  self.input = data
  self.inputpos = 0
  self.interpret( fmt )

 def operate(self, fmtdesc, repetitions):
  if fmtdesc.needcount:
   fmtdesc.unpack(self, repetitions)
  else:
   for i in range(repetitions):
    fmtdesc.unpack(self)
 operate._annspecialcase_ = 'specialize:arg(1)'
 _operate_is_specialized_ = True

 def align(self, mask):
  self.inputpos = (self.inputpos + mask) & ~mask


 def read(self, count):
  end = self.inputpos + count
  if end > len(self.input): raise SyntaxError
  s = self.input[self.inputpos : end]
  self.inputpos = end
  return s


 @specialize.argtype(1)
 def appendobj( self, ob ):
  if isinstance(ob, str): self.strings.append( ob )
  elif isinstance(ob, int): self.ints.append( ob )
  elif isinstance(ob, float): self.floats.append( ob )
  #elif isinstance(ob, long): self.longs.append( ob )  isinstance(ob, long) not RPython, how do we check for long?


class RStructPacker(pypy.rlib.rstruct.formatiterator.FormatIterator):
 # not a drop in replacement for struct.pack, but as close as RPython can get (easily).
 def __init__(self, fmt, strings=[], ints=[], floats=[], longs=[], unicodes=[], uints=[] ):
  self.strings = strings
  self.ints = ints
  self.floats = floats
  self.longs = longs
  self.unicodes = unicodes
  self.uints = uints
  self.args_index = 0
  self.result = []      # list of characters
  self.interpret( fmt )

 def operate(self, fmtdesc, repetitions):
  if fmtdesc.needcount:
   fmtdesc.pack(self, repetitions)
  else:
   for i in range(repetitions):
    fmtdesc.pack(self)
 operate._annspecialcase_ = 'specialize:arg(1)'
 _operate_is_specialized_ = True

 def align(self, mask):
  pad = (-len(self.result)) & mask
  for i in range(pad):
   self.result.append('\x00')

 def finished(self): pass

 def accept_str_arg(self):
  assert self.strings
  a = self.strings[ self.args_index ]
  self.args_index += 1
  return a
 def accept_int_arg(self):
  assert self.ints
  a = self.ints[ self.args_index ]
  self.args_index += 1
  return a
 def accept_float_arg(self):
  assert self.floats
  a = self.floats[ self.args_index ]
  self.args_index += 1
  return a
 def accept_unicode_arg(self):
  assert self.unicodes
  a = self.unicodes[ self.args_index ]
  self.args_index += 1
  return a
 def accept_uint_arg(self):
  assert self.uints
  a = self.uints[ self.args_index ]
  self.args_index += 1
  return a

Meta-Programming Part2: rbpy Internals

2010-08-07T19:35:00.000-07:00

RNA Introspection
Blender's bpy API is generated by RNA introspection; and this information is still preserved at the Python-level, each object either has a bl_rna attribute or a get_rna() function that contains all the C-level introspection information. Knowing the names and types of all function arguments and their returns allows for more efficient remote wrappers that do less data marshaling because they know what type the server is sending them.

Blender objects are not passed directly to the class/function wrapper generator; instead, they are first converted into an intermediate class during introspection because some special-case hacks must be applied. The intermediate class "genRNA" is then passed to the wrapper generator that packages the information and gets it ready for pickling. Pickling saves the user from having to run introspection every time they run their script, and also is the only workaround for transferring data from Python3 back to Python2 (Blender uses Python3 while RPython is a subset of Python2).

When rbpy is launched again as a subprocess this time from Python2, it loads the introspection pickle and generates the final remote wrapper classes. The __init__ of all objects uses *args so it can take any number of arguments or types. Normally this is not RPython compatible because a tuple can not be iterated over, to workaround this we use additional meta-programming to unroll the *args in a RPython safe manner, the technique is detailed here.

Below is the function that does the job of RNA introspection from a live blender object and generation of the intermediate class.


def reflect_RNA_instance( ob, classpath=None ):
 class genRNA(object):
  if isinstance(ob,bpy.types.Object): type = ob.type
 genRNA.__name__ = sn = rpython_shadow_name( ob, classpath )
 genRNA._class_name_ = sn
 if classpath: genRNA._bpy_class_name_ = classpath
 else: genRNA._bpy_class_name_ = ob.__class__.__module__+'.'+ob.__class__.__name__

 if ob.__class__.__name__ == 'bpy_ops_submodule': # bpy.ops..
  for opname in dir(ob):
   func = getattr( ob, opname )
   rna = func.get_rna()
   args = []
   for prop in rna.bl_rna.properties:
    if prop.identifier == 'rna_type': continue
    args.append( reflect_RNA_prop( prop ) )
   d = lambda:()
   d._argument_info = args
   d._return_info = None
   setattr( genRNA, opname, d )

 elif ob.__class__.__name__=='bpy_prop_collection': # bpy.data..
  genRNA.length = 0  # these should not be a special case and all GET funcs should assign, can setattr work with nonconcretes?
  genRNA.GET_length = d = lambda:(); d._return_info = int
  d = lambda:(); d._return_info = (str,)
  setattr( genRNA, 'keys', d )
  d = lambda:(); d._return_info = object
  setattr( genRNA, 'get', d )
  d = lambda:(); d._return_info = object
  setattr( genRNA, 'new', d )
  d = lambda:(); d._return_info = (object,)
  setattr( genRNA, 'values', d )

 elif ob.__class__.__name__ == 'vector':
  genRNA.vec = [.0,.0,.0] # specialcase, use v.vec = v.to_tuple()
  genRNA.angle = d = lambda:(); d._return_info = float
  genRNA.copy = d = lambda:(); d._return_info = object
  genRNA.cross = d = lambda:(); d._return_info = object
  genRNA.difference = d = lambda:(); d._return_info = object
  genRNA.dot = d = lambda:(); d._return_info = float
  genRNA.lerp = d = lambda:(); d._return_info = object
  genRNA.negate = d = lambda:(); d._return_info = object
  genRNA.normalize = d = lambda:(); d._return_info = object
  genRNA.project = d = lambda:(); d._return_info = object
  genRNA.reflect = d = lambda:(); d._return_info = object
  genRNA.to_tuple = d = lambda:(); d._return_info = (float,)
  for p in 'length magnitude x y z w xyz'.split():
   dummy = lambda:(); dummy._return_info = []; dummy._argument_info = float
   setattr( genRNA, 'SET_%s' %p, dummy )
   d = lambda:(); d._return_info = float; d._argument_info = None
   setattr( genRNA, 'GET_%s' %p, d )

 else:
  for prop in ob.bl_rna.properties:
   #if not prop.is_readonly:
   attr = getattr(ob, prop.identifier)
   if hasattr( genRNA, prop.identifier ) and prop.identifier != 'type':
    print( 'this should never happen', prop.identifier )
    raise SyntaxError
   dummy = lambda:()
   dummy._argument_info = ai = reflect_RNA_prop( prop )
   dummy._return_info = [] # do not return from a SET
   setattr( genRNA, 'SET_%s' %prop.identifier, dummy )
   d = lambda:()
   d._argument_info = None
   d._return_info = ri = reflect_RNA_prop( prop, attr )
   setattr( genRNA, 'GET_%s' %prop.identifier, d )
   #if prop.identifier == 'location': raise

  for bfunc in ob.bl_rna.functions:
   if hasattr( genRNA, bfunc.identifier ) or bfunc.identifier=='select': # what is this select bug? TODO check
    print( 'this should never happen', bfunc.identifier )
    raise SyntaxError
   args = []
   returns = []
   for prop in bfunc.parameters:
    if prop.use_output: returns.append( reflect_RNA_prop( prop ) )
    else: args.append( reflect_RNA_prop( prop ) )
   d2 = lambda:()
   d2._argument_info = args
   d2._return_info = returns
   setattr( genRNA, bfunc.identifier, d2 )
 return genRNA

rbpy - Remote Blender Proxy Objects

2010-08-07T00:41:00.000-07:00

The rbpy API (now on google code) wraps Blender's own bpy API in a way that is optimized for remote access and speed, this means that existing scripts must be adapted to run remotely. Passing entire objects over a pipe or socket is very expensive, so this API tends to be very verbose and explicit about what data is read and written per object. The API is also RPython compatible, so compiling to C is an option, this is ideal for programs that do heavy computation but may only need occasionally talk to Blender. It is more work to write RPython compliant code, but we can first prototype our program quickly in normal Python and later add the typing information required for RPython, if maximum speed is required.

Below is Blender's native API. This example only does the most basic thing, move a few vertices on the default cube, and change the camera lens setting:


def bpy_example():
for ob in bpy.data.objects:
 if ob.type=='MESH':
  if ob.data.verts:
   for i,vert in enumerate(ob.data.verts):
    vert.co.x += i*0.5
 elif ob.type=='CAMERA':
  ob.data.lens = 80.0

The Remote API

1. no nested modules: bpy.data.objects becomes bpy_data_objects
2. no dictionary or indexing or iterable objects, objects['Cube'] becomes objects.get('Cube')
3. no dynamic attributes, ob.location becomes ob.GET_location and ob.SET_location
4. functions that return objects are always wrapped by a container
a) if not RPython access single objects by con.value, and for a list con.all
b) if you are doing RPython you access the object from the container by lists with special tag names

The code below does the same thing as above but is written in the remote API. Note that it is not yet RPython compatible, but runs fine in normal Python.



def remote_example():
objects = bpy_data_objects()
container = objects.values()  # objects is not iterable, so instead we call values()
for o in container.meshes:
 mesh = o.GET_data().value # untyped (not RPython)
 verts = mesh.GET_verts().value
 # we can not use len() on this object, GET_length is a special case for collections
 n = verts.GET_length()
 if n:
  for i,vert in enumerate( verts.values().all ):
   debug( str(vert) )
   co = vert.GET_co().value
   co.vec = co.to_tuple()  # co.vec is local not remote, note to_tuple returns a list not a tuple
   co.vec[0] += float(i) * 0.5
   co.SET_x( co.vec[0] )
for cam in container.cameras:
 c = cam.GET_data().value
 c.SET_lens( 80.0 )

RPython Static Typing

If you try to compile the above code you will get this error:
File "pypy/pypy/annotation/unaryop.py", line 581, in next
s_item = itr.s_container.getanyitem()
AttributeError': 'SomeObject' object has no attribute 'getanyitem'
.. v1 = next(v0)
.. '(rbpy:693)remote_example'

The code can not be translated because the dynamic variables are untyped, to make it RPython we only need to change the way we access it from the container that automatically types what it contains and sorts each type into their own list. This by no means makes all of your code RPython, that is still up to you, it just means the API is RPython compatible. A good place to getting started with RPython is to read how the container works.

Below is the RPython version:



def remote_rpy_example():
objects = bpy_data_objects()
container = objects.values()
for o in container.meshes:
 mesh = o.GET_data().meshes_data[0]
 verts = mesh.GET_verts().collections[0]
 n = verts.GET_length()
 if n:
  vcon = verts.values()
  for i,vert in enumerate( vcon.verts ):
   co = vert.GET_co().vectors[0]
   co.vec = co.to_tuple()
   co.vec[0] += float(i) * 0.5
   co.SET_x( co.vec[0] )

for cam in container.cameras:
 c = cam.GET_data().cameras_data[0]
 c.SET_lens( 80.0 )

RPython - Part3: Inheritance Rules

2010-08-05T18:28:00.000-07:00

`The inheritance rules are as follows: the union of two SomeInstance annotations is the SomeInstance of the most precise common base class. If an attribute is considered (i.e. read or written) through a SomeInstance of a parent class, then we assume that all subclasses also have the same attribute, and that the same annotation applies to them all (so code like return self.x in a method of a parent class forces the parent class and all its subclasses to have an attribute x, whose annotation is general enough to contain all the values that all the subclasses might want to store in x). However, distinct subclasses can have attributes of the same names with different, unrelated annotations if they are not used in a general way through the parent class.`

The above quote from the PyPy documentation is critical in understanding how to write proper RPython code, it is not found in the coding guide subsection on RPython, but instead in the translation document, don't miss the subsection on the annotation pass, which helps explain what "someobjectness" is all about - basically you want zero percent "someobjectness" when you translate.

Most Precise Common Base Class?
What excatly is SomeInstance and the most precise common base class? Above we saw that like-named methods with different signatures can be called if their type is proven by assertion first. Without this assertion, only methods with matching signatures can be called. SomeInstance is created when a function returns any number of different subclasses, the calling block is then unsure of which it is dealing with, and the flow graph will warn you it can not follow the call.

Assertion is block scoped flowing downstream, you can not call another function that asserts the type (below external_assert) and then expect the flow graph to know the type from the calling block. It is not valid either to assert the type after wards, even if you do not reassign the variable within that scope.



def external_assert( ob ):
 if ob.__class__ is TA: assert isinstance(ob, TA)
 elif ob.__class__ is TB: assert isinstance(ob, TB)

def entrypoint_external_assert_fails( outside ):
 ta = TA()
 tb = TB()
 con = Container( ta, tb )
 a,klass = con.get(outside)
 a.whoami()
 if a.__class__ is TA:
  external_assert( a )
  a.diff_num_args( 1,2 )
 elif a.__class__ is TB:
  external_assert( a )
  a.diff_num_args( 1,2,3 )

 ## asserting after the function calls wont help either ##
 if a.__class__ is TA: assert isinstance(a, TA)
 elif a.__class__ is TB: assert isinstance(a, TB)
 print 'assert by func test complete'

SomeInstance can be passed through numerous functions and at any later point be typed (by assertion) to convert it back into its real subclass and then saved into a list unique for that type. Later when recalled from the list and the previously asserted instance remains its proper subclass. The flow graph is smart enough to know that after the assertion, subclass X was put into this list, and all code that comes after references that list will get the correct subclass. Note that if we put another subclass into the list, they all revert into SomeInstance. This downstream-flow-style of typing is likely to confuse programmers coming from statically typed languages (like C++) where types are always declared first; its also likely to confuse Python programmers who are not used to having to worry about typing.

The Casting Container:

The class CastContainer encapsulates casting of objects and storing them in a list unique to their type. Note that CastContainer expects all objects to all share the same base class if they pass through the add method. If however you need objects of differing base classes, simply define a new add method with a different name, or change add to accept keyword arguments that default to None and represent all known base classes.


class CastContainer(object):
 def __init__(self):
  self.SomeInstances = []
  self.type1 = []
  self.type2 = []

 def add( self, o ):     # this is safer
  self.SomeInstances.append( o )
  if o.__class__ is TA:
   assert isinstance(o,TA)
   self.type1.append( o )
   #getattr( self, TA.tag ).append( o )  # this works to
  else:
   assert isinstance(o,TB)
   self.type2.append( o )

 def call_all( self, func, *args ):  
  if args:
   for a in self.SomeInstances: getattr(a,func)( args )
  else:
   for a in self.SomeInstances: getattr(a,func)()

def entrypoint_castcontainer( outside ):
 ta = TA()
 tb = TB()
 con = CastContainer()
 con.add( ta )
 con.add( tb )
 a = con.type1[0]
 b = con.type2[0]
 a.diff_num_args( 1,2 )
 b.diff_num_args( 1,2,3 )
 con.call_all( 'whoami' )
 print 'this also works'
 for a in con.SomeInstances: a.whoami()
 print 'presorting test'

RPython Part2

2010-08-05T01:26:00.000-07:00

There are at least two cases where runtime variables can be problematic in RPython with subclasses that have methods with the same name, and 1. return different types, or 2. like-named methods taking different number of arguments - in other words having a different signature. The solution requires not only a if/else block, but also a assert statement that proves type. Note that proving the type in the container's get function is of no help. If the variable outside is known and concrete at translation time then everything works, if however it is passed in from CPython (as it is here) or read from a pipe or socket it is no longer concrete and translation fails.


class T(object): pass

class TA( T ):
 def whoami(self): print 'i am instance of TA'
 def incompatible_return( self ): return 100
 def diff_args( self, a,b,c ): print 'TA: ', a, b, c
 def diff_num_args( self, a,b ): print 'TA: ', a, b

class TB( T ):
 def whoami(self): print 'i am instance of TB'
 def incompatible_return(self): return 'string'
 def diff_args( self, x='1', y='y', z='z' ): print 'TB: ', x, y, z
 def diff_num_args( self, a,b,c ): print 'TA: ', a, b, c

class Container(object):
 def __init__(self, *args):
  self.items = []
  for item in list(args): self.items.append( item )
 def get( self, index ):
  a = self.items[index]
  if index==0:
   assert isinstance(a, TA)
   return a, TA
  else:
   assert isinstance(a, TB)
   return a, TB

#File "pypy/pypy/translator/c/node.py", line 998, in _python_c_name
# Exception: don't know how to simply render py object: 100
def entrypoint_incompatible_fails( outside ):
 ta = TA()
 tb = TB()
 con = Container( ta, tb )
 a,klass = con.get(outside)
 assert isinstance(a, klass)  # too bad this wont work
 b = a.incompatible_return()
 print b

## this works, so SomeObject subclasses method calls are fine as long as the number of args it the same and the return is the same type.
def entrypoint_diffargs_works( outside ):
 ta = TA()
 tb = TB()
 con = Container( ta, tb )
 a,klass = con.get(outside)
 a.diff_args( 1,2,3 )
 a.whoami()

## assert is required ##
def entrypoint_branching_fails( outside ):
 ta = TA()
 tb = TB()
 con = Container( ta, tb )
 a,klass = con.get(outside)
 if a.__class__ is TA:
  a.diff_num_args( 1,2 )
 elif a.__class__ is TB:
  a.diff_num_args( 1,2,3 )


def entrypoint_branching_works( outside ):
 ta = TA()
 tb = TB()
 con = Container( ta, tb )
 a,klass = con.get(outside)
 if a.__class__ is TA:
  assert isinstance( a, TA )  # this is required
  a.diff_num_args( 1,2 )
 elif a.__class__ is TB:
  assert isinstance( a, TB )  # this is required
  a.diff_num_args( 1,2,3 )


PATH2PYPY = 'pypy'
sys.path.append(PATH2PYPY)  # assumes you have pypy dist in a subfolder, you may need to rename this pypy-trunk

def tests( outside ):
 entrypoint_branching_works(outside)

from pypy.translator.interactive import Translation
t = Translation( tests )
t.annotate([int]); t.rtype()
f = t.compile_c()
f(0)
f(1)
print( 'end of program' )

Meta-Programming in RPython

2010-08-03T01:50:00.000-07:00

What is Restricted Python?

Its hard to find a good definition, mainly because there is no formal definition. RPython was born as a side effect of the PyPy interpreter needing a way to compile itself. Since then it has become a general purpose language, but apparently has not been written about much other than a few academic papers [1], [2]. Meta-programming is RPython most exciting feature, more on that below.

Language Restrictions/Definition:
1. Lists and Dicts must contain a compatible type.
(objects with a common base class are compatible)
2. Function arguments types must not be changed after the first call, each call must be consistent with the others in the ordering of types.
(this also applies to function returns)
3. Subclasses must redefine functions that interact with an attribute they have made a new type.*
4. String and char are different, any string of length 1 becomes a char. (some builtin functions accept only a char)
5. Tuples may have incompatible types, but can not be iterated over, yet. (the error messages suggest the iteration limitation is going away)
6. Only __init__ and __del__ are allowed, so no custom attribute access or operator overloading.
7. Globals are considered constants (use singletons for global changeable state)
8. No runtime definition of functions or classes.
9. Slicing can not use negative indexes except for [:-1]
10. Some builtin functions requires literals, like getattr, for example:
valid:
getattr(o,'x')
invalid:
arg = 'x'
getattr( o, arg )

There are a few other rules and exceptions not listed above, but those are small and the RPython translator/compiler is going to give you clear errors when you violate them. Getting started with RPython it is easy to make a mistake somewhere and violate rules 1-3, the errors you will get from breaking them are a bit cryptic as well:

a. Exception: don't know how to simply render py object:
b. pypy.rpython.error.TyperError: don't know how to convert from to
c. AttributeError: no field 'll_newlist'
d. pypy.rpython.error.TyperError: reading attribute '__init__': no common base class for [type]

*Rule 3 is unusual and easy to overlook, it means we must be careful with functions defined in our base class that interact with attributes we have redefined in subclasses that are of a new type. In other words, a function defined in the base class expects its the attributes of self to always have those fixed types, but if the subclasses changes the type, the function breaks. In unrestricted Python we would normally want to put as many shared functions in the base class as possible to avoid code duplication, rule 3 turns this upside down. Consider the following where we use wrapper objects for generic types and note that we have put the unwrap function in each of the subclasses.



class Type1(object): pass
class Type2(object): pass

class Abstract(object):
      def __init__(self):        # be careful with init, do not try to define defaults for what will have different types in subclasses!
            #self.x = 'never define what x is in the base class'
            self.y = 'this is safe'
      def failure(self): self.x = 1.0

class O(object):
      def __init__(self, arg='string'): self.a = arg

class X( Abstract ):
      def __init__(self):
            Abstract.__init__(self)
            self.x = Type1()
      def unwrap(self): return self.x

class Y( Abstract ):
      def __init__(self):
            Abstract.__init__(self)
            self.x = Type2()
      def unwrap(self): return self.x

class Z( Abstract ):
      def __init__(self):
            Abstract.__init__(self)
            self.x = 10.0
      def unwrap(self): return self.x

class W( Abstract ):
      def __init__(self):
            Abstract.__init__(self)
            self.x = O
      def unwrap(self): return self.x
      def new_instance(self, arg): return self.x(arg)

def test_subclasses_fails():
      c = Abstract()
      c.failure()    # this breaks because the type can not be known from the base class
      a = X()
      b = Y()

def test_subclasses_works():
  ab=Abstract()
  a = X()
  b = Y()
  c = Z()
  lst = [a,b]    # sharing the same base class means they can co-exist in a list
  for item in lst: print item
  print a.x
  print b.x
  print c.x
  o = W().x()
  print o
  print a.unwrap()
  print b.unwrap()
  o2 = W().new_instance( 'hello world' )
  print o2.a
  print 'test shared complete'

Another case that can easily lead to rule breaking is when dealing with *args which is a tuple, and since tuples can store incompatibles, we may be tempted to use it to pass variable amounts of incompatible types; but they can not be iterated over, and casting args to a list will not work either because lists must contain only compatible types. Tuple indexing must also be done with a literal constant as well, so for loop will fail:
def func( *args ):
for i in range(len(args)):
a = args[i]

Above fails, so the only way to get at items in args is to index each one with a literal like this, not pretty!:
n = len(args)
if n > 1: args[0]
if n > 2: args[1]
if n > 3: args[2]

Meta-Programming

If we have to code that way, then it seems like we should give up trying to pass variable numbers of incompatible types. However, unlike many other languages which are parsed only from source code, RPython uses live objects and introspection; and before compiling we have the chance to generate classes, modify functions, create new globals, and more, all from unrestricted Python. Using meta-programming we can easily bend some of the restrictions of RPython, in this case we are going to unroll the loop and inline valid RPython code.


STAR_TYPES = 'bool int float str tuple list Meta ID'.split()
ARGUMENT_SEP = '~'
class ID(object):
      def __init__(self,value='undefined'): self.value = value

class Meta(object): pass

class SimplePack( Meta ):        # would be useful to turn this into a minipickler
  def init_head(self):
    self.ID = '0'
    self._init_string = ''
        
  def init_bool(self, v ): self._init_string += '%s%s' %(v, ARGUMENT_SEP)
  def init_int(self, v ): self._init_string += '%s%s' %(v, ARGUMENT_SEP)
  def init_float(self, v ): self._init_string += '%s%s' %(v, ARGUMENT_SEP)
  def init_str(self, v ): self._init_string += '"%s"%s' %(v, ARGUMENT_SEP)
  def init_tuple(self, v ): self._init_string += '%s%s' %(v, ARGUMENT_SEP)
  def init_list(self, v ): self._init_string += '%s%s' %(v, ARGUMENT_SEP)
  def init_Meta(self, v ): self._init_string += '@%s%s' %(v.ID, ARGUMENT_SEP); print 'got meta'
  def init_ID(self, v ): self.ID = v.value; print 'got id'

The SimplePack subclass above is going to handle each possible type that may be passed in *args from our generated function. gen_star_func and gen_switch_block are going to create the unrolled function for us, that can be very large depending on what maxitems is set to as we will see below.


def gen_switch_block( prefix, indent, index ):
  indent += '  '
     r = ''
     for type in STAR_TYPES:
           if not r:
                 r += '%sif isinstance( args[%s], %s ): self.%s_%s(args[%s])\n' %(indent,index,type, prefix,type,index)
           else:
                 r += '%selif isinstance( args[%s], %s ): self.%s_%s(args[%s])\n' %(indent,index,type, prefix,type,index)
  r += '%selse: print "unknown type", args[%s]\n' %(indent,index)
  return r

def gen_star_func(  name, handler_prefix='init', head=None, tail=None, maxitems=16 ):
  ident = '  '
  if head: body = '  self.%s\n' %head
  else: body = ''
  body += '  n = len(args)\n'
  for i in range( maxitems ):
         body += '%sif n > %s:\n%s' %(ident, i, gen_switch_block(handler_prefix, ident,i) )
         ident += '  '
  if tail: body += '\n  ' + tail
  e = 'def star_func(self, *args):\n' + body
  print e
  exec( e )
  star_func.func_name = name
  return star_func

The output of gen_star_func simply checks for each possible type, and forwards it to a handler. In terms of speed there should not be a big expense, since the next switch block is only executed if the length of *args is greater, we lose some memory but it is reasonable as long as maxitems is not too high. As you can see below the output of gen_star_func greatly helps keeps our code maintainable not having to copy and paste into every function where we want to use *args and variable types.


def star_func(self, *args):
    self.init_head()
    n = len(args)
    if n > 0:
        if isinstance( args[0], bool ): self.init_bool(args[0])
        elif isinstance( args[0], int ): self.init_int(args[0])
        elif isinstance( args[0], float ): self.init_float(args[0])
        elif isinstance( args[0], str ): self.init_str(args[0])
        elif isinstance( args[0], tuple ): self.init_tuple(args[0])
        elif isinstance( args[0], list ): self.init_list(args[0])
        elif isinstance( args[0], Meta ): self.init_Meta(args[0])
        elif isinstance( args[0], ID ): self.init_ID(args[0])
        else: print "unknown type", args[0]
        if n > 1:
            if isinstance( args[1], bool ): self.init_bool(args[1])
            elif isinstance( args[1], int ): self.init_int(args[1])
            elif isinstance( args[1], float ): self.init_float(args[1])
            elif isinstance( args[1], str ): self.init_str(args[1])
            elif isinstance( args[1], tuple ): self.init_tuple(args[1])
            elif isinstance( args[1], list ): self.init_list(args[1])
            elif isinstance( args[1], Meta ): self.init_Meta(args[1])
            elif isinstance( args[1], ID ): self.init_ID(args[1])
       else: print "unknown type", args[1]
            if n > 2:
                 ...(to maxitems)


def gen_class( name, base=Meta, items={} ):
    cls = types.ClassType(str(name), bases=(base,), dict=items)
    globals().update( {name:cls} )
    return cls

def gen_metas( names ):
    generated = []
    init = gen_star_func( '__init__', handler_prefix='init', head='init_head()' )
    for name in names.split():
        items = {'__init__':init}
        cls = gen_class( name, base=SimplePack, items=items )
        generated.append( cls )
    return generated
GEN_METAS = gen_metas( 'Meta1 Meta2 Meta3' )

def test_meta():
    m1 = Meta1()
    myid = ID('myid')
    print myid
    m2 = Meta2('a', 'b', 1.0, 'string', m1, myid )
    print m2._init_string
    m3 = Meta3( m1, m2 )
    print m3._init_string

The test above test_meta takes the variable argument types and packs them into a string that could be sent over a pipe or socket for communication with another process.

To run these tests you need to download the pypy source code, and set PATH2PYPY to where pypy is.
Below the tests function is the pypy entry point, to run the different tests above uncomment test_*
You can download the source code for this whole demo here.


PATH2PYPY = 'pypy'
sys.path.append(PATH2PYPY)        # assumes you have pypy dist in a subfolder, you may need to rename this pypy-trunk

def tests( outside ):
    #test_subclasses_fails()    
    #test_subclasses_works()
    test_meta()

from pypy.translator.interactive import Translation
t = Translation( tests )
t.annotate([str]); t.rtype()
f = t.compile_c()
f('from the outside')

print( 'end of program' )

Beta2: Physics, Video Playback, Wiimote

2009-07-19T09:34:00.000-07:00

Above: Pyppet running under WinXP

Pyppet Alpha Test

2009-04-09T00:18:00.000-07:00