The document discusses using the Ruby-Processing toolkit to create 3D applications in Ruby. It provides an overview of Ruby-Processing, examples of challenges in 3D applications, and proposes building a star field simulation that reads from Twitter as an example project. Each star would have its own thread to independently update its position based on time. The document outlines modeling the system, visualizing it using Ruby-Processing callbacks, adding control via input handling, integrating asynchronous I/O to pull tweets, and packaging the application for distribution.

1. WRITING 3D
APPLICATIONS USING
RUBY-PROCESSING
Preston Lee
http://prestonlee.com
http://openrain.com

2. processing.org
Toolkit for creating visualization.
Primitive shapes, positioning, lighting etc.
3D accelerated. (OpenGL rendering available.)
Java.
Both web and desktop friendly.

3. !processing.org
An application framework. No design assumptions.
Object-oriented. BYOOOA&D.
Physics
Ruby.

4. Nutshell.
Processing provides you with a canvas and powerful
primitives, but is in no way a “framework” like Shoes or
Rails.
IMHO, processing is less quirky that the other popular
Ruby GUI toolkits.
Using processing effectively requires design effort
specific to your application.

5. A general GUI framework
application architecture.
A main application/rendering/animation loop that
executes constantly.
CPU intense stuff in separate threads to keep rendering
fast.
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!

6. ruby-processing
`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)

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

8. 3D-Specific Challenges
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.
Performance: models
sometimes need lots of Collision detection.
CPU before rendering.
Physics.

9. Bundled examples.
`cd ruby-processing/samples/processing_app/3D`
`rp5 run form/brick_tower.rb`
`rp5 run typography/kinetic_type.rb`

10. Important missing stuff.
Camera position and object creation position do not
need to be the same. (The camera is fixed in the 3D
examples.)
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.

11. Let’s build something cool!
A star field 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.
Note: object
MRI. JVM FTW!) execution
parallelization is not
needed for most
games, but is useful to
distribute CPU load
across nodes.

12. 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
plane.

13. 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..
`jruby starfield_1_model.rb`

14. Now let’s use ruby-
processing to visualize it.
Callbacks: setup and draw.
Create our models and start the rendering loop.

15. Finally, we’ll add control.
Callbacks: key_pressed, key_released, mouse_dragged,
mouse_released etc.
Math: calculate ∆translation and ∆rotation for camera
on each render based on ∆time.
Move: apply movement to the camera on each draw.

16. 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

17. Packaging as an OS X app.
`rp5 app my_sketch.rb`
Drop in your own icon.
Shove it all in a .dmg.