ben,

I just posted a simple example of a UDP interface here:
http://forums.sketchucation.com/viewtopic.php?f=180&t=31545&start=15#p326273

Also, before I started working on UDP stuff I wrote a ruby script for the wiimote and sketchup to do head tracking similar to what Johny Lee was doing years ago.http://johnnylee.net/projects/wii/

Back when I wrote it, I was using GlovePIE with an Output to file script that I think GlovePIE came with. In sketchup I was just constantly seeking to the end of that file to get the most recent wiimote data. It worked but I never felt it was the best way to do it.

-Mike

Saying that Ruby doesn't have variables is plain wrong though. Even if the variables just hold references to objects, they're still variables, and the term "instance variable" is found throughout most object oriented programming languages (and I think the fact that Matz himself calls them variables is proof enough that Ruby has variables :))

Of course it might be wrong to compare BASIC variables and Ruby variables, but then it's also wrong to compare apples and oranges.

Don't forget the Geom module methods.

Geom.point_in_polygon_2D can be used to narrow down even further where the point is, once you know whether it's ventral (anterior) or dorsal (posterior.)

For instance, reference your view from the other thread, where you show the viewing cone(s) looking downward. Getting the 3 vertices of the horizontal conic section defines a triangular face that can be used with Geom.point_in_polygon_2D, to see if a point should be within the projected section (without regard to z position.)
Repeat the exercise using the vertical conic section, and if both return true, then the point is inside the viewing pyramid that curcumscribes the viewing cone.

@ben.doherty said:

I am having lots of trouble with modules though, if I ask the ruby console for Voyeur::FaceMaker::instance_methods it gives me back a list of the methods as I'd expect, but if I say Voyeur::FaceMaker.makeAnalysisFaces it throws a #<NoMethodError.... any idea how to fix that?

moved to it's OWN topic thread, so folks can find it easier:

See: [info] Using Ruby Modules

Ben, I had some time to post a video demonstrating how to use OpenStudio, EnergyPlus and ResultsViewer to study window shading over the entire year. The video doesn't have any annotation yet, but I'll add that soon. Below are some screenshots. The first is from SketchUp/OpenStudio. The color of the windows relate to the fraction of the window in the sun. While typically viewing simulation data in SketchUp is ideal, here the sketchUp shadows work well on their own. We can look at a window and see that about half of it is in the sun. In this case ResultsViewer's flood maps are an excellent way to study the entire year at a glance. You can quickly see which times of day or year are the problem times. I have shown a Type A and Type B window for the south and east. The Type A and B windows are the same except the Type A has the shade directly above it, while the Type B windows have the same shade offset five feet vertically. This is a simple example, but you can imagine how you can quickly study a variety of window designs and look at the strengths and weakness of each one.

YouTube link (may not work yet)
http://www.youtube.com/watch?v=60lmAnY81ds

Sunlit fraction results viewed in SketchUp
Type b south window
Type a south window
Type b east window
Type a east window