GsX

a more advanced grafix server.

• interfacing only via OpenSoundControl (like SuperCollider server)
• based on OpenGL and OpenSceneGraph
• basic building blocks are nodes
• core implementation in c++
• assorted script libraries in ruby and SuperCollider
• window + event interfacing using OpenProducer

After some tinkering and reading i came to the conclusion that an OpenGL scene graph of some form would be good to have. There are a number of Scene Graph libraries out there, but OpenSceneGraph seems to be the most developed of the free ones. Its complicated but maybe worth it. It should be able to link in the OpenDE physics engine as well.

OSC Interface

i was planning to implement most of the sc server osc messaging, but it does not really seem to fit well into OSG. i'll keep the client-side id management though. The osg classes dont carry an id field so i track objects by id with one (or more) <int, osgthing> maps. the graph relationships are all handled by the osg.

the process:

1: create objects in the server (geometries, images, modifiers) first: "createobject". objects have a unique id generated by the client (this is like sc). to remove objects, use "killobject". killobject is not implemented yet.

2: set static parameters: "setparam"

3: send an "addchild", "removechild", "movechild", "addcallback", "addtexture" or sthg like that to build/change the graph. only some of them are implemented

ok, this means we have these messages:

/createobject <id>,<what>, ... <initparams>
/killobject <id>
/addchild <objectid> <targetid>
/removechild <objectid> <targetid>
/movechild <objectid>, <fromtargetid>, <desttargetid>
/addcallback <nodeid>, <callbackid> (may get dumped)
/removecallback <nodeid>, <callbackid> (may get dumped)
/setstateset
/removestateset
/freeall

a diagram of a sample simple graph

(this is a little bit out of date)

Screenshots

these screenshots show an early incarnation of the server.

Problem areas identified so far:

Camera

While older versions of OpenSceneGraph supported a thing called "osg::Camera" and assorted support classes for this. Since the notion of a "Camera" was considered bad in a 'pure' scene graph library, this class was dumped. Unfortunately, some of the OSG examples on the web make use of this camera. The official answer to "where is the camera?" is: "use Producer!", but this is not as easy as it sounds.

OpenProducer is a companion Library to OSG and does all this camera stuff. Too bad that it also does event handling, timing and interfacing with the window system as well. Even worse: There are only rendering backends for X11 and W32 - but no SDL, no Cocoa. The basic reason for not supporting SDL is SDL's missing support for more than one window (we could easily live with that).

So - I decided to use Producer in the end. yes, its only X11 under OSX but wtf. Eventually someone (me?) implements a Quartz/Cocoa Producer backend some time.

I also threw out the net2/SDL networking stuff, i use liblo now. no support for bundles though.

ODE integration

there is an example ode integration (considered "crude" by the author). should be possible.

OSX problems

There seem to be 2 bugs in the osx build of OpenSceneGraph: a "display list bug" (maybe this is the one which crashes apps when using larger geometries) and a "thread something" bug. i have to try with more recent sources if there has anything happened recently. also it would be nice to have the OpenSceneGraph compiled as a framework on osx, for easier application distribution.

The bug seems to be an OSX bug (!). It can be worked around by forbidding using GL display lists (osg/Drawable.h). all examples run now on osx, except the ones using png images. I just upgraded to 10.3.3, and the display list bug seems to have vanished.

Code

code is available (should build on OSX and linux if you have all supplemental libraries) on XdvCVS.

-- AndiAndi? - 14 Apr 2004