Well, as long as you have a fixed configuration during runtime, then yes chromium is transparent to the application. But, for cave-like setups that have head tracking and use off-axis projection to adjust the viewing frustums, you will need to put some chromium calls in the application. For example, see: http://chromium.sourceforge.net/doc/nonplanar.html
BTW, what kind of system are you guys building?
It sounds quite similar to our work. We (at McGill / SAT) are building a similar interactive/distributed rendering environment using Pd. We started last year with the Pd/Gem combination, but as we started to get more elaborate with our rendering engine, we looked to chromium to help with distribution over the network. It was a viable alternative, but in the end we decided to use a combination of Pd & OpenSceneGraph, and write our own world-coherence engine using a Pd-message based system and [netsend]. It works quite nicely. Much more flexibility in terms of rendering quality and graphical extensions than Gem, and you can maintain higher level control with the slave renderers. ie, the renderers still have knowledge of the world, and not just streamed openGL commands. This is essential is you want to do extra processing down the line (eg. shadow detection/removal, multi-projector blending, etc).
Cheers, -Mike
Ah, I was under the impression, applicaitons needed to be recompiled
to work with chromium. Not sure where I became under the impression.
I will give it a shot.chromium is non-invasive. this means that you do not have to do anything to either Gem nor
chromium to run Gem via a chromium-renderer. this means: it (should) work "out of the box"