hi,
We’re just finishing an installation build with openFrameworks and Unity3d: Sniff.
Sniff is an interactive public projection in a storefront window: an animated dog follows passers-by, discerns their behavior as friendly or aggressive, tries to engage them in a play and forms a relationship with them based on the history of the interaction.
Check out Sniff in action and find additional info, updates and details at: http://www.gravitytrap.com/sniff
A project by Karolina Sobecka with software design by Jim George. Built with openFrameworks and Unity3d.
Sniff will be hosted by The Change You Want To See gallery during the Conflux Festival in New York.
September 18-20th
84 Havemeyer Street, Storefront, Brooklyn, NY 11211
Sniff is also going to Louiseville! Hosted by Gill Holland during the Idea Festival.
Starting September 26th. Exact location and dates TBD.
Please check Sniff-blog for updates and details.
thanks!
yea, unity and OF make a really good combo. jim made a nice osc bridge to communicate with the game engine which we want to post at some point.
Very cool. I’m excited to swing down that way and check it out. Out of curiosity did you guys use the Unity indie? I don’t know anyone who’s used that particular package and I’d be curious to hear more about what you all thought of it since that would be the only one I’d get, if I were going to pick it up.
Yeah we just used the indie license, it has everything we needed.
The biggest advantage of getting the pro version of Unity (at least for what we are trying to do) is the ability to write custom plug-ins in c++. If we had gone with the pro we could have made a much tighter connection between Unity and oF. Potentially we would compile oF libraries into a Unity plug-in and run them in the same application space rather than over the network. But for our purposes in SNIFF, the OSC bridge worked well. We were able to implement that purely using the C#-based networking libraries in Mono that come with Unity, so for a little sweat we got off the hook.
I definitely recommend Unity though, it’s really stable, has great APIs and documentation, and an active community to get help when you need it.
As Karolina said we still want to clean up and post the OSC receiver in Unity3d so we can share it. It opens up a lot of possibilities for Unity-based graphics and animation controlled from any number of live sources. pretty exciting stuff.
As promised, attached is an example project that shows a HelloWorld example for an OSC receiver in Unity.
The networking guts of the example are wholly derived from the MakingThings OSC sender, but modified to compile under the Unity. for reference for those objects see:
Thanks for posting the code, Jim!
I’ve been trying to send messages to your Unity example using the “oscSendExample” that comes with the ofxOsc addon. I left your C# code untouched and changed the following code in the oscSendExample, but I can’t get the Example1 function in Unity to trigger:
testApp.h
#define HOST "127.0.0.1"
#define PORT 57130
testApp.cpp
//--------------------------------------------------------------
void testApp::mousePressed(int x, int y, int button){
ofxOscMessage m;
m.setAddress( "/example1" );
m.addStringArg("foo");
sender.sendMessage( m );
}
I attached my code with an Xcode project.
Any ideas? Maybe there’s a problem with the host or port?
Unity3d has a quirk where downloaded projects lose script references. Most likely you just have to reattach the scripts. In Unity look for the OSCEmpty object, it will have 3 “missing” script references. Next to each of them you can click on the little arrow next to the gear on the right, attach OSC, UDPacketIO, and OSCReceiver in that order. You can also change the variables for the receiver right there too.
DOh! I had re-attached the scripts, but the host and port arguments set in the Inspector were set incorrectly. I was assuming it was all being handled in the JavaScript code. Changed the Inspectors Host/Port arguments to be the same as the code and it worked! Thanks!!
Unity is receiving the OF message, and I’m able to Debug.Log messages without an error, but when I attach the scripts to a cube and try and translate a it a certain distance every mouse click, Unity now throws the following error:
public function Example1(oscMessage : OscMessage) : void
{
transform.Translate(0,1,oscMessage.Values[0]); //move the cube
}
Here’s the OF code:
void testApp::mousePressed(int x, int y, int button){
ofxOscMessage m;
m.setAddress( "/example1" );
m.addIntArg( 25 ); //distance to move the cube on the Z axis.
sender.sendMessage( m );
}
Unity is not thread safe. This means that only one thread can call into Unity API functions. In your scripts you can start other threads. These threads may not call Unity functions. We added an assert into 2.6 when the player is running inside the Editor to report when a calling thread was not the thread that started Unity script. The message you have is basically saying “the code calling into Unity is not the thread that Unity is expecting. The behaviour of Unity may become unpredictable.” (The problem is really when two threads call into Unity functions at the same time.)
Does this sound like a problem with 2.6 where I have to write additional code for message queuing to get your OSC code to work, or am I probably messing something else up? Thanks for the help, i’m pretty new to this…
Hey, sorry for the delay on this. Today I’m in the process of updating Sniff the to new version of Unity and figured out the solution to this thread problem.
The problem is that OSC messages are initiated from a separate thread and can’t “reach into” other unity objects from that context.
The solution is to keep local variables inside your OSCReceiver and then query them in the update of your other objects. Something like this
//in your OSC receiver
public var currentZ : int;
public function Example1(oscMessage : OscMessage) : void
{
currentZ = oscMessage.Values[0];
}
//in the script on the object you wish to move
public var OSCHolder : Transform; // set this in unity to the object with the script on it
public function Update()
{
var oscReceiver = OSCHolder.GetComponent("OSCReceiver"); //get the osc instance
this.transform.Translate(0,1, oscReceiver.currentZ); //move the object
}
A number of users (particularly OS X users) found that Unity 3.0 broke this OSC implementation. I noted the same thing and filed a bug report. Going back to this thread I found the comment by elbow below which is a fix that also seems to work in 3.1 -
“I just changed line 2 of UDPPacketIO.cs to remove the .Ports from the end so that it just says using System.IO; and it seems to work.”
I started working with OSC and Unity without realizing that obviousJim was the guy behind Sniff. Great work! and I look forward to any updates. Kinect maybe?