Hi, On 18. Jun 2013, at 17:39, Petros.Kataras [via Software] <[email protected]> wrote:
> Its a GLUT-like wrapper that's based on Equalizer 1.0.2 and more specifically > the eqPly example. It provides a very simple interface so you dont have to > get into all the details of this amazing but quite complex framework thats > called..Equalizer ! :) > It has worked well in the past for realtime interactive graphics on various > sized clusters.. > > For me what I find really nice about this wrapper is that by reading a page > of documentation you can start working with it .. This is quite important I > think for production environments where multiple developers might have to > work on an Eq based app but not necessary have the time to get on all the > eq-related hardcore details ... I fully agree, and this has lead to Sequel which only has an Application and a Renderer class: http://eyescale.github.io/Equalizer-1.4/namespaceseq.html > Most importantly I think an interface / object manager to add - update - > remove shared objects as easy as possible .. This is the idea behind Renderer and Application implementing co::ObjectFactory and using co::ObjectMap to add/update/remove shared object -- which I just realize is not exposed through the API in Sequel, even though the init and frame data objects are managed through this mechanism. Have a look at the aforementioned classes, and I'm happy to figure out an API to expose the ObjectMap API. > In our case this is as easy as extending a SharedObject class and calling > AddSharedObject(this) , UpdateSharedObject(this), RemoveSharedObject(this) on > the objects you want to distribute with the only need to define a serialize / > deserialize funtion... > > When dealing with realtime interactive multimedia applications where you have > to update a lot of stuff actually something like this comes really handy I > think... We're in full agreement here. > This is actually something that I could maybe help somehow -- Although I > would have to admit that there are times that Equalizer internals are kind of > really challenging to grasp so I suppose I would probably need some guidance > from you on this side .. I'm happy to help - just ask ahead. > I would really like to have your opinion on this matter..i.e equalizer as a > multimedia - realtime - visualization framework and what would be your > approach on making the entry a bit easier on this kind of domain... I would like to move forward with Sequel using a concrete use case like yours to provide a stupidly simple API for 90% of the Equalizer features. > As for the pixel coordinate thing you are right and actually I was thinking > of what would be the best / correct way of dealing with 2D stuff in an easy > way and applyScreenFrustum does actually exactly what I need so thank you for > the info.. Nice :) Cheers, Stefan. -- View this message in context: http://software.1713.n2.nabble.com/Pixel-Coordinates-configuration-file-OF-Equalizer-tp7583381p7583438.html Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
