Headless Cinder?

This is just a thought but I was wondering how difficult it would be to have a “Headless” App template with Tinderbox? This kind of defeats the point of using Cinder as a graphics library but with the new official Linux support i’ve been thinking about some RPI audio / lighting ideas that would be great if I could write using Cinder (and possibly some favourite blocks like Ci-Xtract and Ci-DMXusbPro) but without the overhead of creating a graphics context etc.

If the device doesnt have a display will the app run regardless? Perhaps the window creation overhead isnt even that much, again i’m just wondering whether Cinder might be a valid tool to use for embedded projects or whether I should just use a different kit / language. (maybe this is all already possible)

Cinder is an awesome creative c++ library even without the graphics stuff (audio, timeline animation, events, filesystem etc) though I don’t know how tightly coupled the graphics are to the main App…

Any feasibility thoughts on an embedded Cinder target, RPI etc?


1 Like

I remember a few mentions of this on the old forum, but can’t remember anyone reporting back as to its success.


1 Like

Hi Felix,

last year I used cinder with rpi for a project.

And it worked without any extra settings, the app just detected that there were no monitor and opengl was not initialized. ( not sure if things have changed )

The DMX block was a little bit more tricky, Enttec and the other devices I had at time did not worked with the default Cinder Serial stuff. It needed some specific FTDI driver calls, you can see an example of (bad :upside_down:) code here

1 Like

At Rare Volume we’re also doing headless in Cinder for a client, performing cloud rendering on AWS using OpenGL. Currently you have to jump through a few hoops to create a virtual display in XWindows, but it’s not too bad to setup and works perfectly - neither Cinder nor your app require any modifications. However I’d like to explore using EGL in scenarios like that, in particular without a window at all. GLFW definitely echoes some foreboding warnings to the console, though they are ultimately harmless.

Ultimately I doubt a no-op draw() method in your app requires too much in terms of resources, but exploring this is on my list for the near-term.


1 Like

Cool to hear that its on your radar Andrew!

It would be great to have an example or two (maybe headless rendering image to file and a simple audio example) in the samples in the future.

Thanks for all the pointers everyone else.