 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
yes.
Hmm, just to be sure we're on the same page, there is no Qt in the
povray 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.
https://github.com/zaphoyd/websocketpp
(Although oddly, I had to add -lstd++ to the build for
std::basic_string, which I thought would have been there.)
> It appears to me that the way you're approaching it, that would be a
> replacement for both the Unix command-line version as well as
> povconsole.exe.
Yes. And it's the "replacement" part that I internally debate. I have
chosen to generate povrayws as a separate unix binary to povray, because
the unix frontend (command line parser) is ripped out and replaced.
But I wonder if instead I should have kept a single binary with a new
povray option -N4401 to switch to the websockets version at runtime.
The vfe(s) are nicely thin, and I don't see a problem switching to that
technique if later it is preferred.
>
> The reason being that ideally the system as a whole should run on /any/
> platform supported by Qt, not just those for which we /happen/ to
> already have a command-line version of POV-Ray.
>
> In terms of source files, this means that your system should compile and
> run fine without any of the files residing in `unix`, `windows`,
> `vfe/unix` or `vfe/win`, and ultimately even without any of the files in
> `platform/unix` or `platform/windows` (though these last two are
> probably comparatively easy to fix further down the road, by
> establishing some `platform/qt` instead).
>
The --websockets option to ./prebuild.sh does a substitution of vfe/unix
with vfe/websockets.
At first, I thought ./prebuild.sh was really overengineered. It is the
most complicated automake system I've ever seen. (A script to create
./configure.in and massive Makefile.in(s) ? Why not just have those
files?) But it works for me because now I do the directory substitutions. :)
platform/[unix|windows] has to stay because that is backend system grunt
work (timers). I don't know if I see value in platform/qt. Do you
really want to drag in all of the Qt baggage (custom build system,
custom packaging) just to provide a backend timer. -- If it ain't
broken, don't fix it.
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.
--
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
>
> yes.
>
> 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.
> https://github.com/zaphoyd/websocketpp
> (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.
>> It appears to me that the way you're approaching it, that would be a
>> replacement for both the Unix command-line version as well as
>> povconsole.exe.
>
> Yes. And it's the "replacement" part that I internally debate. I have
> chosen to generate povrayws as a separate unix binary to povray, because
> the unix frontend (command line parser) is ripped out and replaced.
>
> But I wonder if instead I should have kept a single binary with a new
> povray option -N4401 to switch to the websockets version at runtime.
> The vfe(s) are nicely thin, and I don't see a problem switching to that
> technique if later it is preferred.
It doesn't matter whether you add a websockets interface to the existing
Unix binary, or create a new Unix binary with the command-line parser
replaced by a websockets interface: Neither binary will run on Windows,
and thus your Qt-based GUI will be mostly useless on Windows.
> 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
one.
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?
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.
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.
> At first, I thought ./prebuild.sh was really overengineered. It is the
> most complicated automake system I've ever seen. (A script to create
> ../configure.in and massive Makefile.in(s) ? Why not just have those
> files?) But it works for me because now I do the directory
> substitutions. :)
The `prebuild.sh` script is not an automake system -- rather, it is a
pre-processing script designed to keep our repository as free from
build-process-specific stuff as possible. Most notably, the script:
- /Creates/ certain autotools-specific files from platform-neutral
sources, in order to avoid having to maintain the redundant information
in those autotools-specific files manually.
- /Copies/ other autotools-specific files from other locations to the
root directory of the package, in order to avoid cluttering the root
directory with stuff only required by one particular build process.
> platform/[unix|windows] has to stay because that is backend system grunt
> work (timers). I don't know if I see value in platform/qt. Do you
> really want to drag in all of the Qt baggage (custom build system,
> custom packaging) just to provide a backend timer. -- If it ain't
> broken, don't fix it.
Ultimately? Yes, I'd like to see a `platform/qt` (in /addition/ to the
existing `platform/*`, mind you), if only because it would instantly
allow us to support a number of additional platforms -- anything
supported by Qt.
In the short run? No. As I said, I expect it easy to replace further
down the road, so why bother when there's still more important stuff in
the way.
> 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.)
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).
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).
I think it is important that we distinguish between what I like to refer
as "platforms" and "incarnations":
- When I talk about "platforms", I think of certain low-level
functionality that is essential for POV-Ray on each and every operating
system, but which can't be implemented in a portable fashion. For
instance the `file_exists()` scene language function requires that we
can determine whether a file exists or not, but on Windows this needs a
different function call than on Unix. In order to solve this, we have
"platform-specific" code tucked away in `./platform` (and probably other
places as well, but those will be weeded out in the long run).
- On the other hand we have "POV-Ray for Windows" and "POV-Ray for
Unix", which I'd like to refer to as "incarnations" of POV-Ray. And
while they happen to run on different platforms, and need different code
to e.g. test whether a directory exists, it's not their main difference.
Instead, they're really different pieces of software, which just happen
to share certain pieces of code (namely the stuff residing in
`./source`, plus a few odds & ends like platform-neutral portions of the
VFE). These should be tucked away in `./windows` and `./unix`,
respectively. Other "incarnations" also exist, such as Yvo's version for
Mac OS, which comes with its own GUI (and presumably uses
platform-specific code for Unix), and I'd also consider the
command-line-only version for Windows a separate "incarnation".
When talking about Qt, we have the same duality:
- As a framework for creating platform-independent software, Qt surely
must provide its own interface to do stuff such as determining whether a
particular file exists or not. While this will actually be a wrapper, it
makes sense of thinking of it as yet another "platform". And any
"incarnation" designed to make use of Qt should better also make use of
this "platform", lest the biggest benefit of Qt -- portability -- be wasted.
- 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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
>>
>> yes.
>>
>> 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.
Ok.
>> 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.
>> https://github.com/zaphoyd/websocketpp
>> (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
> one.
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:
Ok.
> - 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
contemplating.
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.
http://git.buckosoft.com/gitweb/pov.cgi?p=qtpov.git;a=blob_plain;f=qtpov.pro;hb=HEAD
There is obviously a lot of magic happening behind the scenes to turn
that into:
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/QtWidgets
-I/opt/Qt/5.9.1/gcc_64/include/QtGui
-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
../qtpov/mainwindow.cpp
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?
--
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
dick balaska <dic### [at] buckosoft com> wrote:
> One thing about vfe/POVMS, is that file I/O happens in both the frontend
> and backend. This currently limits the networking to localhost.
The code to handle this exchange file location information via POVMS is already
in 3.7. There just happens to be no code to actually transfer files over a
network.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
dick balaska <dic### [at] buckosoftcom> wrote:
> BTW, this is the colored editor:
> http://www.buckosoft.com/qtpov/
>
> --
> dik
The syntax being configurable is cool !
I don't know if you had a look, we kind of had lots of trial and errors to get
to a satisfying look for our Blender POV syntax highlight, so feel free to skim
throught the groups of words for ones you want or might have forgotten (of
course if you see some we missed I hope you'll tell us as well ;-))
https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/space_text/text_format_pov.c
Our INI support is slightly less fine grained:
https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/space_text/text_format_pov_ini.c
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
et voilà
qtpov caught in mid-render.
http://www.buckosoft.com/qtpov/g/qtpovRenderInProgress.png
Two weird things, one in povray, one in qt.
1) povray frontend loses the vfeSession::MessageType info somewhere
before it hits the vfe. I see mDivider, everything else (mDebug, mError)
is mUnclassified. Line and Col are always 0, too. I'll figure out what
I'm doing wrong.
2) qt loses/ignores the last paint event when drawing a rendering image.
If I wiggle with size bar, all of the data shows up. Um...
--
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have a qtpov-0.0.1 release (Linux only).
http://www.buckosoft.com/qtpov/
It's very primitive, but it has some bells and whistles.
http://www.buckosoft.com/qtpov/g/qtpovRenderInProgress.png
I have one bummer: When I throw a "render several frames at .5 seconds
per frame" command at it, the bit that scales the in-progress image into
the window is *slow*, and drags the event queue to a crawl. There's too
many redraw events [1]. :(
There is a compiled binary package available. I have run it on 3
different Ubuntu 16 boxes, but that's not much of a test, because they
are all Ubuntu 16. The qtpov program runs on Ubuntu 14 (with the
included .so files) but povrayws tips over on bad system libraries. It's
best to build povrayws yourself.
--
dik
[1] So I start a render of 10 frames. The UI locks up as it furiously
renders and displays the 10 frames. Around frame 5 I press "Cancel",
which is the same button as "Render". It finishes the frames, sees the
event on the button, which is now back to "Render" (because the job is
done) and restarts the render job. argh.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 2017-10-25 09:22, also sprach dick balaska:
> I started on qtpov.
Runs on Windows 8.
http://www.buckosoft.com/qtpov/g/qtpovWindowsRendering.png
--
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 30.11.2017 um 10:53 schrieb dick balaska:
> Am 2017-10-25 09:22, also sprach dick balaska:
>> I started on qtpov.
>
> Runs on Windows 8.
> http://www.buckosoft.com/qtpov/g/qtpovWindowsRendering.png
Love to hear that :)
I really need to have a closer look at what you're doing and how you're
doing it... as soon as I find the time.
What tools are needed to build the Windows binaries?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 2017-11-30 07:09, also sprach clipka:
> Am 30.11.2017 um 10:53 schrieb dick balaska:
>> Am 2017-10-25 09:22, also sprach dick balaska:
>>> I started on qtpov.
>>
>> Runs on Windows 8.
>> http://www.buckosoft.com/qtpov/g/qtpovWindowsRendering.png
>
> Love to hear that :)
>
> I really need to have a closer look at what you're doing and how you're
> doing it... as soon as I find the time.
>
> What tools are needed to build the Windows binaries?
>
vs2015 for povwebsockets.exe and Qt5 for qtpov.
I'll write it up.
Weird, I put together a Windows Qt package for bsAniPic
( http://www.buckosoft.com/bsAniPic/ )
but I can't say the right magic words for qtpov. :) :(
As I've said, I am treating this as a learning exercise. I am getting
into the whole vfe structure, so when it comes time to move to ./qt I'll
already have experience and should make better choices, because it will
be my second vfe.
qtpov works by launching and persisting a single instance of povray and
then creating a new vfeSession for each render. This is the pvengine
technique. I noticed that Unix, I seem to leak about 70MB per render,
and I bet myself that Windows would not leak, being that pvengine
doesn't leak, and it doesn't. So, that's a thing. (or, "top" lies. I
haven't run valgrind or anything on it yet.)
--
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
