Alright, I got winrview working with R5 (without extensive testing)
With the help of a modern compiler, some non-standard coding had
to be eliminated. Then I found that lots of function and variable
names in Radiance had changed over the years. And finally there was
just the usual weirdness of fiddling with someone elses code...
Instead of copying certain key files from Radiance and chainging them
like last time, I tried to adapt the other way now. I threw out all
copied files and most copied functions, linking directly to the originals.
For that to work, I had to actually implement the display driver protocol,
so the library would link with no missing symbols (just pro-forma for now,
the protocol doesn't actually do anything useful yet).
The result is still a bit quirky, but it runs and displays simulations.
Winrview uses the standard Windows method to handle background
computations. The MFC library offers a way to have tasks invoked by an
"onIdle" handler, which means they will be started any time the user
leaves the GUI alone (I think it's even in a seperate thread).
As soon as the user touches anything, the running simulation should
be signalled to pause and then restart with the new parameters.
The controlling agent is not the rvu core, nor even winrview itself,
but the event loop of a windows library.
Rvu manages its own command loop, and a queue of rays to simulate
while waiting for user input. I don't quite understand yet how a GUI
"driver" will maintain its indepence and responsiveness next to that,
but as qtrvu demonstrates, it seems to be possible.
Years ago we worried a lot about response times, as a GUI is supposed
to react instantly to user input. In fact, we had tweaked some
rendering functions deep inside Radiance, so we could interrupt a
simulation even in the middle of computing an individual ray, no
matter how many recursions deep.
I didn't bother with that this time. Given the increased CPU power
available, I'm not sure if it would still be of any benefit.
I remember waiting long seconds for (x)rvu to react to input.
But now it usually answers almost instantly even with a largish model
and tough parameters.
What's still to do?
* At the end of a simulation, the very first large tiles suddenly
overlap the new and smaller ones again - until the next refresh, eg.
when the window is moved around a bit. I blame my OpenGL driver.
* Full implementation of the display driver protocol. If this works
while maintaining sufficient responsiveness, then it would
reduce the duplicated functionality, and simplify the whole thing.
* It doesn't know about any of the recently added simulation options
(pmap, etc.). Both the GUI and the command line should learn about
those (the latter possibly via the task above).
* The program currently doesn't have a command protocol window, but
presents "urgent" info via entertaining popups.
* Command line parameters are used, but not propagated to the
dialog box (it opens showing the default values).
* The GUI is quite functional with dockable toolbars, but has the
typical 90-ies look of Windows NT.
* There's qite a bit of cruft in the code to clean up.
(eg. checking registry entries for paths, left over from DR.)
There are 12x files of C++, 7x files of C, a bunch of headers, plus
some resources. It builds with both Visual Studio 2015 and SCons.
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/