On 11/12/2017 01:00 AM, clipka wrote:
> Am 12.11.2017 um 00:56 schrieb dick balaska:
>> On 11/11/2017 03:53 PM, clipka wrote:
>>> No, not a Qt based render engine -- just a Qt based program (which acts
>>> as a wrapper for the actual render engine) that you invoke from the GUI
>>> to render scenes.
>> Hmm, just to be sure we're on the same page,
> I think we aren't yet. Somehow we're still talking different language here.
>> there is no Qt in the povray source tree.
> Of course not (yet). But if you write a Qt-based GUI, and we want to
> make it an official part of the POV-Ray package (to replace that
> outdated POV-Ray for Windows GUI, for instance), then obviously that
> means Qt-based code must get into the POV-Ray source tree.
>> The "wrapper" is a separate program and
>> communicates via a socket. My pollution to the source consists of
>> adding an std/boost based header only websocket library.
>> (Although oddly, I had to add -lstd++ to the build for
>> std::basic_string, which I thought would have been there.)
> I'm pretty sure that's not enough -- if the goal is for the Qt-based GUI
> to run on all Qt-supported platforms. And from my seat, that's exactly
> the goal.
Yes. I plan on demoing Linux and Windows, which is what I have available.
>> The --websockets option to ./prebuild.sh does a substitution of vfe/unix
>> with vfe/websockets.
> We don't have `./prebuild.sh` on Windows. And just replacing the vfe
> package doesn't turn a Unix-specific application into a platform-neutral
No. I envision a third option in VS2015. Currently, there's "GUI" and
"Console" iirc. I'd add a third option "Websockets".
> Besides, at this point I'm wondering whether you're doing the right
> thing with the websockets interface:
> - The official interface between the UI and the actual parser/renderer
> system is the POVMS layer.
> - The VFE layer was placed on top of that for easier use of the POVMS
> layer on the UI side.
> - Now you're placing a third layer on top of that, to... well, why
> exactly? Separate the GUI from the actual parser/renderer system?
Yes, separate the GUI from the render system. I'm trying to be as
unobtrusive as possible to the current povray source tree.
> I'd like to point out here that although the POVMS layer is currently
> only used to communicate between different threads of the same process,
> it was originally designed specifically as an interface to be used
> between separate processes or even over a network connection. So rather
> than bolt websockets on top of the VFE layer, it seems to me the right
> thing to do would be to integrate it /into/ POVMS as a channel to
> transport POVMS messages. Think POVMS-over-websockets.
Hmm, interesting. I didn't notice the network aspects of POVMS, but I
wasn't looking. That would be a lot tighter binding than I was
One thing about vfe/POVMS, is that file I/O happens in both the frontend
and backend. This currently limits the networking to localhost.
> I don't claim that to be an easy task, as I do expect some weed still in
> there that needs removing. (Somewhen during the development of v3.7.0,
> the strict use of the POVMS layer had been eroded quite significantly,
> with the VFE communicating directly with the parser/renderer subsystem
> at various points. I've been trimming down that wild growth since, but
> there may still be remnants of that eposide lurking in there.)
> So your Qt-based GUI should really access either VFE or POVMS directly
> (or via a layer running in the same process), with the actual
> inter-process communication happening within the POVMS layer.
Yes. What I have done is subclass vfeSession. Instead of vfeUnixSession
there is now vfeWebsocketSession. I think it will be easy to flesh out
vfeWebsocketSession because I have a working model of what I need to
feed vfeSession with the existing vfeUnixSession.
>> The source files in $(povray)/unix are now unused (display a picture),
>> but I need the control foo in there. I think the same thing happens to
>> $(povray)/windows, too. The *.cpp go away but the vs2015 directory, at
>> least, will remain.
> That is something that I think we should avoid. (And physically removing
> files from the tree is a no-go, obviously.)
s/go away/will be unused in the websockets incarnation/
> Qt is a platform-independent framework, so I'd presume it provides
> /some/ mechanism to manage the build process in a platform-independent
> manner (possibly by maintaining build information in a platform-neutral
> form, and auto-generating platform-specific build information from that,
> just like we currently do with our Unix `prebuild.sh` script).
Yes, ain't nothing to a Qt makefile.
There is obviously a lot of magic happening behind the scenes to turn
g++ -c -pipe -g -std=gnu++11 -Wall -W -D_REENTRANT -fPIC
-DQT_DEPRECATED_WARNINGS -DQT_QML_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB
-DQT_CORE_LIB -I../qtpov -I. -I/opt/Qt/5.9.1/gcc_64/include
-I/opt/Qt/5.9.1/gcc_64/include/QtCore -I. -isystem /usr/include/libdrm
-I. -I/opt/Qt/5.9.1/gcc_64/mkspecs/linux-g++ -o mainwindow.o
One nice thing about Qt, is the Windows version supports gcc/MinGW and
VS2015 compilers. I use the VS2015 because it seems to have more robust
debugging and seems to generate faster code, at least for bsAniPic.
> So anything specific to the Qt-based incarnation of POV-Ray should
> reside in its own dedicated directory (say, `./qt`, instead of `./unix`
> or `./windows`, respectively).
> - A Qt-based GUI for POV-Ray has to /either/ constitute an "incarnation"
> of POV-Ray in its own right, /or/ invoke some "incarnation" to do the
> actual work. In the latter case (which I understand is your approach),
> this should ideally be a portable "incarnation" (and thus necessarily a
> new one, ideally based on Qt as well), again lest the biggest benefit of
> Qt be wasted.
All right, I think I see. You envision a single unified build based on
Qt. The GUI and the engine build to make one big happy program.
I could spend months learning and tweaking the Qt build system and CPU
optimizations to build a well optimized backend. If rendering is 5%
slower, the users won't adopt it. This is not my strength, and I'm not
interested in it at this time. I just want to make it work so I can get
back to my animation. :)
So Phase 1, I'm going to continue on my websockets, separate source,
separate build, plan. If it dies, it dies. If it turns out good, then
Phase 2 will be move the GUI tree to ./qt and get the whole thing to
build with Qt.
Phase 3 will be remove the websockets and give the GUI either a direct
vfe interface or maybe POVMS.
Sound ok to you?
Post a reply to this message