|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hiya
I'm doing a final year project at university working with povray and need to
work with the source code but due to its sheer size I have no idea where to
start and I've been unable to find any diagrams that help with this.
I was wondering if there were any class diagrams or flow diagrams showing the
structure of the program or the execution process. If not, what is the entry
point of the program? Is it the povray.cpp file in backend?
Secondly, what would be the easiest way of profiling povray and finding out
where the bulk of the processing is done? And also, how close is the current
beta to being complete? As it's design for multi-core processors is ideal for my
work but I don't want to do loads of work and then have it all change due to the
final release changing things.
Thanks
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 23/12/2010 00:50, Aidy nous fit lire :
> Hiya
>
> I'm doing a final year project at university working with povray and need to
> work with the source code but due to its sheer size I have no idea where to
> start and I've been unable to find any diagrams that help with this.
>
Have you tried to apply some tools on the sources ?
As blind as it could be, doxygen might already give you some clues.
(but it won't explain how it happens, and you'd better investigate the
boost::thread (or whatever their names))
> I was wondering if there were any class diagrams or flow diagrams showing the
> structure of the program or the execution process. If not, what is the entry
> point of the program? Is it the povray.cpp file in backend?
The entry point (main) is in vfe/unix/unixconsole.cpp (for the unix
port). Windows' entry point as usual...
Final year project in CS ? I'm afraid, very afraid. You will learn a
lot, or not.
>
> Secondly, what would be the easiest way of profiling povray and finding out
> where the bulk of the processing is done?
Learn your tools.
what about investigating g++ and its -pg option ?
You might be in for some delusion: this is not a triangle renderer, the
time is spent on various computations which depends on the scene to
render. If you put in some polynomial, you would spend a lot of time in
a polynomial solver iterating to find the roots... every scene is different.
> And also, how close is the current
> beta to being complete? As it's design for multi-core processors is ideal for my
> work but I don't want to do loads of work and then have it all change due to the
> final release changing things.
Load of works should be automated for your project (for raw data
production at least) if you cannot sell a beta code to your supervisor.
Data analysis might be checked for conclusion when raw data are updated.
(what if your year ends before the final release ? or if it get out 3
days before the presentation's deadline ?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.12.2010 08:07, schrieb Le_Forgeron:
> Le 23/12/2010 00:50, Aidy nous fit lire :
>> Hiya
>>
>> I'm doing a final year project at university working with povray and need to
>> work with the source code but due to its sheer size I have no idea where to
>> start and I've been unable to find any diagrams that help with this.
>>
>
> Have you tried to apply some tools on the sources ?
> As blind as it could be, doxygen might already give you some clues.
> (but it won't explain how it happens, and you'd better investigate the
> boost::thread (or whatever their names))
A few header files indeed include doxygen-compatible documentation.
>> I was wondering if there were any class diagrams or flow diagrams showing the
>> structure of the program or the execution process. If not, what is the entry
>> point of the program? Is it the povray.cpp file in backend?
I'd suggest starting at
TracePixel::operator()
in tracepixel.cpp, and work your way "up" and "down" from there. This is
where a single pixel is computed.
>> And also, how close is the current
>> beta to being complete? As it's design for multi-core processors is ideal for my
>> work but I don't want to do loads of work and then have it all change due to the
>> final release changing things.
We plan on releasing 3.7.0 proper in just a bit over a week's time, so
you can safely presume that the overall architecture is not going to
change anymore until then :-).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks for the replies. I'll take a look through those and see what I can get.
:)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 23.12.2010 08:07, schrieb Le_Forgeron:
> > Le 23/12/2010 00:50, Aidy nous fit lire :
> >> Hiya
> >>
> >> I'm doing a final year project at university working with povray and need to
> >> work with the source code but due to its sheer size I have no idea where to
> >> start and I've been unable to find any diagrams that help with this.
> >>
> >
> > Have you tried to apply some tools on the sources ?
> > As blind as it could be, doxygen might already give you some clues.
> > (but it won't explain how it happens, and you'd better investigate the
> > boost::thread (or whatever their names))
>
> A few header files indeed include doxygen-compatible documentation.
>
> >> I was wondering if there were any class diagrams or flow diagrams showing the
> >> structure of the program or the execution process. If not, what is the entry
> >> point of the program? Is it the povray.cpp file in backend?
>
> I'd suggest starting at
>
> TracePixel::operator()
>
> in tracepixel.cpp, and work your way "up" and "down" from there. This is
> where a single pixel is computed.
>
> >> And also, how close is the current
> >> beta to being complete? As it's design for multi-core processors is ideal for my
> >> work but I don't want to do loads of work and then have it all change due to the
> >> final release changing things.
>
> We plan on releasing 3.7.0 proper in just a bit over a week's time, so
> you can safely presume that the overall architecture is not going to
> change anymore until then :-).
Hiya,
I've taken a look at TracePixel::operator() and that's all fine, but which is
the main bit of code which makes its call to that? Where does it loop over each
pixel and call the tracepixels () operator method? I can't seem to find it :(
Thanks
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 09.01.2011 20:37, schrieb Aidy:
> I've taken a look at TracePixel::operator() and that's all fine, but which is
> the main bit of code which makes its call to that? Where does it loop over each
> pixel and call the tracepixels () operator method? I can't seem to find it :(
Try TraceTask::Run().
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |