[eq-dev] Announcing Sequel - A simple API to the Equalizer parallel rendering framework.
Stefan Eilemann
I've just pushed the first usable version of Sequel to the github master branch.
Sequel provides a simple programming interface to the Equalizer parallel rendering framework. It allows rapid development of clustered multi-GPU application while not sacrificing the flexibility and power of the underlying Equalizer framework. The philosophy is to lower the entry barrier to multi-GPU development by hiding the flexible, but complex class hierarchy of Equalizer.
Right now a lot of things are missing, and I'm counting on the community to provide input on what is needed. You can help by using Sequel for your development, either of new applications or existing Equalizer programs. Whenever you find a missing feature, please do one of the following:
- Ask here for this feature
- Open a new issue on github: https://github.com/Eyescale/Equalizer/issues
- Fork Equalizer and implement it yourself. We'll pick it up automatically once you pushed it to your fork.
The API documentation can be found here: http://www.equalizergraphics.com/documents/Developer/API/sequel/index.html
I'll update the remaining documentation and website incrementally during the next weeks.
Cheers,
Stefan.
_______________________________________________
eq-dev mailing list
eq-...@equalizergraphics.com
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
Daniel Pfeifer
> github master branch.
Nice. But why didn't it get a repository of its own? Maybe I
would like to install Equalizer via apt and then hack on the
Sequel source code without distraction.
> Sequel provides a simple programming interface to the
> Equalizer parallel rendering framework. It allows rapid
> development of clustered multi-GPU application while not
> sacrificing the flexibility and power of the underlying
> Equalizer framework. The philosophy is to lower the entry
> barrier to multi-GPU development by hiding the flexible,
> but complex class hierarchy of Equalizer.
Yes, this is much needed. This is obviously the right
approach. But in my opinion it does not go far enough.
I am not sure whether it is a good idea to hesitate the use
of some good programming guidelines just for the sake of
consistency.
Is there a strong reason for not using RAII?
If you want to provide a narrow interface instead of
exposing a bunch of classes, maybe it would be a good idea
to seperate (public) headers that provide this interface
from the rest of internal source files?
> Right now a lot of things are missing, and I'm counting on
> the community to provide input on what is needed. You can
> help by using Sequel for your development, either of new
> applications or existing Equalizer programs.
I will.
> The API documentation can be found here: [link]. I'll
> update the remaining documentation and website
> incrementally during the next weeks.
I find it confusing that the API reference contains the
examples. Any good documentation contains examples as well
as a reference. But there should be a clear distinction.
----
wishlist:
* Don't provide any 'init' functions.
* Don't provide any 'exit' functions.
* Use smart pointers (smarter than co::base::RefPtr!)
* Don't force clients to provide 'destroy' functions.
* Don't provide boolean return values indicating success/failue.
Classes should be initialized in the constructor and
deinitialized in the destructor. Further, anything that
needs to be initialized and/or deinitalized should be
wrapped in a class. -- RAII
(Really) smart pointers should be able to provide reference
counting without any requirements to the pointee type
(nonintrusive). It should be possible to provide a custom
delete function. Qt windows then could be created like this:
return shared_ptr<QWindow>(new QWindow(), bind(&QWindow::deleteLater, _1));
Calling multiple functions each of which provides a boolean
result value requires a cascade of if-not-successful-then-bail
checks. Using exceptions here can simplify both library and
client code by a great deal.
cheers, Daniel
Stefan Eilemann
On 21. Jun 2011, at 10:51, Daniel Pfeifer wrote:
> Nice. But why didn't it get a repository of its own? Maybe I
> would like to install Equalizer via apt and then hack on the
> Sequel source code without distraction.
Because right now it requires the latest Equalizer version due to a number of minor changes. Once it stabilizes I will separate the repositories, probably with the next release. There is also some non-trivial infrastructure work (CMake, version, packaging, etc.).
> Yes, this is much needed. This is obviously the right
> approach. But in my opinion it does not go far enough.
It's a first incremental shot - so yes, it does not go far enough.
> Is there a strong reason for not using RAII?
What places are you referring to? I hope you don't want to do Application::init in the ctor, since this would break other design principles.
> If you want to provide a narrow interface instead of
> exposing a bunch of classes, maybe it would be a good idea
> to seperate (public) headers that provide this interface
> from the rest of internal source files?
They are separated!? All internal stuff is in sequel/detail.
>> The API documentation can be found here: [link]. I'll
>> update the remaining documentation and website
>> incrementally during the next weeks.
>
> I find it confusing that the API reference contains the
> examples. Any good documentation contains examples as well
> as a reference. But there should be a clear distinction.
They are separated by namespace:
API: http://www.equalizergraphics.com/documents/Developer/API/sequel/namespaceseq.html
Example: http://www.equalizergraphics.com/documents/Developer/API/sequel/namespaceseqPly.html
Is this not clear enough a distinction?
> * Don't provide any 'init' functions.
> * Don't provide any 'exit' functions.
I don't want to do this work in the ctor/dtor.
> * Don't force clients to provide 'destroy' functions.
I don't. I *allow* them to provide destroy functions - or am I overlooking something?
> * Don't provide boolean return values indicating success/failue.
>
> Classes should be initialized in the constructor and
> deinitialized in the destructor. Further, anything that
> needs to be initialized and/or deinitalized should be
> wrapped in a class. -- RAII
>
> (Really) smart pointers should be able to provide reference
> counting without any requirements to the pointee type
> (nonintrusive). It should be possible to provide a custom
> delete function.
The only ref-counted object is Application which is a RefPtr since it inherits from eq::Client. That will only change when the Equalizer interface changes to shared_ptrs.
> Qt windows then could be created like this:
> return shared_ptr<QWindow>(new QWindow(), bind(&QWindow::deleteLater, _1));
Fair enough - But Sequel is far from this type of customization.
> Calling multiple functions each of which provides a boolean
> result value requires a cascade of if-not-successful-then-bail
> checks. Using exceptions here can simplify both library and
> client code by a great deal.
Now we are entering religious territory. We've tried that with the runtime reliability work, and no, it does not make the code simpler or more readable. It's funny that the proponents of exceptions always bring them up, while real C++ codes use them sparingly - including boost.
Cheers,
Stefan.
Daniel Pfeifer
Am Dienstag, den 21.06.2011, 12:24 +0200 schrieb Stefan Eilemann
<eile...@gmail.com>:
> On 21. Jun 2011, at 10:51, Daniel Pfeifer wrote:
>
>> Nice. But why didn't it get a repository of its own? Maybe I
>> would like to install Equalizer via apt and then hack on the
>> Sequel source code without distraction.
>
> Because right now it requires the latest Equalizer version due to a
> number of minor changes. Once it stabilizes I will separate the
> repositories, probably with the next release. There is also some
> non-trivial infrastructure work (CMake, version, packaging, etc.).
Piece of cake. I did something similar for a much larger project (~100
components).
>> Is there a strong reason for not using RAII?
>
> What places are you referring to? I hope you don't want to do
> Application::init in the ctor, since this would break other design
> principles.
Yes, initializing a class in the constructor is a key element in the
RAII principle.
Which other design principles could be negatively affected by this
approach?
>> If you want to provide a narrow interface instead of
>> exposing a bunch of classes, maybe it would be a good idea
>> to seperate (public) headers that provide this interface
>> from the rest of internal source files?
>
> They are separated!? All internal stuff is in sequel/detail.
Hm. So everything not in sequel/detail is public? I see some .cpp files
there; are they part of the interface declaration?
>>> The API documentation can be found here: [link]. I'll
>>> update the remaining documentation and website
>>> incrementally during the next weeks.
>>
>> I find it confusing that the API reference contains the
>> examples. Any good documentation contains examples as well
>> as a reference. But there should be a clear distinction.
>
> They are separated by namespace:
>
> API:
>
> http://www.equalizergraphics.com/documents/Developer/API/sequel/namespaceseq.html
> Example:
>
> http://www.equalizergraphics.com/documents/Developer/API/sequel/namespaceseqPly.html
>
> Is this not clear enough a distinction?
On this page, yes. Otherwise, nope.
>> * Don't provide any 'init' functions.
>> * Don't provide any 'exit' functions.
>
> I don't want to do this work in the ctor/dtor.
This is exactly what I meant by "I am not sure whether it is a good
idea to hesitate the use of some good programming guidelines just for
the sake of consistency".
You actually DON'T have a reason, it is simply because you have always
done it like this, right?
>> * Don't force clients to provide 'destroy' functions.
>
> I don't. I *allow* them to provide destroy functions - or am I
> overlooking something?
Either way, the width of the interface could be reduced without the
loss of functionality.
>> * Don't provide boolean return values indicating success/failue.
>>
>> Classes should be initialized in the constructor and
>> deinitialized in the destructor. Further, anything that
>> needs to be initialized and/or deinitalized should be
>> wrapped in a class. -- RAII
>>
>> (Really) smart pointers should be able to provide reference
>> counting without any requirements to the pointee type
>> (nonintrusive). It should be possible to provide a custom
>> delete function.
>
> The only ref-counted object is Application which is a RefPtr since it
> inherits from eq::Client. That will only change when the Equalizer
> interface changes to shared_ptrs.
Both createRenderer() and createViewData() return (dumb) pointers. I am
not suggesting to replace RefPtr by shared_ptr. I am suggesting to use
(really) smart pointers where dumb pointers are used currently.
>> Qt windows then could be created like this:
>> return shared_ptr<QWindow>(new QWindow(),
>> bind(&QWindow::deleteLater, _1));
>
> Fair enough - But Sequel is far from this type of customization.
Not as far as you might think. Using smart pointers, you could bind a
deleter that calls the appropriate destroy function of the current
NodeFactory. This would provide full compatibility to already customized
NodeFactories but would reduce the interface width for new NodeFactories
by 50%!
>> Calling multiple functions each of which provides a boolean
>> result value requires a cascade of if-not-successful-then-bail
>> checks. Using exceptions here can simplify both library and
>> client code by a great deal.
>
> Now we are entering religious territory. We've tried that with the
> runtime reliability work, and no, it does not make the code simpler
> or
> more readable. It's funny that the proponents of exceptions always
> bring them up, while real C++ codes use them sparingly - including
> boost.
bool foo()
{
if(!bar())
return false;
if(!baz())
return false;
return true;
}
vs.
void foo()
{
bar();
baz();
}
Which one is simpler and more readable? Please show me the code in
Boost or the C++ standard libraries where a boolean return value
indicates success.
Daniel Pfeifer
>> Yes, initializing a class in the constructor is a key element in the
>> RAII principle.
>> Which other design principles could be negatively affected by this
>> approach?
>
Not a design princible at all B-)
> Apart from some initial misunderstanding on my part, there is now the
> open issue that the current initialization calls virtual methods on
> the same object which are overwritten in the subclass.
I see. Fixing this would be rather straight forward, but very time
consuming I guess. Nevertheless, we should remember it for the future
and strive for RAII in newly written code.
> I will not separate the header from the implementation into separate
> directories unless one can provide new arguments.
I know. I will bring them in due time :-)
>>> They are separated by namespace:
>>>
>>> API:
>>>
>>> http://www.equalizergraphics.com/documents/Developer/API/sequel/namespaceseq.html
>>> Example:
>>>
>>> http://www.equalizergraphics.com/documents/Developer/API/sequel/namespaceseqPly.html
>>>
>>> Is this not clear enough a distinction?
>>
>> On this page, yes. Otherwise, nope.
>
> So what do you suggest?
Providing a documentation per component. Each component's documentation
should include sections for introduction, tutorial, reference and
examples. But this should be postponed until after the modularization
effort.
> Forcing people to use boost::shared_ptr is a loss of functionality.
I could agree that it will make the code more complicated for average C
programmers. But how can it lead to loss of functionality?
>> Both createRenderer() and createViewData() return (dumb) pointers. I
>> am not suggesting to replace RefPtr by shared_ptr. I am suggesting to
>> use (really) smart pointers where dumb pointers are used currently.
>
> Smart pointers are useful if the ownership of an object is not
> clearly defined. They tend to encourage people to not think about
> ownerships and therefore can lead to bad design. I don't see what
> value a smart_ptr brings here.
Exactly what you said. The pointers returned from the above functions
do not have a clearly defined ownership (the factory should be able to
create and forget them), which makes them perfect candidates for smart
pointers.
If an object has a clearly defined ownership, pointers would bring no
value (smart or dumb), you also could use references in that case.
> ... you hide the
> complexity in the bind which makes it harder to use and understand
> for
> mere mortals. You, and to a certain degree I, have no problem writing
> and understanding this, but *imo* it adds nothing in clarity or
> accessibility. I guess we'll never reach stable ground on this type
> of
> discussion, but that doesn't mean that we have a stalemate.
C'mon, this is not some Voodoo like Boost.Proto or Boost.Fusion, this
is just a lambda. Students learn stuff like that on the Bachelor level
nowadays. How low does the entry level need to be? (This is a serious
question, not meant to offend anybody.)
cheers, Daniel
Daniel Pfeifer
>> These packages seem to include one configuration only. It is either
>> Debug or Release but not both.
>
> Correct, it's Release. I don't think the current CMake/CPack setup
> can handle this.
It cannot. But I figured out how to do it anyway. :-)
Stefan Eilemann
On 22. Jun 2011, at 13:49, Daniel Pfeifer wrote:
> sorry for being an ass. I guess my last email was a little harsh. I don't want to start a war, I'm really willing to contribute.
Ok, then I'll read this one later with a kilogram of salt. ;)
>> Once it stabilizes I will separate the
>> repositories, probably with the next release. There is also some
>> non-trivial infrastructure work (CMake, version, packaging, etc.).
>
> If you really want to separate the repositories, I will contribute all the required infrastructure work.
> That includes:
>
> * A system to aggretate the Equalizer source code (and its dependencies) from multiple repositories.
> * Ability to create individual as well as monolithic source packages.
> * Ability to create individual as well as monolithic binary installers (with components).
> * Ability to put both Debug and Release into the same installer.
> * Ability to deploy packages to multiple ubuntu series (maverick, natty, oneiric) at once.
> * Everything will be installed as "CMake package". That means, CMake users may use Equalizer like this (a FindEqualizer.cmake file will not be required):
>
> find_package(Equalizer "1.1" COMPONENTS client admin)
> include(${Equalizer_USE_FILE})
Sounds good - but please let's get at that incrementally, if possible. There tend to be side effects one single person does not see due to his workflow, and I'ld like to be able to influence getting the above features.
Cheers,
Stefan.
Stefan Eilemann
On 22. Jun 2011, at 16:29, Daniel Pfeifer wrote:
> These packages seem to include one configuration only. It is either Debug or Release but not both.
Correct, it's Release. I don't think the current CMake/CPack setup can handle this.
Cheers,
Stefan.
Stefan Eilemann
On 21. Jun 2011, at 18:16, Daniel Pfeifer wrote:
> Yes, initializing a class in the constructor is a key element in the RAII principle.
> Which other design principles could be negatively affected by this approach?
Reality. ;)
Apart from some initial misunderstanding on my part, there is now the open issue that the current initialization calls virtual methods on the same object which are overwritten in the subclass.
>> They are separated!? All internal stuff is in sequel/detail.
>
> Hm. So everything not in sequel/detail is public? I see some .cpp files there; are they part of the interface declaration?
I will not separate the header from the implementation into separate directories unless one can provide new arguments. The .cpp are the implementation of the interface and tend to be trivial.
>> They are separated by namespace:
>>
>> API:
>> http://www.equalizergraphics.com/documents/Developer/API/sequel/namespaceseq.html
>> Example:
>> http://www.equalizergraphics.com/documents/Developer/API/sequel/namespaceseqPly.html
>>
>> Is this not clear enough a distinction?
>
> On this page, yes. Otherwise, nope.
So what do you suggest?
>>> * Don't provide any 'init' functions.
>>> * Don't provide any 'exit' functions.
>>
>> I don't want to do this work in the ctor/dtor.
>
> This is exactly what I meant by "I am not sure whether it is a good idea to hesitate the use of some good programming guidelines just for the sake of consistency".
> You actually DON'T have a reason, it is simply because you have always done it like this, right?
See my first paragraph above.
>>> * Don't force clients to provide 'destroy' functions.
>>
>> I don't. I *allow* them to provide destroy functions - or am I
>> overlooking something?
>
> Either way, the width of the interface could be reduced without the loss of functionality.
Forcing people to use boost::shared_ptr is a loss of functionality. You have to realize that I am not the extreme of 'doing things like I've always done', quite the opposite. Real-world codes often are older than 10 years and have been not always been written by good software engineers.
> Both createRenderer() and createViewData() return (dumb) pointers. I am not suggesting to replace RefPtr by shared_ptr. I am suggesting to use (really) smart pointers where dumb pointers are used currently.
Smart pointers are useful if the ownership of an object is not clearly defined. They tend to encourage people to not think about ownerships and therefore can lead to bad design. I don't see what value a smart_ptr brings here.
>>> Qt windows then could be created like this:
>>> return shared_ptr<QWindow>(new QWindow(), bind(&QWindow::deleteLater, _1));
>>
>> Fair enough - But Sequel is far from this type of customization.
>
> Not as far as you might think. Using smart pointers, you could bind a deleter that calls the appropriate destroy function of the current NodeFactory. This would provide full compatibility to already customized NodeFactories but would reduce the interface width for new NodeFactories by 50%!
I was focusing on the Qt part. To answer your comment: you hide the complexity in the bind which makes it harder to use and understand for mere mortals. You, and to a certain degree I, have no problem writing and understanding this, but *imo* it adds nothing in clarity or accessibility. I guess we'll never reach stable ground on this type of discussion, but that doesn't mean that we have a stalemate.
Cheers,
Stefan.
Stefan Eilemann
On 22. Jun 2011, at 14:26, Daniel Pfeifer wrote:
>> That sounds great! What about Mac OS X-Installers?
>
> With selectable components, of course. Debug and Release in one package. See: http://purplekarrot.net/doc/Boost.CMake/install-darwin.png
We're already building those: http://www.equalizergraphics.com/downloads/nightly/
Cheers,
Stefan.
Daniel Pfeifer
Hi Stefan,
sorry for being an ass. I guess my last email was a little harsh. I
don't want to start a war, I'm really willing to contribute.
> Once it stabilizes I will separate the
> repositories, probably with the next release. There is also some
> non-trivial infrastructure work (CMake, version, packaging, etc.).
If you really want to separate the repositories, I will contribute all
the required infrastructure work.
That includes:
* A system to aggretate the Equalizer source code (and its
dependencies) from multiple repositories.
* Ability to create individual as well as monolithic source packages.
* Ability to create individual as well as monolithic binary installers
(with components).
* Ability to put both Debug and Release into the same installer.
* Ability to deploy packages to multiple ubuntu series (maverick,
natty, oneiric) at once.
* Everything will be installed as "CMake package". That means, CMake
users may use Equalizer like this (a FindEqualizer.cmake file will not
be required):
find_package(Equalizer "1.1" COMPONENTS client admin)
include(${Equalizer_USE_FILE})
To make things simple (and to make my build-system reusable), it will
be required to organize the repositories in a similar way as the
100-repo project I was refering to in my previous (unpleasant) email.
Ideally, each component should live in its own repository and provide
its own headers, source, documentation, examples and tests. It may
depend on other components. Circular dependencies are not a problem.
Would that be a welcome contribution?
cheers, Daniel
Daniel Pfeifer
>>> That sounds great! What about Mac OS X-Installers?
>>
>> With selectable components, of course. Debug and Release in one
>> package. See:
>> http://purplekarrot.net/doc/Boost.CMake/install-darwin.png
>
> We're already building those:
> http://www.equalizergraphics.com/downloads/nightly/
These packages seem to include one configuration only. It is either
Debug or Release but not both.
Jonas Bösch
>> Once it stabilizes I will separate the
>> repositories, probably with the next release. There is also some
>> non-trivial infrastructure work (CMake, version, packaging, etc.).
>
> If you really want to separate the repositories, I will contribute all the required infrastructure work.
> That includes:
>
> * A system to aggretate the Equalizer source code (and its dependencies) from multiple repositories.
> * Ability to create individual as well as monolithic source packages.
> * Ability to create individual as well as monolithic binary installers (with components).
> * Ability to put both Debug and Release into the same installer.
> * Ability to deploy packages to multiple ubuntu series (maverick, natty, oneiric) at once.
> * Everything will be installed as "CMake package". That means, CMake users may use Equalizer like this (a FindEqualizer.cmake file will not be required):
>
> find_package(Equalizer "1.1" COMPONENTS client admin)
> include(${Equalizer_USE_FILE})
That sounds great! What about Mac OS X-Installers?
As OS X doesn't have a true package manager, a .dmg with an installer for the .frameworks/.dylibs and headers would be great...
Daniel Pfeifer
Am Mittwoch, den 22.06.2011, 14:13 +0200 schrieb Jonas Bösch
<boe...@ifi.uzh.ch>:
> On 22.06.2011, at 13:49 , Daniel Pfeifer wrote:
>
>>> Once it stabilizes I will separate the
>>> repositories, probably with the next release. There is also some
>>> non-trivial infrastructure work (CMake, version, packaging, etc.).
>>
>> If you really want to separate the repositories, I will contribute
>> all the required infrastructure work.
>> That includes:
>>
>> * A system to aggretate the Equalizer source code (and its
>> dependencies) from multiple repositories.
>> * Ability to create individual as well as monolithic source
>> packages.
>> * Ability to create individual as well as monolithic binary
>> installers (with components).
>> * Ability to put both Debug and Release into the same installer.
>> * Ability to deploy packages to multiple ubuntu series (maverick,
>> natty, oneiric) at once.
>> * Everything will be installed as "CMake package". That means, CMake
>> users may use Equalizer like this (a FindEqualizer.cmake file will not
>> be required):
>>
>> find_package(Equalizer "1.1" COMPONENTS client admin)
>> include(${Equalizer_USE_FILE})
>
> That sounds great! What about Mac OS X-Installers?
With selectable components, of course. Debug and Release in one
package. See: http://purplekarrot.net/doc/Boost.CMake/install-darwin.png
cheers, Daniel
Stefan Eilemann
On 22. Jun 2011, at 17:30, Daniel Pfeifer wrote:
>>> Both createRenderer() and createViewData() return (dumb) pointers. I am not suggesting to replace RefPtr by shared_ptr. I am suggesting to use (really) smart pointers where dumb pointers are used currently.
>>
>> Smart pointers are useful if the ownership of an object is not
>> clearly defined. They tend to encourage people to not think about
>> ownerships and therefore can lead to bad design. I don't see what
>> value a smart_ptr brings here.
>
> Exactly what you said. The pointers returned from the above functions do not have a clearly defined ownership (the factory should be able to create and forget them), which makes them perfect candidates for smart pointers.
They have a clearly defined ownership (Application and View, respectively). The factory can create and forget them. It *might* want to override the destroy precisely in the case that it uses whichever smart pointer implementation for whatever reason.
> If an object has a clearly defined ownership, pointers would bring no value (smart or dumb), you also could use references in that case.
Correct, except that they are not set in the ctor and reference member variables can't be reset. One could reference and dereference the pointer accordingly to use a reference in the API - but what would be the point in that?
>> ... you hide the
>> complexity in the bind which makes it harder to use and understand for
>> mere mortals. You, and to a certain degree I, have no problem writing
>> and understanding this, but *imo* it adds nothing in clarity or
>> accessibility. I guess we'll never reach stable ground on this type of
>> discussion, but that doesn't mean that we have a stalemate.
>
> C'mon, this is not some Voodoo like Boost.Proto or Boost.Fusion, this is just a lambda. Students learn stuff like that on the Bachelor level nowadays. How low does the entry level need to be? (This is a serious question, not meant to offend anybody.)
Sure, no offense taken. I value these discussion since they are very helpful for me.
The average level is lower then you think. Right now I work in a project where Neuroscientist do programming. I agree that this should not be the case - but it's reality. Another example is HPC, where *some* people work at a lower level for performance reasons. MPI is still a C API, after all. And yes, I've heard about boost::mpi. ;)
Cheers,
Stefan.
wihu
Sequel framework, because the NodeFactory is implemented inside the
Application implementation (namespace detail), and is encapsulated. Am I not
supposed to subclass the Channel directly?
I need to modify the Channel, because I want to use multiple cameras to
render a wide curved screen (320 degree), so what I am thinking is I need to
initialize the Channel and render it using different model view matrix
based on the channel's name.
Please kindly advice. Thank you.
--
View this message in context: http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7088583.html
Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.
Stefan Eilemann
On 13. Dec 2011, at 4:07, wihu [via Software] wrote:
> Hi, I am having some problem when trying to create my own Channel using this Sequel framework, because the NodeFactory is implemented inside the Application implementation (namespace detail), and is encapsulated. Am I not supposed to subclass the Channel directly?
Yes, the idea is that everything is presented through application and renderer.
> I need to modify the Channel, because I want to use multiple cameras to render a wide curved screen (320 degree), so what I am thinking is I need to initialize the Channel and render it using different model view matrix based on the channel's name.
This is not the concept of Equalizer/Sequel. You render whatever you're told in Renderer or Channel, and use a configuration file with multiple channels/segments having different frusta. You should definitely not assume any kind of special configuration and modify your frustum based on a name. That way you can run the same application on you desktop, a curved screen or whatever comes up later.
HTH,
Stefan.
--
View this message in context: http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7089153.html
wihu
Thanks for your answer, I must admit I misunderstood the concept of
Equalizer/Sequel, and so, I undo-ed my changes to the code, and used the
configuration file, and it worked really well. : D
However, I am having trouble understanding how to synchronize FrameData
object in the sequel across all machines. I looked at an example Seqply,
created a customized FrameData class, and then pass it to the
Application::run(&_frameData), then, I override ViewData class to capture
the user interaction through handleEvent callback, I am not sure how to link
them together (how ViewData affecting FrameData object in the Renderer::draw
loop), and also even if I can change the data in the FrameData object and
set the flag to dirty, I did not see any changes in the other machine, in
fact, the FrameData object is null.
Please kindly advice. Thanks in advance.
--
View this message in context: http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7150232.html
Stefan Eilemann
On 4. Jan 2012, at 13:37, wihu [via Software] wrote:
> However, I am having trouble understanding how to synchronize FrameData object in the sequel across all machines. I looked at an example Seqply, created a customized FrameData class, and then pass it to the Application::run(&_frameData), then, I override ViewData class to capture the user interaction through handleEvent callback, I am not sure how to link them together (how ViewData affecting FrameData object in the Renderer::draw loop), and also even if I can change the data in the FrameData object and set the flag to dirty, I did not see any changes in the other machine, in fact, the FrameData object is null.
Do you mean the FrameData object passed by Sequel to Renderer::draw is 0? If yes, did you implement Renderer::createObject?
Cheers,
Stefan.
--
View this message in context: http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7150259.html
wihu
In the application node, the frameData object is being passed correctly.
Although, when I put some debug log in the Renderer::createObject function, it gets called in the client, but not passed in the draw function (NULL).
And what triggers the frameData object synchronization? Does Sequel handle that automatically everytime I set the dirty flags?
Thanks again for your help.
Cheers,
William
From: Stefan Eilemann [via Software] [mailto:ml-node+s171...@n2.nabble.com]
Sent: Wednesday, January 04, 2012 8:48 PM
To: William Hutama
Subject: Re: Announcing Sequel - A simple API to the Equalizer parallel rendering framework.
Hello,
On 4. Jan 2012, at 13:37, wihu [via Software] wrote:
> However, I am having trouble understanding how to synchronize FrameData object in the sequel across all machines. I looked at an example Seqply, created a customized FrameData class, and then pass it to the Application::run(&_frameData), then, I override ViewData class to capture the user interaction through handleEvent callback, I am not sure how to link them together (how ViewData affecting FrameData object in the Renderer::draw loop), and also even if I can change the data in the FrameData object and set the flag to dirty, I did not see any changes in the other machine, in fact, the FrameData object is null.
Do you mean the FrameData object passed by Sequel to Renderer::draw is 0? If yes, did you implement Renderer::createObject?
Cheers,
Stefan.
________________________________
If you reply to this email, your message will be added to the discussion below:
http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7150259.html
To unsubscribe from Announcing Sequel - A simple API to the Equalizer parallel rendering framework., click here<http://software.1713.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=6495036&code=aHdpbGxpYW1AbnR1LmVkdS5zZ3w2NDk1MDM2fDI5NDU5ODYwNA==>.
NAML<http://software.1713.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
________________________________
CONFIDENTIALITY: This email is intended solely for the person(s) named and may be confidential and/or privileged. If you are not the intended recipient, please delete it, notify us and do not copy, use, or disclose its content.
Towards A Sustainable Earth: Print Only When Necessary. Thank you.
--
View this message in context: http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7150282.html
Stefan Eilemann
On 4. Jan 2012, at 13:54, wihu [via Software] wrote:
> Yes, I did implement Renderer::createObject, and yes the FrameData object passed by Sequel to Renderer::draw is 0 but ONLY in the client machine,
[...]
> And what triggers the frameData object synchronization? Does Sequel handle that automatically everytime I set the dirty flags?
Yes, Sequel should handle this. All objects are frame-synchronized in Sequel.
It seems this is a bug in Sequel. Can you verify if seqPly mis-behaves in the same way?
Cheers,
Stefan.
--
View this message in context: http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7150311.html
wihu
copy some files(*.ply) to the other machine.
But I found something weird, in the ObjectMap class line 252: (just after
_factory.createObject( entry.type );)
_factory.getConfig() returns null in the client machine.
I will verify again whether seqPly really has the same problem.
--
View this message in context: http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7150340.html
Stefan Eilemann
On 4. Jan 2012, at 14:08, wihu [via Software] wrote:
> _factory.getConfig() returns null in the client machine.
This is indeed a bug. See https://github.com/Eyescale/Equalizer/issues/71, it should be fixed soon.
Cheers,
Stefan.
--
View this message in context: http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7150533.html
wihu
I will continue and verify with you tomorrow as I just left my office.
Cheers.
--
View this message in context: http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7150652.html
wihu
The bug is fixed. I can now sync my frame data object in multi-nodes config.
Thank you.
--
View this message in context: http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7157109.html
Stefan Eilemann
On 01.02.2012, at 20:17, "oliver [via Software]" <ml-node+s171...@n2.nabble.com> wrote:
> One short question:
> Is the seq::ViewData meant to be used as framedata object or is it completely independent?
It is independent, providing per-view, per-frame data. The frame data provides global per-frame data.
Hth,
Stefan.
--
View this message in context: http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7244178.html
Stefan Eilemann
On 2. Feb 2012, at 12:32, oliver [via Software] wrote:
> Is it easily possible to use orthographic projection with Sequel? Because I couldn't find the corresponding parts in seqPly.
>
> The application which is developed is 2D based, using multiple projections. It would be perfect if I would have a coordinate system from 0 to 1 (or-1 to 1) spanning over all projections. But I guess that's the standard case...
The ortho projection simply projects orthographically on the defined walls. Getting this is just a matter of wiring the eq::Channel::useOrtho to the seq::Renderer. The easiest would be if you fork the github repo, implement it yourself and push the change. Alternatively please open an issue and we'll do it eventually.
I suggest that you then set the walls of your views programmatically to normalized values, since this orthographic projection has no relationship to physical dimensions.
HTH,
Stefan.
--
View this message in context: http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7247039.html
Stefan Eilemann
Stefan.
On 02.02.2012, at 17:54, "oliver [via Software]" <ml-node+s171...@n2.nabble.com> wrote:
> Hi Stephan,
>
> should I add the ortho functionality as attribute of seq::ViewData or should it be an overridable getter in seq::Renderer?
>
> Best!
> Oliver
>
> Am 02.02.2012 15:15, schrieb Stefan Eilemann [via Software]:
>>
>> Hi Oliver,
>>
>> On 2. Feb 2012, at 12:32, oliver [via Software] wrote:
>>
>> > Is it easily possible to use orthographic projection with Sequel? Because I couldn't find the corresponding parts in seqPly.
>> >
>> > The application which is developed is 2D based, using multiple projections. It would be perfect if I would have a coordinate system from 0 to 1 (or-1 to 1) spanning over all projections. But I guess that's the standard case...
>>
>> The ortho projection simply projects orthographically on the defined walls. Getting this is just a matter of wiring the eq::Channel::useOrtho to the seq::Renderer. The easiest would be if you fork the github repo, implement it yourself and push the change. Alternatively please open an issue and we'll do it eventually.
>>
>> I suggest that you then set the walls of your views programmatically to normalized values, since this orthographic projection has no relationship to physical dimensions.
>>
>>
>> HTH,
>>
>> Stefan.
>>
>>
>>
>> If you reply to this email, your message will be added to the discussion below:
>> http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7247039.html
>> To unsubscribe from Announcing Sequel - A simple API to the Equalizer parallel rendering framework., click here.
>> NAML
>
>
>
> If you reply to this email, your message will be added to the discussion below:
> http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7247574.html
> To start a new topic under Equalizer - Parallel Rendering, email ml-node+s1...@n2.nabble.com
> To unsubscribe from Equalizer - Parallel Rendering, click here.
> NAML
--
View this message in context: http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7247722.html
Stefan Eilemann
On 2. Feb 2012, at 18:34, oliver [via Software] wrote:
> I pushed the change... never worked with git before, hope I did it right....
Thanks - Looks ok, I will review and merge.
Cheers,
Stefan.
--
View this message in context: http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7250098.html
wihu
nodes in Sequel,
I suppose I can only customize event handler in the view data, but then the
view data is not globally sync-ed with all other nodes' view data, so the
only way is to make frame data object so that we can have global per-frame
data through the application. Thus, I in the Renderer::draw() function, I
need to manually retrieve the view data (view states' changes by user
inputs), and copy the dirty states into global frame data, and then get the
local frame data and copy back the states into the view data (because the
channel in Sequel uses view data to get the model matrix for rendering).
I probably misunderstood how things work in Sequel, so please correct me if
I am wrong.
Thank you!
--
View this message in context: http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7432052.html
Stefan Eilemann
On 3. Apr 2012, at 9:37, wihu [via Software] wrote:
> I am still confused about how I should synchronize user inputs across all nodes in Sequel,
> I suppose I can only customize event handler in the view data, but then the view data is not globally sync-ed with all other nodes' view data,
The seq::ViewData is frame-synchronized in all corresponding Renderer instances across all nodes. You can see it working, since the Camera (model matrix) is part of the ViewData.
HTH,
Stefan.
--
View this message in context: http://software.1713.n2.nabble.com/Announcing-Sequel-A-simple-API-to-the-Equalizer-parallel-rendering-framework-tp6495036p7432825.html