a project to remotely control the Ogre 3d engine with OSC.

ogreOSC is part of the ProjectTRGSystem and current documentation can be found in the README file. At some point, this will work its way into the 'documentation', most likely once the interface dust settles.

current code can be found here > http://fo.am/cgi-bin/darcsweb.cgi?r=trg;a=tree;f=/system/ogreOSC

or using darcs

darcs get http://fo.am/darcs/trg

possibly it was born out of the realisation that to get an XML sceneloader for Ogre i would have to write the “bindings” (not really the right term but it's conceptually close) myself. if i have to do that grunt work just to load static data at scene-creation time, why not do it for an interface that will be useful during run-time as well.

most (all?) of the data structures in Ogre can be referred to by a textual name. this makes it possible to do almost all of the control of the engine remotely, since there is no need to pass around complicated opaque datatypes. most objects are also stored in a tree (the scenegraph) making it possible to reference them with a /directory/style/pathname.

since i'm still learning the engine, as i discover new functions i want to use, i make a little wrapper (using liblo) to the function in OSC. at the moment adding a new wrapper involves about 3-4 lines of code (maybe about 8 if you count cut+pasted lines).

at the moment, i have these functions:

• /Node/setScale path-to-node x y z
• /Node/setOrientation path-to-node w x y z (this is a quaternion rotation, so not really human useable at the moment)
• /Node/removeAllChildren path-to-node
• /SceneNode/createChildSceneNode path-to-scene-node child-name
• /SceneNode/attachObject path-to-scene-node entity-name
• /SceneManager/createEntity entity-name mesh-name
• /SceneManager/setAmbientLight r g b

no pictures yet… just imagine wobbling ogre heads being controlled from pd.

note to self: in the ExampleApplication framework that Ogre provides, the default camera is called PlayerCam

this is a very low level interface at the moment, as it merely exposes the internal ogre API. one of the ideas in the back of my head is to write some XSLT to convert a nicer XML scene description into the series of OSC commands that would be needed to create the described scene. at according to my own subjective idea of 'work', that sounds easier than building an XML loader directly into Ogre.

other unrelated-to-trg ideas include talking to Ogre from SuperCollider…

– PiX - 02 Dec 2004

data from Ogre → supercollider is definately useful and completely relevant, but the other way (2way conversation) may not be as unrelated-to-trg as perhaps it first seems. not necessary, but still worth pondering. – nik gaffney

i have been thinking a bit about changing the way that things are addressed in OgreOSC, since i have bumped up against a few limitations with the way i have been doing it thus far. my ramblings are available here: OgreOSC Address Space