Stardust = openframeworks + equalizer

Hi,

maybe of interest to some people here, I have started an attempt to bring together Equalizer with openFrameworks.

This combo allows running openFrameworks powered applications in visualization clusters and distributed environments of virtually any size ( thanks to Equalizer and given sufficient resources of course :wink: ).

It is very much a work in progress with a lot of functionality intentionally not there yet ( distributed objects for example ), since ideally I would like to get input from more people before designing specific features but I hope its in a state where people can already start playing around if interested.

Stardust can also be a good test bed for the new multi-renderer design of OF ( thanks @arturo ) which allows the multithreading of rendering code.

You can find it here.

Stardust would not have been possible without the amazing work of the OF community and the team behind Equalizer, so respect to all and many thanks !

Petros

3 Likes

This looks very interesting! How much latency does the system add? Is it still reasonable to build a touch reactive system with this?
Any idea on how hard would it be to make it work on OS X and Windows?

Also, I never heard of the “multi-renderer design” for OF before, is this a thing @arturo ?

yes, it’s still an experimental thing though. the idea is that in some cases there will be more than one renderer and might be running in a different thread.

In 0.9 each window creates it’s own renderer. if all windows are running in the same main loop in the same thread then it’s ok to work as we’ve been doing till now but in some cases we might want to use different threads per window or do background operations in a different thread for those case one can create explicitly a renderer and use only “safe” calls.

Right now in the core, everything but the draw and bind calls in every object are safe and every renderer has draw and bind functions for every GL object. Also the only singleton in the whole rendering system is (optionally) the main loop object.

for example instead of doing:

texture.draw()

you can do

gl.draw(texture)

where gl is an ofGLRenderer or ofGLProgrammableRenderer.

Safe here doesn’t mean that those objects are completely thread safe in the sense that they can be used from different threads but that those calls don’t use any global object so as long as each object is only used from one thread it’ll be safe to use them (as safe as openGL allows)

this is also in preparation for vulkan which works in a similar way.

there’s an example here:

1 Like

There is no perceivable latency in the system ( by default equalizer maintains a 1 frame latency between the application and the rendering tasks for better pipelining of operations ) so a touch reactive system is definitely possible and reasonable depending your requirements and setup.

As for porting to Windows / OS X, I guess the main challenge would be to setup dependencies and relevant cmake project files. Other than that I don’t see something else right now that could cause an issue.

I will be adding more examples along the way ( also multi-node ones ) and more info ( maybe even a wiki ). Hopefully there is time and interest for everything!

Re latency: The one frame latency is intended for large data visualization, so rendering and compositing operations can be pipelined. One can easily enforce synchronous execution (zero frames latency). In this mode, added latency for multi-display environments are in the millisecond ballpark (compute and send per-tile render tasks to the nodes).

Hi Stefan!

Great to have you on board with this ! Just for reference for anyone interested equalizer specific questions related to stardust can be addressed in this post of the eq forum where there is a discussion started with Stefan ( one of the main developers behind Equalizer ).