IWe are planning to do research project on multiprojector warping. Our
lab develops using the Qt (qt.nokia.com) toolkit. Now that Qt is
heading to OpenGL-ES 2.0 with QML 2.0 is a good timing to rewrite part
of our toolkit to do good use of Equalizer.
The goal:
1. allow Qt to create a GL (we use QGLWidget)
2. try to keep things isolated into ctors and dtors so current coding
styles are mostly unaltered
... after Equalizer stuff has been established..
N. do research about projector edge blending, warping, non linear
mapping... for huge non-standard visualization/interaction screens
N+1. do research about huge ui's
I've already googled around and found the "best" alternative is eQute
(http://purplekarrot.net/blog/eQute.html) but it seems it doesnt work.
I can get a lot of verbosity of Equalizer running and 4 windows + Qt
window but the 4 windows wont show anything but black. Am i doing ok
in using eQute, or shall i use another method. Relevant code at:
main.cpp
http://pastebin.com/cUCzcpVU
eqTest.hpp
http://pastebin.com/Xh1rDArH
Thanks a lot
Ariel Molina R.
Interactive and Cooperative Technologies Lab
Universidad de las Américas Puebla
http://ict.udlap.mx
_______________________________________________
eq-dev mailing list
eq-...@equalizergraphics.com
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
On 26. Jun 2011, at 23:11, Ariel Molina wrote:
> The goal:
> 1. allow Qt to create a GL (we use QGLWidget)
> 2. try to keep things isolated into ctors and dtors so current coding
> styles are mostly unaltered
>
> ... after Equalizer stuff has been established..
> N. do research about projector edge blending, warping, non linear
> mapping... for huge non-standard visualization/interaction screens
> N+1. do research about huge ui's
>
> I've already googled around and found the "best" alternative is eQute
> (http://purplekarrot.net/blog/eQute.html) but it seems it doesnt work.
> I can get a lot of verbosity of Equalizer running and 4 windows + Qt
> window but the 4 windows wont show anything but black. Am i doing ok
> in using eQute, or shall i use another method. Relevant code at:
As far as I can tell this looks ok.
Daniel, who wrote the eQute magic, is on this list. Maybe he'll comment some more. He is working on a better Qt integration right now, but since this requires some refactoring that might take some time yet.
Cheers,
Stefan.
Well the code looks good for me too, but the fact is that it wont
render anything on the EQ windows, only black screens (see
http://imagebin.org/161597), the output log is at:
http://pastebin.com/vYZAM1KQ
Im using a laptop:
Intel(R) Core(TM) i7 CPU Q740 @ 1.73GHz
GeForce GT 330M
Ubuntu 10.04 (Kernel 2.6.32-31-generic #61-Ubuntu)
Nvidia propietary driver v270.29
Xorg 1.7.6 (10706000)
As i understand Equalizer should share the context of Qt, then Eq must
init it's stuff and then inside Qt I should just render stuff as
usual, then Eq should balance the load. Am i right?
My scenario is simple, i want to offload rendering to a farm of
1gpu+1projector in order to create a huge wall. I want to use Qt to
visualize stuff.
Ariel
--
---
Ariel Molina Rueda
sorry for letting you wait for so long.
The main with the Equalizer-Qt marriage currently is that Equalizer
creates all its windows in the Pipe thread while Qt wants all Widgets to
be created in the Application thread.
There are the multiple different ways to handle this:
A. Refactor Equalizer into a threading model that is compatible with
Qt. This approach would be most future proof, because many other
windowing toolkits behave similarly to Qt. But it is also a lot of work.
B. Create all widgets before even initializing Equalier (this is what
eQute does). Then, of course, it is impossible to dynamically add/remove
windows depending on the config file or admin events.
C. When a window should be created, signal the main thread to create a
window and then signal the pipe thread upon completion. I tried to avoid
this route so far because I consider it a hack.
Anyway, A is too much work and B has been proven deficient. I will try
to implement C in the next couple of weeks. I will keep you updated.
cheers, Daniel
purpleKarrot wrote:
>
> Anyway, A is too much work and B has been proven deficient. I will try
> to implement C in the next couple of weeks. I will keep you updated.
>
Option C is what I implemented a while ago, it's available here:
It seems it is somewhat more cumbersome to use than eQute, and as Daniel
rightly noted, the whole concept is a bit of a hack (and there probably are
ways to do it more elegantly than my implementation). However, I think this
is the most "Equalizer-style" way of combining Eq+Qt.
In contrast to eQute (as far as I understand it), it creates windows (Qt or
native) based on Equalizer's config file, and allows the application to
decide per-window whether to use Qt or a native window.
This means that your approach of creating a window yourself and then telling
Equalizer to render into it is not possible; instead, you would tell
Equalizer to create the window via a simple config file. There's a small
example application to get you started.
Regards,
Marc
--
View this message in context: http://software.1713.n2.nabble.com/About-Qt-and-Equalizer-tp6518175p6583020.html
Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.