Toolkit for creating visualization.
Primitive shapes, positioning, lighting etc.
3D accelerated. (OpenGL rendering available.)
Both web and desktop friendly.
An application framework. No design assumptions.
Processing provides you with a canvas and powerful
primitives, but is in no way a “framework” like Shoes or
IMHO, processing is less quirky that the other popular
Ruby GUI toolkits.
Using processing eﬀectively requires design eﬀort
speciﬁc to your application.
A general GUI framework
A main application/rendering/animation loop that
CPU intense stuﬀ in separate threads to keep rendering
I/O (such as network and disk access) in separate
threads to prevent render loop from blocking.
HID events arrive asynchronously and outside of the
rendering loop. Thread safety a must!
`sudo gem install ruby-processing`
Ruby bindings to processing.
Comes bundled with a version of jruby. You do not
need a separate jruby installation.
`rp5 watch my_sketch.rb` to run your app.
Best API documentation from processing.org. (Java)
Great 3D use cases.
Data visualization: many things make more sense in
a 3D world, since we live in one and all.
Simulation: real or non-real-time execution.
Computation sometimes distributed across the tubes
with local visualization.
Gaming: real-time visuals with asynchronous state I/
O, as well as asynchronous input, graphics and audio.
Underutilized: several Positioning/
high learning curves. Orientation: Tracking
where everything is at a
Math: strong spatial given point in time.
reasoning skills are a
must. Input: click detection
and other HID.
sometimes need lots of Collision detection.
CPU before rendering.
`rp5 run form/brick_tower.rb`
`rp5 run typography/kinetic_type.rb`
Important missing stuff.
Camera position and object creation position do not
need to be the same. (The camera is ﬁxed in the 3D
No sophisticated movement or input methods.
Everything is in the animation (“main”) thread. This
does not scale for real applications.
Rendering is based on CPU time, not wall clock time.
Physics should be the same against a wall clock
regardless of CPU speed.
No I/O. All real-world apps have I/O.
Let’s build something cool!
A star ﬁeld simulator Behave according to
and twitter feed reader. wall-clock time, even
on a crappy system.
All visible objects have
their own thread, and First person shooter-
can execute arbitrary style movement.
code such as I/O and Keyboard and mouse
heavy computation. both act on wall-clock
(Implausible on the 1.8 time.
MRI. JVM FTW!) execution
parallelization is not
needed for most
games, but is useful to
distribute CPU load
Modeling the system.
The universe is a giant cube (the “clipping plane”).
The sun is stationary with start whizzing by it.
Camera position in discrete X, Y, Z integers.
Orientation as a vector and rotation.
Starting position and velocity (speed + direction)
for each star.
Stars get “recycled” when they leave the clipping
Every star has a thread.
Each star instance has its own thread that updates
its own state based on wall-clock time. It calculates its
own state when it can.
Stars move according to their own parameters. (We
could make them talk to each other, too.)
Let’s test our model in a simple ruby script..
Now let’s use ruby-
processing to visualize it.
Callbacks: setup and draw.
Create our models and start the rendering loop.
Finally, we’ll add control.
Callbacks: key_pressed, key_released, mouse_dragged,
Math: calculate ∆translation and ∆rotation for camera
on each render based on ∆time.
Move: apply movement to the camera on each draw.
Let’s add some I/O.
Bundled twitter gem dependent on native C code.
API call to pull in friends and their tweets.
Fill the twiverse with information asynchronously
Packaging as an OS X app.
`rp5 app my_sketch.rb`
Drop in your own icon.
Shove it all in a .dmg.