On 11.12.14 23:45, Anthony D. Baye wrote:
> The source makes very little sense, period.  I tried tracing the path for the
> command line options to find out the answer for another question, and I couldn't
> figure out where anything was handled.

The code makes sense if you know how to build parallel and/or distributed 
software. Then you also know what design patterns to look for ;-)

All communication between threads is handled via message passing, and all 
computations are handled in worker threads that get created based on 
messages with commands that tell the code to do so. Hence you cannot follow 
a simple call chain in a parallel and/or distributed program because there 
isn't one!

Imagine this like modern manufacturing where parts of products are produced 
in different countries around the globe. If you only look at he 
manufacturing plants, you will never figure out how a whole product is made 
from beginning to end because some plants might get half-finished parts from 
other plants, add a piece and then send them elsewhere for assembly. What 
you need to know is the freight traffic between those plants to figure out 
what product depends on which pre-produced part. The plants are the threads 
and the freight traffic are the messages in POV-Ray 3.7...

> I found references to several apparently different functions called "trace" but
> nowhere could I find definitions or forward declarations for them. (I downloaded
> the zip of the master and went through it using grep)
 >
> It would make more sense -to me, at least- for command line parsing to be more
> centralized, with options and their values stored in a dictionary that could be
> queried by various modules, but that's just my opinion.  It may be that there
> would be some undesirable overhead in that method, but it would seem to me that
> maintainability would win out.

Depending on where you looked (i.e. Windows version) it can be a bit 
complicated to find the start. It is easier to start with the native main 
function in 
https://github.com/POV-Ray/povray/blob/3.7-stable/source/backend/povray.cpp 
line 677. Parsing the command line starts in line 753 with the creation of 
the ProcessRenderOptions object. Parsing takes place for command line 
arguments in line 765 with the call to renderoptions.ParseString, with all 
values stored in the POVMS object 'obj', which is then passed to 
frontend.Start in 780, which sends it to the backend.

The actual parsing takes place in the class ProcessOptions, while the 
specific implementation is included in the derived class 
ProcessRenderOptions 
https://github.com/POV-Ray/povray/blob/3.7-stable/source/frontend/processrenderoptions.cpp

. Most important are the tables starting in line 89 for INI options and in 
line 235 for the command line options. Most of the magic of command line 
parsing can be seen in ProcessRenderOptions::ProcessUnknownString starting 
on line 823.

In the backend the parsed object appears again in 
https://github.com/POV-Ray/povray/blob/3.7-stable/source/backend/scene/scene.cpp 
in line 437, where it arrives as argument of Scene::StartParser. Later is 
arives again, this time in 
https://github.com/POV-Ray/povray/blob/3.7-stable/source/backend/scene/view.cpp 
line 668 as argument of View::StartRender. Tracing is started in line 1135 
for the main image (radiosity pretace etc happened earlier).

So now you arrive in 
https://github.com/POV-Ray/povray/blob/3.7-stable/source/backend/render/tracetask.cpp 
line 215 with takes all the data and initializes the state of the tracing 
code. Then eventually TraceTask::Run in  line 263 is called, which selects 
the different tracing methods. The actual tracing takes place with the 
various calls to the 'trace' object, which is of class TracePixel. Here the 
function operator in line 258 of 
https://github.com/POV-Ray/povray/blob/3.7-stable/source/backend/render/tracepixel.cpp

takes care of tracing by calling the method TraceRay from the parent class 
Trace. So you continue looking in 
https://github.com/POV-Ray/povray/blob/3.7-stable/source/backend/render/trace.cpp 
line 108 where Trace::TraceRay does all the work. From here on, you are 
basically in the same code as in 3.6 and before, though the names of 
functions/methods have changed a bit.

     Thorsten

Post a reply to this message