Anirudh Sharma

Let's begin with what all I tried at my end that didn't work . 1. Direct Implementation of Ruby Client within Sketchup - Didn't work due to the Ruby API's limitation under SketchUp. 2. pyGE_touch - Tried to hack around Win32COM interface to make SketchUp respond to pyGE like script. Didn't workout just because we don't have a COM interface in SketchUp's API. 3. Using the SKSocket class - Though it showed some initial success the if the SKSocket was buffering and finally flushed the data all at once, this wasn't the best of experiences. As per the blogpost on http://touchaddict.blogspot. com/2009/06/some-changes-to- strategy.html its explianed how it worked for a while- gave me a lot of hope, but eventually failed. That's what finally gave some hope to move on. 4. Finally since the time was short, we thought of an option(with Colin) that we could connect TUIO to SketchUp using a Text file logger . got some success in getting this done. Although ...

Finally I am dumping the SkSockets approach with our plugin. Though it showed some initial success the if the SKSocket was buffering and finally flushed the data all at once. Which won't work for this as we need constant refresh of data. 1 - started osc.exe - set it for small screen size and low framerate. 2 - used toxy_win UDP to TCP proxy server (gave a link) 3 - Start the tuioconn.rb code in SU. This made SketchUp's screen turn white for long, and random messages(which i didn't log sadly), but i couldnt get it done twice again. Maybe it is the SU Socket is waiting on something like 2 newlines as a signal to flush, but with osc you never get 2 in a row because its a stream of messages. The one time it did work, it must have hit the Socket limit set in SU. and then flushed everything it had been buffering. So for this week I am dumping this approach finally, and keeping the writing TUIO to text file in the background . Moving on with the next big thing is the DLL integrat...

Got back from home after 5 days, it was probably a long gap, resumed the GSoC work now, 1. The TUIO client now appends cursor coordinates to a text file, the x_pos and y_pos, example coordinates 0.535937488079071, 0.410416662693024. 2. Writing a ruby script SketchUp plugin that reads the TUIO cursor information from the text file. The downsides to this after discussing with Jay Morrisson 1. it's subject to slowdown by writing to/reading from disk and 2. The serialization has to be done by oneself After this works I'll consider one more option of trying the dRB ruby gems (Distributed Queue in Ruby) since we can just focus on the sketchup integration

What would be the best between 1. pyGE Touch like implementation under SketchUp, doable if SketchUp can support WIN32COM interfacing http://code.google.com/p/pymt/source/browse/examples/kaswy/PyGE_touch.py 2. Going with Aberrant's TUIO Client within SketchUp, we won't continue with it since thread calculation within SketchUp's scripting is quite a pain. 3. Write TUIO to Text/XML, and get it read by SketchUp. That's what we're busy doing now. After this works, we'll work with code refinement and optimizing the stuff before moving to gestures.

Going to ask my mentors and guys on the SketchUpforums about the WIN32 COM interfacing with SketchUp.

Simultaneously I had a word with patali, regarding pyGE if something similar will work with Google SketchUp. We can go with an external script, that will sends TUIO using win32com directly http://code.google.com/p/pymt/source/browse/examples/kaswy/PyGE_touch.py like passing commands. That's how the Google Earth is controlled via python and we can make these commands user defined 1. We run an external script and this script launches the Google SketchUp 2. Takes in the TUIO, processes gestures and talks to SketchUp But we will resort to this option if all else fails, after trying this successfully I'll come back to usual TUIO implementation within SketchUp. Started to try if that works out with Sketchup. The only difference being that Google Earth comes with a direct WIN32 COM interface and SketchUp doesn't. But we might be able to add that support via a DLL.