Experiments with ruby-processing (processing-2.2.1) and JRubyArt for processing-3.0

Tuesday 18 February 2014

Nature of Code examples now ported to ruby

Thanks to Pierre-Pat, Shiffmans the nature of code examples have now been ported to ruby-processing, get them here. Naturally enough PVectors were retained in the examples (the code after all originally comes from Dan Shiffman). I am not a big fan of the PVector class (which I think is trying to do too much, which is why I created the vecmath library for ruby-processing) so here is one of examples that could easily use the Vec2D class instead of PVector:-
# The Nature of Code
# http://natureofcode.com
# NOC_1_11_motion101_acceleration_array

load_library :vecmath

class Mover
  TOP_SPEED = 6
  attr_reader :location, :velocity, :topspeed_squared

  def initialize(width, height)
    @location = Vec2D.new(rand(width/2), rand(height/2))
    @velocity = Vec2D.new(0, 0)
    @topspeed_squared = TOP_SPEED * TOP_SPEED
  end

  def update
    mouse = Vec2D.new(mouse_x, mouse_y)
    acceleration = mouse - location
    acceleration.normalize!
    acceleration *= 0.2

    @velocity += acceleration
    @velocity.set_mag(TOP_SPEED) if velocity.mag_squared > topspeed_squared
    @location += velocity
  end

  def display
    stroke(0)
    stroke_weight(2)
    fill(127)
    ellipse(location.x, location.y, 48, 48)
  end
end

def setup
  size(800, 200)
  @movers = Array.new(20) { Mover.new(width, height) }
end

def draw
  background(255)

  @movers.each do |mover|
    mover.update
    mover.display
  end
end

More explorations of shape primitives in ruby-processing (JRubyArt)

I have now created a experimental "shape" library class for ruby-processing see the development branch at JRubyArt. This very much work in progress, but the box class is somewhat influenced by toxiclibs "axis bounding box" AABB class. But for the idiosyncratic axis convention lo would correspond to back lower left, and hi to front upper right.
load_libraries :vecmath, :shape

attr_reader :my_shape

def setup
  size 200, 200, P3D
  camera(100.0, 100.0, 120.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0)
  my_box = Box.new
  my_box.scale(size: 100)
  #my_box.scale(x: 50, y: 30, z: 80)
  fill 100, 100, 100, 100
  @my_shape = create_shape(BOX, *my_box.dimension)
  my_shape.translate(*my_box.center)
end

def draw
  lights
  fill 200, 0, 0
  no_stroke
  sphere(50)
  shape(my_shape)
end

Sunday 16 February 2014

Experimenting with a Box class for ruby-processing (using ruby-2.0 syntax)

Right now you can use ruby-2.0 in ruby-processing, just set `compat.version=2.0` in your `.jrubyrc` file. Here I experiment with using that feature to create a axis bounding Box class (cf toxiclibs AABB class). If it actually makes it to a library I expect to do the rendering using PShape (with a possibly povray export option).
load_library :vecmath

attr_reader :my_box

def setup
  size 200, 200, P3D
  smooth 4
  camera(100.0, 100.0, 120.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0)
  @my_box = Box.new
  #my_box.scale(sz: 50)
  my_box.scale(x: 60, y: 50, z: 70)
end

def draw
  lights
  translate *my_box.center
  box *my_box.dimensions
end

class Box
  attr_reader :fl, :br

  def initialize(top_front_left: Vec3D.new(1.0, -1.0, 1.0), bottom_back_right: Vec3D.new(-1.0, 1.0, -1.0))
    @fl, @br = top_front_left, bottom_back_right
  end

  def scale(sz: 1.0, **args)
    if (args.empty?)
      @fl *= sz
      @br *= sz
    else
      fl.x *= args[:x] / 2.0 if args[:x]
      br.x *= args[:x] / 2.0 if args[:x]
      fl.y *= args[:y] / 2.0 if args[:y]
      br.y *= args[:y]  / 2.0 if args[:y]
      fl.z *= args[:z] / 2.0 if args[:z]
      br.z *= args[:z] / 2.0 if args[:z]
    end
  end

  def dimensions
    [fl.x - br.x, br.y - fl.y, fl.z - br.z]
  end

  def center
    dimensions.map{|x| x/-2.0}
  end
end

Sunday 2 February 2014

More experiments with pry and ruby processing

I have found that is is indeed possible to use pry in place of irb with JRubyArt (on the pry branch of development branch of ruby processing). The most secure way is to create and install a 'java' platform version of the JRubyArt gem, requiring pry (unless you are using bundler (or rvm?) install pry using `jruby -S gem install pry`). Below is a snapshot of a ruby-processing sketch started with:-
jruby -S k9 live drawolver # update 4 Feb 2014 (default to using installed jruby)
In this case I need to use `jruby -S` because for my pry-branch I specify use of java engine (on reflection I don't think this is important), however the --gem flag is important. Now using anBy using the --gem flag we require the sketch to be actually run with an installed jruby (this seems to be required to use gems, and in this case we want to use pry-java version). In the pry branch of JRubyArt I have substituted pry for irb. As with the irb live mode you can access the sketch with `$app`, see below where no_loop command has been sent (stops the draw loop).
screenshot
Running JRubyArt in live mode (note use $app to access sketch)



What good it is, is best tested by pry afficianados, however it also occured to me that there is an alternative way of introducing/using pry. If you start a sketch in the "watch" mode you can edit the live sketch to:-
require 'pry'
# and where you want the break
binding.pry
This also works but again I'm no pry afficianado, so I will leave it to them to decide how best to proceed, but in this scenario you could edit the sketch either from pry, or with an independent editor (tested with vim for both in my case). See below, here I found I was able to set the @back variable directly (no need to call $app). In this I started the sketch in the watch mode, and edited in vim (right-hand terminal, with and unusual white background for me!!)
Now this is slightly interesting, instead of continuing to type $app in the pry repl, you can assign to app `binding = $app`. Then just carry on as though you are editing a regular ruby sketch...

Followers

About Me

My photo
I have developed JRubyArt and propane new versions of ruby-processing for JRuby-9.1.5.0 and processing-3.2.2