Writing 3D Applications Using ruby-processing
Upcoming SlideShare
Loading in...5

Writing 3D Applications Using ruby-processing






Total Views
Views on SlideShare
Embed Views



5 Embeds 297

http://www.prestonlee.com 274
http://www.slideshare.net 16
http://azcode.tumblr.com 3
https://www.linkedin.com 3
http://translate.googleusercontent.com 1



Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />

Writing 3D Applications Using ruby-processing Writing 3D Applications Using ruby-processing Presentation Transcript

  • WRITING 3D APPLICATIONS USING RUBY-PROCESSING Preston Lee http://prestonlee.com http://openrain.com
  • processing.org Toolkit for creating visualization. Primitive shapes, positioning, lighting etc. 3D accelerated. (OpenGL rendering available.) Java. Both web and desktop friendly.
  • !processing.org An application framework. No design assumptions. Object-oriented. BYOOOA&D. Physics Ruby.
  • 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.
  • 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!
  • 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)
  • 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.
  • 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.
  • Bundled examples. `cd ruby-processing/samples/processing_app/3D` `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 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.
  • 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.
  • 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.
  • 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`
  • 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, 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.
  • 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.