|
![](/i/fill.gif) |
Here are some explanations of the speed optimizations in MegaPov 0.5:
The constant-media speedup works like this:
If the ray in question is a shadow ray (meaning that we are only determining
how much light is blocked as the light travels through the media) and all
participating media are constant, then POV will use one interval, and one
sample using media method 1 instead of the user-selected method. The reason
is that no other samples are needed. A single sample will give us the
density, and we really don't care how much light is hitting the media along
the path of the ray, because we only care how much light was blocked as the
beam of light traveled along the ray.
The memory cache speedup works like this:
The issue is that during the main rendering loop, POV calls pov_malloc and
pov_free many times, which results in a significant amount of CPU time
(depending on the operating system, of course). So, we malloc some memory
before rendering starts, and then use that memory over and over again
instead of mallocing and freeing. This heap of memory is basically stored
in a stack, so that a "malloc" now consists of incrementing an index, and
"free" simply becomes a decrement of that index. The stack data structure
allows fast, efficient, and easy access to the memory. The stack is
expanded in size if more memory is needed.
The disc and plane optimizations were discussed earlier in this newsgroup.
The area_light speedup basically in-lines a function and, in the process,
removes some wasted computations.
The macro speed optimization fixes a previous problem with MegaPov 0.4,
which caused macros to parse very slowly if a large file containing many
macros (such as an object library) was encountered. I just noticed that I
listed this under both a bug fix and an optimization in the announcement and
on the history page. oops. I guess there's _only_ 23 bug fixes instead of
24. ;-)
-Nathan
Post a reply to this message
|
![](/i/fill.gif) |